I am really new in buckminster.
I have just downloaded from our repository an Eclipse RCP project that needs a plugin update (placed in its Target Platform). We are currently using a remote target platform.
I have downloaded the remote target platform configuring its path in the targetplatform.source project, then I did the update and reload it checking the plugin's version. I have changed the version number in feature.xml on my targetplatform.feature project (that contains the buckminster.properties file).
The problem comes when I right-click on the targetplatform.feature project, select Buckminster > Invoke action... > site.p2. This just rise an error and the console shows the Buckminster log with the same error:
java.lang.IllegalArgumentException: case variants of key: awt.toolkit: case variants of key: awt.toolkit
Thanks in advance!
Best regards,
I finally had to stop using a remote target platform as I could not solve the Buckminster problem. The workaround described below covered my plugin update needs.
In order to have a control version system, the plugin update problem can be managed by having a repository manager (for example Nexus). Then you can simply upload a zip of your target platform with the updated plugins. Nevertheless, this forces the configuration to set the target platfom as local and therefore you need to download and unzip it previously.
Related
Background
My Eclipse RCP application is built using Tycho. It consists of multiple components (in the form of OSGi bundles/Eclipse plug-ins). One of these component contains the product file and materializes the product.
There is a reactor POM at the application root, which builds all components in order, but I also want to build other components independently (using mvn deploy) .
Building such a single component works as follows:
Retrieve the latest versions of all the component's dependencies from our company (p2) repository.
Build the component.
Deploy the component to our company repository to be used as a dependency for other components itself.
Note: Our repository is a normal maven2 repository hosted on a Nexus, whose RCP artifacts are automatically mapped to a p2 repository format as well. This way, Tycho can use the p2 repository format to find dependencies, while the standard Maven deployment can be used. This works fine.
Note: My parent POM makes sure that we look for dependencies at the p2 repository URL. The deployment URL is the default maven2 format location of the repository. This works fine.
Problem
When building such a single component through the command-line (mvn deploy), Maven looks for intra-project dependencies in the p2 repository and they are correctly resolved (i.e. latest version is automatically downloaded and used in build).
However, when developing in Eclipse, the IDE cannot resolve them. The manifest files gives an error at each of my intra-project dependencies that they cannot be resolved.
Question
My question is: How can I make the Eclipse IDE look for dependencies (and new versions of dependencies) in either:
My local p2 repository (~/.m2/repository/p2/osgi/bundles)
My company p2 repository (nexus.mycompany.com/myproduct-snapshots/.meta/p2)
Ideally, it would look for them every time and fetch the latest version if a newer version is available.
If it does not use the p2 repository URLs in the POM, how should I configure Eclipse?
Example
Consider an eclipse plug-in com.mycompany.myproduct.fancy, which depends on another eclipse plug-in com.mycompany.myproduct.core.
Both also have a POM (configured for Tycho use), which (through their parent POM) have my Nexus repositories configured correctly: maven2 repository URL for deployment and p2 repository URL to look for dependencies.
First I deploy the core plug-in to my maven repository (using the default mvn deploy). The Nexus repository will provide this deployed plug-in in both maven and p2 format.
When I build the fancy component through the command line (using mvn install), the (earlier deployed) core component is found and downloaded automatically.
project/com.mycompany.myproduct.fancy$ mvn clean install
<searches in p2 repository, download core>
<builds fancy>
<SUCCESS>
When I open a new Eclipse workspace and open the fancy component, its Manifest (which contains its dependencies) gives the following error:
Bundle 'com.mycompany.myproduct.core' cannot be resolved.
My question is: how can I develop the fancy component in the Eclipse IDE without the need to open core as project in Eclipse.
Speculation
This is some speculation from my side. Please correct me if I'm wrong and any other solution to the actual problem is also welcome!
I know the m2e plug-in of the Eclipse IDE currently maps Maven POMs to Eclipse concepts (using m2e connectors). I have installed the dedicated Tycho connectors. For example, the mvn compile step is actually performed by the Eclipse JDT compiler.
I also know that when a complete Tycho product is started in Eclipse, it is run in the Eclipse PDE environment. For example, I need to a specify a target platform in my Run configuration.
I know I can open all components in my Eclipse workspace. This would solve the problem, but is not feasible as I have many components and this would break independent component development.
I assume the Eclipse m2e mapping and/or the PDE build environment is not smart enough to fetch (latest) dependencies automatically at build time. Please correct me if I'm wrong. :)
Therefore, I assume I need to specify the target platform at build time too. I have taken a look at Window > Preferences > Plug-in Development > Target Platform. I can add our p2 repository to the Target Platform, which solves the problem. However this gives many problems:
I need a feature containing all components for this to work. Only features can be added.
Every time I deploy a new build of a single component, I would have to rebuild the complete feature (to create a new feature version on our p2 repository).
Every time I update a component and build the feature, I would have to manually change the Target Platform.
If the above is all correct, I speculate I need an m2e connector (or a different one from the current one) that actually checks the p2 repositories specified in the POM when resolving the OSGi dependencies and automatically adds those to the target platform.
As indicated by Nick Wilson, you will need to install the m2e Tycho Configurator, which basically "links up" Eclipse and Tycho (i.e., makes Tycho available in Eclipse).
You should've been pointed towards it after having installed m2e, but you can also install it manually:
Go to Window > Preferences > Maven > Discovery.
Click the "Open Catalog" button. This will open the "m2e Marketplace" window.
Search for "tycho", this should give you the "Tycho Configurator" as sole search result.
Click "Finish", you're done.
I've had this issue as well, and it isn't simple to find the solution, so I hope this helps!
The "most automated" way to configure your target platform in Eclipse is to use a target file. That file can be checked in with your sources, so every developer only needs to open the file and click on "Set as Target Platform" to activate it. AFAIK there is no m2e connector or Eclipse plug-in which does that automatically.
Given your development process, setting up this target file is a little more tricky. Since you don't have a feature which contains the latest version of all your bundles, you need to include the bundles directly in the target file. This is not possible via the rich editor, but can be done with a text editor:
Create a target definition file, add your p2 repository, and select any feature from that p2 repository. Save the file.
Open the target file in a text editor, remove the <unit> entry for the feature you added.
Instead, add an entry for each of your bundles:
<unit id="a.bundle.symbolic.name" version="0.0.0"/>
This target file then contains the latest version of each of the listed bundles. To see the content, open the file with the "Target Editor" again and switch to the "Content" tab. This file can now be used by all developers.
Note: When a new version of one of the bundles is deployed to Nexus, the developers will only see that new version if they open the target file and choose "Set as Target Platform" again.
I am trying to deploy a version of Eclipse and would like control over the default repository list. See my earlier question.
In my other question, I learned that this is stored in the user's home directory under ".eclipse\org.eclipse.platform_3.7.0_525061626\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs".
I would rather not deploy this file to a user specific location because there might already be one from another Eclipse installation and there could be more than one user account.
Is there any way that I can avoid the user profile?
I did find an equivelent file under the main Eclipse folder "eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs" but changing this didn't make any difference.
Thanks,
Alan
You can use p2 touchpoints and the p2 director to install your feature to customize the version of eclipse you are trying to deploy.
See p2.inf for an example of touchpoint configuration instructions that add p2 repositories to the default install. This one is part of an sdk.product generation. If you are starting with an eclipse that already has a product, your touchpoint instructions would have to remove the repositories that were already included and then add your own.
instructions.configure=\
addRepository(type:0,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:1,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:0,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);\
addRepository(type:1,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);
The way that I ended up doing this was to create a lightweight plugin that starts when Eclipse loads. This then programatically adds the update site as detailed here: https://stackoverflow.com/a/7384954/101642
I'm using tycho to build my rcp application. Sadly, today I have to release the first internal milestone, but one of the projects I'm using is down (The great LWJGL - http://www.lwjgl.org/) and consequently my build fails because I cannot resolve an entry of my target platform.
Does there is a way to disable such update?
Note that I already have build my app, hence I already have downloaded all the LWJGL's jars and p2 stuff. Now I simply want to use the version of LWJGL I already have to build my RCP application...
There is a corresponding Eclipse p2 bug that needs update site checking for the target platform - that's why maven offline mode does not work as expected. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=337022
For later, I suggest building a mirror of critical outside sites. In that case you could at least redirect the build to that. E.g. b3 aggregator can be used for this: http://www.eclipse.org/modeling/emft/b3/
try maven offline mode (mvn -o)
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .