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.
Related
I'm attempting to utilize the "Project References" feature in Eclipse for an embedded firmware project. I'm using Code Composer Studio 7.0 which is essentially just a wrapper for Eclipse 4.6 with CDT 9.0 and JRE 8. However, from what I can tell the features I'm trying to use are specific to the CDT. The embedded firmware is broken up into several parts with a few libraries, an RTOS platform, and the "core" firmware.
The intention is that the dependencies of a project are automatically built and updated in the proper order whenever a build on the core firmware project is triggered. However, due to some libraries building upon others I'm seeing some weird behavior that i don't quite understand. The dependency graph is shown below.
As you can see, there's a maximum of four levels of dependency. The issue that I'm seeing is that, while I've ordered the references in the order "Properties->C/C++ General->Paths and Symbols->References" as [Platform, PAL, HAL, Features] for the firmware project, the build order doesn't seem to follow that specification. The ordering seems to be semi-random. After a clean sometimes the PAL will build first, other times the Features will. The entire build ultimately fails when this happens due to dependencies not being accessible. Is there an additional step I'm missing to get dependencies to build in the correct order, or are nested dependencies not supported by Eclipse for some reason?
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.
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.
Bootstrapping Eclipse on new machines is such a time consuming process, you wind up asking yourself whether you really need each plugin. But there all handy, and help develop consistent habits.
Eclipse bootstrapping problems include:
Explaining / documenting what needs to happen
The actual time pasting in the right URLs and downloading
Version compatibility and dependencies
Eclipse likes to restart after each one
The changeover to the Eclipse Marketplace means that some plugins and instructions you find on the web tend to be inconsistent, depending on when they were written.
The Licenses... over and over and over... yes, yes, yes... I understand that the person installing needs to be aware of it, and have a chance to review them, but there's got to be a better way.
It'd be nice to have "patch file" (either binary or meta) that spells out what I want to add on top of stock Eclipse installation. I'd really like to find (or create) a 1 or 2 step process that sets up Eclipse, plus a favorite batch of plugins:
subclipse
m2eclipse
jetty support like runjettyrun
android sdk and plugin (or at least just the plugin)
aspectj
Web Objects / WOLiops
python, other langs
JVM Monitor, maybe EclEmma
probably a git plugin pretty soon.
Does command line maven help with any of this? It seems like its repository management would fit at least part of the functionality.
On a machine with an Eclipse installation matching your needs use File -> Export -> Install -> Installed software items to file. Import the generated file using the same menu on all other machines.
As Scott says, a good approach is to simply package a fully prepared Eclipse installation once all the plugins you need are installed. The downside is that you have to update most plugins afterwards.
Another option is to use Yoxos. With it, you can create a profile and configure it with all the plugins you need (and apparently Yoxos can do more than that).
Finally, this page might interest you concerning the configuration side of things.
Solution 1 is too search for more advanced Eclipse distributions.
For example, STS (Spring Tool Suite) comes with
AspectJ
EGit
m2e
(and of course) Spring IDE
One small trick can be done with m2e-android - Android Configurator for M2E Maven Integration. If installing it on clean Eclipse, it will also automatically resolve to install :
m2e
Android Developer Tools (ADT)
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.