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?
Related
When working with software projects that employ the Java programming language, there are 3 commonly employed build systems:
Apache ANT-IVY,
Apache Maven,
and Gradle.
Looking through the jungle of the Eclipse Interface each of those build buzzwords occur, yet this IDE gives me no clue what build system it actually uses?
How can I find out what Eclipse thinks should happen when I tell it to build the project?
If you don't set up any special then none of these system is used to build a Java project. The Eclipse Java compiler runs automatically as you type. Other builders written as Eclipse plugins run when resources change, you can see information about these in the 'Builders' page of the project Properties.
There are Eclipse plugins that add support for all the build systems you mention. They are used if you create a project specifying which system you want to use.
My company has a featured based RCP 4 app. We use tycho to build the app with a predefined target platform. There are several plugins that are retrieved from separate p2 update sites that have different versions of the same plugin that are both needed for our app to run. However, it appears that Eclipse only picks up the latest version of the plugin when the code is executed so my app fails to run properly.
I considered an article that had a similar problem, but the solution seemed to only deal with the issue where the plugins were defined in a dependency feature, not retrieved from a separate update site.
I've already tried including both versions of the plugins in the feature.xml with the correct "version=" value for each, but still only the latest version is used. What I want to know is how to get Eclipse to include both versions of the same plugin from the feature definition when the product is excecuted?
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.
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've recently learned that the import section from feature.xml is legacy, and the actual dependency work is delegated to the p2 engine, which uses the information from the plugin manifest.
I am not sure though if p2 is available for all recent versions of Eclipse, or in all Eclipse-based products, so I'm not sure if it is safe to remove the import section from feature.xml.
Under what circumstances is it safe to remove the import section from feature.xml? Assume that we are taking into consideration Eclipse 3.4 or newer.
P2 was introduced in Eclipse 3.4 release. It had quite a few issues in that release, so a way was given to revert your Eclipse install to using the legacy Update Manager. Starting with 3.5 release, p2 is quite stable and is a definite improvement over the old Update Manager. I am not certain if it is possible to revert to the Update Manager in 3.5 or higher release. I certainly haven't heard of anyone doing this.
P2 is present in all Eclipse packages starting with 3.4 release.
I wouldn't categorize feature import as a deprecated feature. You would still want to use it to pull in plugins when you don't have direct OSGi dependency on them.
Consider the case where you are building an extension to JDT. Say you only depend on JDT core api (no UI extensions). If you only rely on OSGi dependencies, when your plugin is installed, p2 will dutifully install JDT core bundle, but not the UI bundle. Perfectly fine from OSGi perspective, but probably not what you intended.
I recommend sticking with feature import to describe your high level dependencies to make sure that they are installed in full. Relying only on OSGi dependencies works best for free-floating bundles that aren't part of something bigger that should be installed as a unit.