How can I solve NetBeans plugin dependencies (user and not developer question)? - netbeans

Within the context of upgrading plugins explain how to resolve plugin dependencies when NetBeans user interface's reports specific missing dependencies, yet these do not resolve with a google search or are unmentioned in the netbeans FAQ.
The practical example leading me to ask this question was when I attempted to install an in-development-plugin org-netbeans-modules-htmlprojects.nbm. It requires General Queries API v1.24 and I have v1.19.1.

Have a look at the bug report that mentions the nbm, it's for version 7. This also means that the mentioned version for GQA is also version 7 specific.
You best choice is probably to upgrade to version 7, it has some nice improvements over version 6.9 like HTML5 support. As a new install picks up the configuration of an installed previous version upgrading shouldn't be a lot of work.
EDIT based on restated question:
The short form: you cannot, it's not meant to work that way.
The long form: due to what happened here and the inner workings of Netbeans the error message was less clear than it could have been...
you downloaded a module for a higher version than the installed one
Netbeans' nbm deployment descriptor states dependencies on editor modules, not on editor versions - see inside the nbm which is actually a ZIP file Info/info.xml, manifest element, OpenIDE-Module-Module-Dependencies attribute.
Normally that error would not happen, as the version of the nbm will normally match the editor version, and the dependencies should either be satisfied or satisfiable by on-the-fly installation of the missing dependencies.

Related

NetBeans 8.2 External Execution Base API Missing for Scala Plugins

I am using NetBeans 8.2 to develop Scala application.
Some Scala plugins require: "The plugin External Execution Base API is requested in implementation version 201510222201".
Can I download that API anywhere?
One of the frequent pull request submitters has an 8.2 plugin set available for download.
I've just ran into the same problem. The solution is the following:
Find out what version of the External Execution Base API you have in your Netbeans installation.
In my case, it is noted in
..\NetBeans 8.2\ide\modules\org-netbeans-modules-extexecution-base.jar\META-INF\MANIFEST.MF
Edit the dependency definitions of the related nbscala nbm files.
In my case I had to update the following files
org-netbeans-modules-scala-sbt-1.8.1.0.nbm\Info\info.xml
org-netbeans-modules-scala-sbt-1.8.1.0.nbm\netbeans\modules\org-netbeans-modules-scala-sbt.jar\META-INF\MANIFEST.MF
org-netbeans-modules-scala-console-1.8.1.0.nbm\Info\info.xml
org-netbeans-modules-scala-console-1.8.1.0.nbm\netbeans\modules\org-netbeans-modules-scala-console.jar\META-INF\MANIFEST.MF
Delete the nbm signatures, since the changes made it invalid
org-netbeans-modules-scala-console-1.8.1.0.nbm\META-INF\NBSCALA.*
org-netbeans-modules-scala-sbt-1.8.1.0.nbm\META-INF\NBSCALA.*
Install the modules and hope there won't be any issue encountered by this hack.

FindBugs Eclipse plugin: is there a way to set "Run automatically," and "(also on full build)" options on workspace level?

I have an eclipse (kepler) workspace with several (mostly java) projects. I just installed the FindBugs (2.0.3) plugin, and noticed that the "Run automatically," and "(also on full build)" options are only configurable on the project level - and not on the workspace level.
Is there any convenient way to enable/disable these options on the workspace level (other than a search/replace approach on all .project files)?
UPDATE: it seems this feature is considered to be added to the upcoming 3.0.1 version:
https://sourceforge.net/p/findbugs/feature-requests/287/
This may also mean that there's no way to do this in the 2.0.3 plugin, which means the solution to this problem is to write a search&replace script :-(
Short version: since this question received no answers in about a year, it is safe to assume, that the answer is: no, the Eclipse Find Bugs plugin 2.0.3 (or earlier) is not capable of the workspace-level configuration of the mentioned options.
Possible workarounds:
Upgrade to 3.x.x or higher versions of the plugin. (I already mentioned that in the question above.)
If upgrading is not an option, you have to bulk update your .project
files. Now I'm pretty sure there's an XML tool or a nice scripting
language, that is designed for this kind of problem (bulk
update of XML content). But since I already had to solve this exact
problem with a simple Java program, I might as well recommend just
that.

Eclipse bundle version tolerances

