Based on my tests, it appears that the new version of the bundle (from source) is included in the distribution. As a best practice, I would avoid having the bundle in both places, though.

— Patrick

Another question: when doing headless builds, are the plugins in the buildDirectory taken into consideration by eclipse with higher priority then the ones found in the eclipse/plugins directory.
Example:
1. I have deployed the de.inframe.synapse.client.jobmanager_3.0.0.beta-002.jar into eclipse/plugins.
2. In the buildDirectory the same plugin project exists.
When I run the build I the lines above in the log.

[java] [eclipse.buildScript] Bundle de.inframe.synapse.client.jobmanager:
[java] [eclipse.buildScript] Another singleton version selected: de.inframe.synapse.client.jobmanager_3.0.0.beta-002

Does this mean that eclipse will use the plugin found in its eclipse/plugins directory. If yes, why gets this plugin recompiled?

Thanks!
Diana.

It’s a common case to want to build on top of other resources that have already been built. And yes, moving these pre-built resources into your build target is the way to go. BTW, it’s generally not a good idea to use your Eclipse install as the build target (baseLocation property).

It’s much better to create a separate directory and unpack the RCP SDK, RCP Delta Pack, and whatever you need into it. It’s also a good idea to create the build target from scratch during a build because (as you’ve seen) it can vary from build to build.

As for the 2 plugins that it’s taking from the buildDirectory, I’m guessing these are neither of these is the plugin you’re trying to build. Is that right? Is there anything these two plug-ins have in common?

— Patrick

Regarding my building issue problem, I have tried out this solution. (I will explain it in very short steps, and I need somebody to review it :) )

1. in the build_directory/plugins update plugins that have been modified
2. copy all unmodified plugins to the headless-eclipse/plugins directory
3. run build (at this step all the plugins that eclipse finds in its “plugins” directory will be used in the build process i.e “Another singleton version selected” will appear for each unmodified plugin?- correct me if I’m wrong)

What do you think about the above steps? Will I manage to avoid the compiling step for the unmodified plugins?
———————————————————–

I have put in practice the steps described above and copied all of the jars generated by the feature build, unpacked them to eclipse plugins directory. For 2 plugins out of 62, eclipse doesn’t use the plugins from its directory but takes the 2 plugins from the buildDirectory :((
Could it be that the 2 jars for haven’t been correctly build. After what details should I look in order to find the cause?

Thank you!
Regards,
Diana.

Thank you very kindly for your answer, I have tried out your first suggestion on the build directory. More precisely I have changed the following 2 lines in the build.properties file.

topLevelElementType = plugin
topLevelElementId = de.inframe.synapse.client.framework

The compilation seemed to work OK but at the assamble-step I received the following error:

[java] init:
[java] assembleElement:
[java] Java Result: 13
[echo] BUILD FAILED
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\build.xml:27: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\build.xml:92: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\customTargets.xml:12: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\allElements.xml:16: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\genericTargets.xml:134: The following error occurred while executing this line:
[echo] java.io.FileNotFoundException: C:\builds\featurebuilder\assemble.de.inframe.synapse.client.framework.all.xml (Das System kann die angegebene Datei nicht finden)

Do you have any clue why?

Thanks again,
Diana.

PDE Build can build a specific plug-in. You can use the topLevelElementType and topLevelElementId properties to set this up, and I imagine you could use variable substitution in an Ant script to build one or more plug-ins that have changed.

Whether this will work or not depends on your goals for the build. If you’re building to verify the process and run unit tests, this shouldn’t be a problem. If you’re building to deploy (e.g. to a p2 repository), then the feature version will need to be incremented every time a plug-in is built, even if this is only the qualifier section.

Another alternative might be to create more fine-grained features.

— Patrick

I use a feature-build that manages more then 60 eclipse plugins. When somebody makes changes on one plugin, the build process is triggered for all the plugins in the feature.
Do you know if there is a way to customize the headless builds in such a way that only the plugins changed through the last commit are re-build?

Thanks,
Diana.

no, sadly, an additional project is not an option. Your suggestion about the custom task could be it.
However I solved this in a different way. As we use maven 2 to automatically build the projects I used the maven bundle plugin to build the bundle of the project on mvn install and after that the build.xml (headless build) is executed using the exec-maven-plugin. The headless build then uses the build bundle.

All in all it was quite a fight but thanks to your article and the comments here it was less a hell than it could be.

Thanks again :)

Perhaps one option would be to move the build configuration area out of the product bundle. I usually create a com.mycompany.myapp.build project for each application. This project is not a bundle, just a regular project that contains build-related files such as build.properties. This project also serves as the config area for PDE Build.

I’ve never had any problems with this approach, and you definitely shouldn’t have to go through the process you describe. If creating a separate build project isn’t an option, I guess you’ll need to try the solution I suggest above (custom task to copy the tmp folder).

Regards,

— Patrick

thank you for your answer.

My situation:
The headless build is beeing started from within the plugin project with the .product. Therefore the headless build can’t find the defining plugin (the one with the .product as it is not build yet and the headless build is taking place in it). Currently I added the root path of the project as a plugin path to the build.properties so the pde builds a bundle of the project automatically before the headless build itself begins and then grabs this bundle during the build.
The automatically build bundle is located temporary in a tmp directory. After the headless build the tmp directory is beeing cleaned so the bundle is deleted. I want to avoid this as I want to keep this bundle.