Community
Participate
Working Groups
This is effecively the same as bug 85090 but it wasn't filed against PDE yet. In the <pluginname>.jar target in the generated build.xml for a plugin, there are paths to be found like the following: <pathelement path="../../Programme/eclipse3.1/M5/eclipse/plugins/org.eclipse.osgi_3.1.0/osgi.jar"/> This only works on other machines if Eclipse is installed in the same directory structure as on the generating machine, let alone Eclipse on other platforms (e.g. Mac). This is a problem mostly for "custom = true" in the build.properties, when one starts off with a generated build.xml. It would be good if the Eclipse install directory could be configured in the build.properties. I'm using a custom build.xml anyway only because I need some bytecode-enhancement in the build process, which is common at least with JDO based applications. I'm not very ant-savvy, but wouldn't it somehow be possible to configure a bytecode-enhancing task incl. classpath to be invoked between compilation and jar packaging? I mean, in a way that makes custom build unnecessary. I don't really trust custom build.xml, because I never know what a newly generated build.xml looks like (and potentially must look like) in future versions of Eclipse.
Right now, I am working on a small patch for PDE-build, that is relevant to that bug. I understand that as Pascal said in bug 85090: >The build.xml scripts generated are not meant to be reused. >They are generated according to a specific setup (workspace location, eclipse >install location, etc). Nervertheless, the path elements are the only build elements which are not parameterized by a an ant variable, as far as I can tell. The patch I'll submit tries to find common paths among all the generated classpath elements, and generates ant properties for them accordingly. It performs some optimization once all the paths have been generated, before the script is written to create as 'smart; as possible variables. Expect that to come in sometimes this week. It will not be very pretty -- this is an optimization so it uses heuristics -- but the output is clean. You'll be the judges! IMHO, this can help make the generated build more re-usable without needing the whole pde build machinery. It's to help folks that write plug-ins to re-use the PDE UI generated scripts more easily, and have them generate more consistent builds. I think it would go a long way to help the casual plug-in builder, and the RCP developer.
I guess you will have to elaborate on why it "helps the casual plug-in builder, and the RCP developer."
Being able to generate a script that can be kept under version control, that can be run standalone and just driven from a set of build.properties or through an ant call is something that can de-mystify the build of a plug-in or an RCP, IMHO. De-mystification will help folks to re-use that. Using the export does that behind the scenes but cannot run headless. A pde generated ant script makes this more accessible, and can run headless. Now becasue the scripts are designed to be throw-away they are hard to re-use in their curent shape. A small enhancement to make the path element 'parameterized' (what kind of an ugly word am I creating here? ;-)) is all you need to make them re-usable IMHO, and offer the possibility to override the hard coded generated paths in some property, so they can be re-used regardless of the shape of your workspace or local eclipse installation.
I just forked off bug#107190 covering the issue of bytecode-enhancing separately from the issue of making generated build.xml files more reusable. Apart from that, I absolutely agree with Philippe that making the RCP build process more transparent by using build.xml files that don't vanish after usage would make things more manageable. Being able to simply invoke an ant task to create different configurations of an RCP product export would be nice and more in line with what people are used to in their previous projects.
Philippe, although I understand the motivation behind the effort, I think the resulting script won't be resilient enough to plugins that change location and that the files that will be kept into repo will end up being the source of problems. Moreover this will likely break other nasty pde ui scenarios Instead of working on this, and if your goal is to help the developement of RCP based app, I would prefer to have you look at how we can make the export of RCP product smoother using the script generation technology.
The initial bug has been solved by allowing people to contribute in various points of the build cycle of each plug-in (see M3 release new and noteworthy)
(In reply to comment #5) > Philippe, although I understand the motivation behind the effort, I think the > resulting script won't be resilient enough to plugins that change location and > that the files that will be kept into repo will end up being the source of > problems. Moreover this will likely break other nasty pde ui scenarios I'd like to add that, as long as there is the "custom-build" checkbox, there will always be people who use it. Making the resulting build.xml more resilient to location changes certainly is an improvement valuable for anyone using "custom build", even if it might not be perfect.