I'm trying to install an Eclipse Product into an existing Eclipse installation using a third-party-tool (namely the IBM Installation Manager) but it fails with several errors of the kind
CRIMA1054E: Installing bundle "org.eclipse.equinox.p2.repository.tools_2.0.1.R36x_v20100823" into this existing Eclipse installation does not meet the version tolerance of "[2.0.100,3.0.0)" for the existing bundle "org.eclipse.pde.ui"
Unfortunately, I can't disclose any specifics on the affected product, so I'd like to turn this into a more general question.
Following some research on the Eclipse platform, my understanding is that it is one of the key features of the OSGi Specification, that one should be able install multiple versions of the same bundle (≘ plugin?) into the same environment. If the bundle org.eclipse.pde.ui is already present, I assume that also its required version of the [...].p2.repository.tools is already available.
My question: Why should it be a problem to just add another version of that plugin to the environment? Am I getting something terribly wrong about Eclipse and OSGi?
Side question: Shouldn't version 2.0.1.R36[...] be inside [2.0.100,3.0.0) anyway? Doesn't really affect my main question though, because I have other examples that are clearly out of tolerance.
Some initial thoughts and theories
Even though Eclipse allows parallel versions of a plugin, some plugins still conflict with other versions of themselves. Still, then I would expect more of an error like "[...].repository.tools_x is incompatible with [...].repository.tools_y which is required by existing bundle org.eclipse.pde.ui"
The installation is not blocked by Eclipse but by the IBM Installation Manager. It probably does some internal dependency checking but is too lazy to consider parallel bundle version installs.
Again regarding that specific product: Unfortunately the product is not available through the regular Eclipse software installation mechanism. I also would like to avoid dropping it into my Eclipse manually because I'm dependent on regular updates and those are only delivered through the IBM Installation Manager.
Any Eclipse plug-ins that contribute UI must have the singleton directive set to true. This means that only one bundle with that symbolic name can be in the framework, see http://wiki.osgi.org/wiki/Bundle-SymbolicName for more info.
I went and inspected the org.eclipse.equinox.p2.repository.tools bundle in my version of Eclipse (3.8), and I can see that it does indeed have singleton=true.
You said: "2.0.1.R36[...] be inside [2.0.100,3.0.0)"
That's not the case, as 2.0.1 is < 2.0.100.

Is there a way in Eclipse to find out plugins that are not used?

I am struggling with this!
While trying to install some features - eclipse keeps complaining about some dependency not met and about old version of some dependencies. The messages are rather not straigtforward.
Is there a way to clean the eclipse installation of the unused plugins? Does eclipse tell you on its own as to which features/plugins have not been used (for a while)?
What would be the definition of an unused plugin? All plugins that Eclipse update manager is referencing are currently in use because they were installed directly or are referenced by plugins that were installed directly.
I am not aware of anything that would actively track which features you are utilizing while using Eclipse and then report on unneeded plugins.
The error that you are running into typically happens because plugin A that you have depends on plugin X v1 and you are trying to install plugin B that requires X v2. Since both v1 and v2 of X cannot be simultaneously installed, installation of B aborts.
Here are the two most common causes of users finding themselves in this situation:
You haven't run "search for updates" recently, so many of your plugins are on older service levels. The plugin you are installing, however, requires a newer service level of a particular plugin. Resolve by updating your installation prior to trying to install the new plugin.
The plugin you are trying to install was not designed to be compatible with the major version of Eclipse that you are running. For instance, you might be running Eclipse "Galileo" 3.5 platform while the plugin you are trying to install was designed to work with Eclipse "Helios" 3.6 platform. You cannot use the update manager to move between major releases. Pay attention to what yearly release the plugin advertises support for. If it needs a newer version and you are willing to upgrade, you will need to download a new package.
Outside of that, post a new question with specific failure message you are getting along with details about your current installation and what you are trying to install. Someone here ought to be able to translate the installation failure into resolution options for you.

How can I disable plugin version compatibility checking in Eclipse?

When I try to install Eclipse plugins, I often get an error with details like:
An error occurred while collecting
items to be installed No repository
found containing:
org.eclipse.equinox.concurrent/osgi.bundle/1.0.0.v20090520-1800
This is clearly a bug in Eclipse. The bundle I'm installing doesn't need any special version of anything, it's just a profiler plugin that works in literally any build of Eclipse 3.4. Refusing to install my plugin is not an acceptable course of action. Eclipse should stop showing this message and install the plugin.
I'm not sure exactly what error the Eclipse developers made, but I can see that the version compatibility checker is absolutely strict, and it should not be. Either it is incorrectly evaluating the required bundles, and failing as a result of its own blunder, or the version requirements of the bundles are loosely defined in a way that the version checker does not really understand.
So, is there a way to simply disable this version checker? The thing is crippling my Eclipse install. Frankly, Eclipse would be better if the thing were completely deleted from the application. We only need it to choose the correct version of existing plugins for binding OSGi services. We don't need our development tools to kibitz about whether a plugin seems proper.
Thanks in advance for any suggestions.
Byron
As mentioned in the wiki
The message indicates that the Eclipse provisioning system P2 has found meta data to install a plug-in but can not locate an artifact repository that provides the required downloads
It is suggested to remove update sites and re-add the same update sites, to trigger a refresh, but in your case, it is not your plugin update site which is involved.
There is indeed a bug (236437) with Eclipse 3.4 about "Lost artifact repositories". It has been solved in Eclipse3.5, but if you cannot use that version, there may be a workaround:
1) export the update site listing to bookmarks.xml file (Software Updates->Manage Sites->Export)
2) stop eclipse
3) remove configuration/.settings/org.eclipse.equinox.p2.*.prefs files
4) start eclipse
5) import the bookmarks.xml file (Software Updates->Manage sites->Import) that was exported in step 1
Comment #59 helped me fix my updating problem, thanks!
Though, I think maybe it was enough to just delete the configuration/.settings/org.eclipse.equinox.p2.*.prefs files as I have a feeling that the problem was already resolved before I imported the bookmarks file (things happened a bit in parallel for me here).
Note for Eclipse3.5 users:
I am seeing this in 3.5.1 when trying to install stuff from an old style update
site when I include site.xml:
http://www.perforce.com/downloads/http/p4-wsad/install/site.xml
If I remove site.xml I can install things fine.