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.

I’ve never tried to do this, but you might want to look at adding some logic to the customTargets.xml file to copy the tmp directory someplace before it’s deleted.

Also, it might be worthwhile talking about what you need to save in the tmp directory, and if there’s another way to meet your needs. If you want to talk about it offline, feel free to send me an email.

Regards,

— Patrick

thank you for this great guide it helped me a lot! It’s hard to find usefull help if it comes to pde and headless building so I’m glad you took the time to explain the most important part here.

But I still have a problem. The build works and everything, but I want to keep the generated tmp dir or in particular one of the plugins in it. I copyied the customTargets.xml into my configuration dir and deleted the clean target and it’s call (postGenerate target)but it still deletes the tmp dir at the end of the build.

Do you have an advice how to do this?

This is a common problem when upgrading from one version of RCP to another. The version number is embedded in the product definition and needs to be changed when upgrading. The simplest way to do this is to remove the org.eclipse.rcp feature from your product and then re-add it.

Hope this helps anyone facing a similar problem.

— Patrick

You helped us two years ago to set up our PDE build process for Europa.
We want to upgrade our Eclipse platform from Europa to Galileo. Our headless PDE build process works fine with Europa but fails with Galileo. Your example, updated for Eclipse 3.5.1 builds with no problem on our Galileo.

On our project, the build process stops on a generateFeature step with Java error code 13 and we get the following error message: Unable to find feature “feature_com.xxx.metatest.jniusbasic” with version in range [1.0.0,1.0.0]

I am totally stuck on this! I send you the build log file through email. Could you please give us some direction or some point to look at?

Thanks a lot in advance for your time!

Georges

org.codehaus.mojo
pde-maven-plugin
1.0-alpha-2-SNAPSHOT
true

${pde.build.label}
${pde.java.source}
${pde.java.target}
${pde.pluginpath}
${pde.base}
${pde.baselocation}
${pde.baseos}
${pde.basews}
${pde.basearch}
<!–win32,win32,x86–>

${pde.eclipseInstall}
${pde.product.finalname}
${pde.build.version}
1.0.201.R35x_v20090715

But I was getting the error
java.lang.NoClassDefFoundError: org/eclipse/equinox/launcher/Main
Caused by: java.lang.ClassNotFoundException: org.eclipse.equinox.launcher.Main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: org.eclipse.equinox.launcher.Main. Program will exit.
I have tried googling a lot but with no success.As given in the comment above,Govind had got the same error.
After a long hit and trial,I found that the problem was that due to that we have two jars in eclipse/plugins folder org.eclipse.equinox.launcher.source_1.0.201.R35x_v20090715.jar and org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar.When I removed the org.eclipse.equinox.launcher.source_1.0.201.R35x_v20090715.jar,it tried to find a org.eclipse.equinox.launcher.Main class in org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar and it finds that class in org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar and finally the problem got resolved.

Posting it so that if anyone facing a same problem,it might be the reason for it.

I’m adding an additional property in the resources section of the JNLP file and adding the jnlp.jar as on the rcp bundle’s local classpath.

Cheers,

Joep

I’m sorry to say I haven’t worked with JNLP before. You might have better luck asking on the RCP mailing list, if you haven’t already.

Sorry I can’t be more help with this.

— Patrick