I have been having a real hard time getting API Tooling to work in Eclipse 3.4.2. It keeps telling me:
The minor version should be incremented in version 3.4.0.qualifier, since new APIs have been added since version 3.4.0.40001
That being said, I have generated the plugins that are used for the baseline from the exact same code that it is being analyzed against. The API Tools docs say that it compares the current code against the baseline to see if there are any differences. I can't see how there could be differences if the built version is built from the current code.
The way that I tested it:
Create a new eclipse workspace
Create a new Plug-in Project with API Analysis turned on
Add a simple class to that plugin and export the package with that class in it
Build/Export that plugin to some location on your hard drive
Set the workspace baseline to that location and do a full build
You get an error for the project in your problems view.
Thanks,
-One very perplexed user
Looks like this is something that got fixed in 3.5. Too bad my company doesn't want us using 3.5 in case there are any incompatibility issues. (there were 3.3 to 3.4)
My recommendation to anyone who wants to do Eclipse API Analysis is to use 3.5.
First off, I apologize for jumping on a thread late after its "active time" but I am currently running into this exact situation, but with Eclipse Helios 3.6.
From your answer, you noted that something was fixed in 3.5. Are you aware of what this exact fix was AND if you have yet been able to verify that it is working under Eclipse Helios 3.6?
I would really like to have PDE API tooling working but I'm nearing my time allowed on this effort and need to move forward onto some pending tasks.
Thanks!
EDIT: I would have posted this in a followup link but did not see any such links available.
Related
I'm developing an Eclipse plugin and i've run into this problem several times already.
I always keep my Target Platform updated for the latest (stable) Eclipse release so that i test my code against all the recent updates, fixes etc.
However, this may (and have) result in accidental breakage of backward compatibility of my plugin, e.g. when i accidentally use new API that did not exist in the Eclipse version i aim to support.
Or, more sneaky example, in 4.6 Eclipse moved to Java 8 and some interface methods got default implementations. Now when i implement these interfaces my IDE doesn't automatically generate empty implementations for those methods and no error is generated. If i install and run this code against a previous Eclipse version these methods will throw AbstractMethodError since no implementation has been provided.
So my question is: is there a tool to further restrict API my Target Platform provides to some earlier Eclipse API version?
Is API Baseline an appropriate tool for this? Because i couldn't get it to work like this. (It allowed even non-baseline method calls not to mention the more complex default-methods example.)
You can use multiple target platforms, switching between them doesn't take long. For testing Stack Overflow questions I have one Eclipse install with 10 target platforms.
So have a target platform for the oldest release you want to support as well as your current release target platform and check the code runs against that.
It is particularly important to test with the actual Target Platform if you want to support Eclipse 3 releases as the were large changes going from Eclipse 3 to 4.
I am following the following blog to configure my golang environment (OS-X machine):
http://webapp.org.ua/dev/intellij-idea-and-go-plugin/
But, whenever I try to add go sdk (installed at /usr/local/go), it appear blank selection for the SDK.
Please suggest me, if I am missing something.
This page lists the SDKs which have already been configured in IntelliJ IDEA. You need to press the "Configure..." button and point the plugin to your SDK installation. Once you do this, it will become available in the SDK list for new project creation.
I would suggest to use the following for writing golang application:
https://groups.google.com/forum/#!msg/golang-nuts/tuGS99f-kqk/Tl5KqNG0js0J
https://github.com/visualfc/liteide
If you want to use IDEA with golang, we've made a lot of progress in the past months. Please install the latest release from github releases and give it a try.
As the name suggests, there are a few issues here and there but it should work much better that the current release of the plugin.
You'll find it a class over the other offerings for writing go apps ;) (disclaimer I'm one of the contributors to the plugin, I'm very biased)
So I've been messing around with the packaging feature that NetBeans offers, following this tutorial: http://platform.netbeans.org/tutorials/nbm-nbi.html. I didn't like how I had to modify the platform that my IDE was running on in order to customize the installer itself, so I decided to create a copy and just change the platform the application suite was using (Properties->Libraries).
This seemed to work fine, and even packaged that platform as part of the installer. However, when doing the packaging itself, I noticed that it was calling the IDE's platform build script to create the installer rather than the one I had customized. This defeats the purpose, at least in my case, of having the separate platform.
Within the platform manager, under the harness tab, I made sure that the platforms harness was being used rather than the IDE's, but it didn't seem to make a difference.
I verified the behaviour by throwing an echo into both the default IDE platform and my customized platform to see which was being called. I also noticed that the Ant call that gets made at the start of packaging makes an explicit reference to the IDE platform, as well.
I've tried this under 7.2 (currently using 7.3) as 7.3 has had some fairly nasty bugs and thought perhaps it was just recently introduced.
At this point I'm thinking it's a bug, but I was hoping that perhaps someone else had come across this and found some sort of solution or could shed some light on why it's doing what it's doing.
Thanks!
This is slated to be fixed for 7.4, in case anyone comes across it in the meantime.
Here's a link to the bug ticket: https://netbeans.org/bugzilla/show_bug.cgi?id=229478
I'm trying to get up and running with Virgo, and I'm following along with what appears to be an excellent tutorial, but I'm at section 7.2 and I just can't figure out why EclipseRT / Virgo doesn't appear in my list of options.
So far I've been using SpringSource Tool Suite (STS) as the guide recommended and have installed all the Spring dm Server Tools and Developer Resources bundles.
Has anyone else run into this issue or have a solution to getting the EclipseRT/Virgo server adapter?
Virgo 2.1.0.RELEASE and STS 2.5.0.RELEASE are both now out. The problems you had with the docs should be resolved. The documentation has also been updated to show the latest information as well.
Be aware that the STS 2.6.0 upgrade removes this server adapter! Refer to the STS JIRA entry STS-1690 for details on this removal. You can simply go to the Dashboard > Extensions tab and select "dm Server Support Extension" to put it back.
Hey, have a look at this eclipse forum for virgo
Seems like you have to get used to playing with the update sites until you find the right one. I imagine that by the time anyone reads this the url will probably have morphed every so slightly yet again. Sigh. Comes of playing with tech while they're still actively releasing.
In case someone is searching for more recant information, one need to install DM Server Tooling from http://dist.springsource.com/release/DMS-TOOLS/update to get Virgo in the server add dialog.
I've been just playing around with Virgo 2.1.1 and Eclipse STS 2.7.1.
Indeed there is no Virgo server adapter, but you can install it from this update site:
http://download.eclipse.org/virgo/milestone/IDE
For the latest version of STS (3.1.0), I tried many ways suggested, and find only the Eclipse Virgo/Tooling wiki works.
(http://wiki.eclipse.org/Virgo/Tooling#Install_Eclipse)
It adds the EclipseRT/Virgo adapter in STS 3.1.0.
I've read a lot about IBugTraqProvider interface and implementing an issue tracker into the commit dialog of TortoiseSVN.
IBugTraqProvider is written here.
Is there a more simpler way not to do it, building the plug-in and installing it on TortoiseSVN. The Document is not that clear that a developer can create its own plugin.
I'm working with SalesForce as the Issue Tracker, and retrieved the WSDL file to integrate with the Working Items. Now I need to know how to connect it to TortoiseSVN.
Please any suggestions?
Take a look at issue-tracker-plugins.txt in the contrib directory in the TSVN source code. There's a fairly decent example in C# that should get you heading in the right direction.
When I built a plugin, I built a test harness that passed arbitrary information using the IBugtraqProvider interface, so that I could debug the plugin whilst building it, without having to reinstall the plugin into TSVN each time.