I have an eclipse feature with a few platform dependent fragments (jogamp based plugins, to be precise)
I'd like to export that feature using PDE export. It works, as usual, only it will omit all plugins that do not match my current platform.
I want to use this exported feature as a p2 site that can be used from different platforms, so that's no good.
Is there a way to export an eclipse feature for all platforms?
Thanks, Frank
There's no easy way to get all the platforms from within eclipse as a PDE export. I took a crack at using PDE build as a workspace export, http://pweclipse.blogspot.com/2011/02/pde-build-as-workspace-export.html but it requires some digging to get all the properties correct and it's specific to one workspace.
It's better to set up a proper headless PDE build to generate your p2 site.
Related
I used to package my various Eclipse RCP products with PDE, for years.
With my latest upgrade attempt to Eclipse Oxygen, I got some new strange resolution errors which I could not solve, and I decided it really was time to give Tycho a try. I followed the excellent article about Tycho by Lars Vogel, and after a bit of tweaking, it worked well (and I was not stucked by the same resolution errors as in PDE! Yay!).
But indeed it was a simple test: I created a folder for my bundles, another for my features, created my poms, and so on. Now I look at the degree of automating in my PDE and find quite a huge gap.
In PDE, there is a build.properties where you give your master feature file and a map file, and the process will, seemingly:
parse the master feature
parse the features in it (recursively)
parse the plugins in them
find in the map file the plugins to be packaged (the other dependencies are supposed to be in the target platform)
download the relevant git repos
move the relevant plugins/features to the working directories
launch compile, p2 and so on
(note : the git part needs you provide the egit fetchfactory)
Now in Tycho, I have to create poms, but it is not the problem. I have to create some master poms, and for the individual plugin poms, I have either the pomless option, or the pom generator. The pom generator also seems to have the advantage of creating the parent pom which contains all the plugins as modules. So far so good.
But I have to fill the features and plugins folders, and I'm stuck here.
I do not have PSFs for my products, because I never needed it: in PDE, map + product definition does the trick.
Does it mean I will have to maintain PSFs from now on or is there another tycho solution I did not find? (Tycho doc is quite scarce, in my opinion). Maintaining PSFs seems redundant to me because I have product and map, and also because I have many products, many plugins, and many of which are common to several products.
(Indeed, a basic solution would be to take the git repositories mentioned in the map file, dump them all and launch tycho. Tycho would compile all the plugins, and then the p2 part would package only the product-relevant ones. The problem is that I have plenty of different products that rely on plenty of different repositories. And even in a given git repo, I have plugins that may or may not be relevant for a given product. Thus, I would compile hundreds of useless plugins in the process.)
My need is to copy in the tycho folders only the plugins and features which are referenced in my product and which are not already in my target platform. Generating a PSF from my product and my map would be shifting the problem.
Indeed, I can code this, and I will if needed.
But given that all this is already automated in PDE, is there at least some parts of the process that could be automated with some tycho plugins I did not uncover?
After some time of digging, here is the solution I finally chose.
In order to fetch the relevant features and plugins, I used... PDE ! I digged in PDE and found the various steps in its process. The first one is to fetch (it is an ant task named eclipse.fetch). I externalized this part, and my script launches it, then generates the master poms by scanning the fetched features names and fecthed plugins names, then adds the other tycho confugurations and then launches tycho.
In the end, granted, it is not a full tycho solution, it is a hybrid one PDE + Tycho. But it works like a charm, and the build/package process is Tycho, only the initial fetch is delegated to PDE. (anyway, PDE build/package process does not work in my case, as stated initially)
I have an update site that contains some 100 - 200 features and many more plugins. For some users all of these are needed, so I'd like to simplify the installation process by creating one feature that they can install. This feature would then contain all the contents of the update site.
I've created a new feature project and my plan is to add the contents of the original update site as included features and plugins in this project.
Problems is; In my feature project, when adding feature in the "included features" tab, I can only add features that are currently installed in my Eclipse platform. I'd rather not install those 200 features just so I can add them.
Is there a way to work around this?
Without the features installed in your target platform, you will need to edit the feature.xml file directly. All you need to do is to add the following for each feature that you want to include:
<includes
id="<add_feature_id>"
version="0.0.0"/>
Your build process (PDE or tycho) should add the proper version numbers for you.
I think you should have a detailed look at the Eclipse target platform concept. The features don't need to be installed in your current Eclipse platform (i.e. the IDE), they need to be installed in the target platform to be available for an update site.
If you never defined a target platform, your currently running application will be taken as IDE, and that is where your confusion might come from.
When I try to manipulate a feature I only need to have them in my workspace. No reason to install them.
Here are two short, but hopefully good questions:
When to use plugins and when fragments?
What is a headless PDE build and when to use it (and when not)?
Fragments are for when you want to expand or alter the functionality of a plugin. A fragment cannot exist on it's own, it requires a parent plugin. The typical example of a fragment are for localizing a plugin, i.e to change strings to other languages. The fragment will then alter the functionality of the plugin to replace resources or code with the contents of the fragment.
More details here Tutorial here
The headless part means you do the build without a gui, i.e from commandline or from a tool such as jenkins/hudson. PDE stands for Plugin Development Environment. In short, it adds some tasks to Ant, and you can use the defined resources and dependencies in the plugin.xml to build. The alternative is to again define classpaths, sources, etc in an Ant build file.
I've used it in some projects and it has been difficult to setup properly, but its the best way to build Eclipse plugins or products. We wanted to use relative paths for the build and had major problems with that. The earlier in your project that you set up a continous headless PDE build, the easier it will be to configure.
More info here
I am trying to avoid duplicating customBuildCallbacks.xml for all my plug-ins, when called from either PDE's headless build or the Eclipse GUI. I have in customBuildCallbacks.xml steps to generate code or modify the plug-in packaging that I:
obviously want to run with the headless build
would also like to run either when I export this plug-in from the GUI or from an external builder watching specific files in my plug-in
The headless build runs in a well defined environment, so I can set customBuildCallbacks.buildpath or even use a relative path in each plug-in's build.properties to point at my common customBuildCallbacks.xml. However, this is trickier from the GUI: that path is different for every developers since we do not have sources in the Eclipse workspace (we import projects from various locations due to our internal build process). I was hoping for every project to have an associated ant property holding its path on disk, similar to the ${workspace} variables exposed in various dialogs. I couldn't find anything useful though.
Does anyone have any experience doing this kind of things?
Thanks,
Romain
I have a bunch of Eclipse plugins and features, which I would like to build as part of a nightly (headless) build. I've managed to do this using a complicated setup involving manually specifying paths to Eclipse plugin jars, copying customTargets.xml, etc.
Is there really no simpler solution? Isn't there a way to just point out my Update Site's site.xml and say "build"; i.e. the equivalent of clicking "Build All" in the Update Site project?
Given that all the answers to this question are all 3-5 years old, I figure an update would be useful to others.
For those who want to add the building of Eclipse plugins to the CI process, I recommend they check out the Eclipse Tycho project. This is essentially a Maven plugin that allows you you to wrap eclipse projects within Maven project. With this we use Atlassian Bamboo to build our Eclipse plugin. This also allows us to use the Maven jarsigner plugin to sign our plugin files.
I've just been fighting with this problem myself. Are you using the productBuild script? Maybe putting your features into a product would help you out.
I am doing a headless build on a product configuration. The only script that I customized was to add some ant tasks to customTargets.xml to get my sources from SVN and to do a little cleanup on JNLP manifests after the build as I am using WebStart.
Then you only need to invoke antRunner on the out of the box productBuild.xml in the scripts/productBuild directory (in the pde-build plugin).
Check out Ant4Eclipse. I've used it to parse Eclipse's .classpath/.project files to determine project dependencies and classpaths. In combination with Groovy Ant Task, I have automatically built multiple projects in Ant using the Eclipse project files for build information.
A buildPlugin task exists, but I have not personally used it.
We are currently using PDE to automatically build features and our complete product. It works quite well. Make sure you use the right script for product build or feature build.
Eclipse Help on using PDE
EDIT: We've now migrated to Buckminster, which has an excellent command line interface.
You might look into buckminster and maven. There is a learning curve for sure, but they seem to do their jobs well.
We are using headlesseclipse, which can be found on Google Code:
http://code.google.com/p/headlesseclipse/
It works quite well, and can easily automate command-line building of plugins and features. However, I have not yet found a way to automate building of the update site via the command line.