Eclipse Headless Build Thought

I have been working recently on the build automation of our Eclipse’s project. Manually generating pacakages was boring, not safe and time consuming !!!!

Starting from web resources I quickly front of the part of the build related to the fetching of sources from a remote repository. In our case, we are not using CVS/SVN but Clearcase UCM.

Of course I can’t use ant GET target to fetch my sources from Clearcase but that is not a problem because I want to build the current version I have locally on my hard drive (== my working copy).

Eclipse’s help says here that I can manually retrieve my source within the customTargets.xml script (in the postSetup target). Fine !!! All I need to do is to use COPY ant tasks to “fetch from my lcoal hard drive” my sources into the directory that will host the build.

I decided to start to automate the build of my SDK feature. Starting from here I modified the postSetup target to copy my SDK feature and my feature (included by the SDK one) into the build directory. Then I had also to copy all the feature’s plugins. After long time  and several launch of my build script to see step by step which plugins where missing I finally was able to build my feature.

All this boring work (developers are lazy guys :o) ) made me think that it would be nice to have the eclipse.fetch target able to fetch plugin from a local directory. This way, as in the case of fetching from CVS, what we have to do is just says where to find locally plugins and features through a map file containing local paths. Eclipse will be responsible to get required elements to build the feature according to the feautre.xml file.

What do you think about that, anyone already reached this problem ? May be this feature is already existsing … ??? I guess the map file is read by Java code, I’ll try to step in Eclipse code to see if it’ll be possible to implement such feature …

I was wondering how Eclipse’s projects developers can build a feature using sources not commited yet to a CVS repository … In fact I guess they/you face the same problem I described … ???


This entry was posted in Uncategorized by Manuel. Bookmark the permalink.

6 thoughts on “Eclipse Headless Build Thought

  1. Did you look at the pluginPath property in Maybe it can work for your case:

    #pluginPath is a list of locations in which to find plugins and features. This list is separated by the platform file separator (; or :)
    #a location is one of:
    #- the location of the jar or folder that is the plugin or feature : /path/to/foo.jar or /path/to/foo
    #- a directory that contains a /plugins or /features subdirectory
    #- the location of a feature.xml, or for 2.1 style plugins, the plugin.xml or fragment.xml

  2. Hi Richard,

    Yes I looked at this property, but it seems Eclipse is building things directly in the pluginpath directory and doesn’t copy plugins found other there in the build directory. Do you confirm

    More over we had troubles to have things working correctly for several heterogeneous environements (linux/windows, different paths) when using pluginpath, that is why we decided to copy all needed plugins in the build directory the same way Eclipse projects do by fetching from CVS ….

  3. Yes, bundles will be built directly in the pluginpath directory.

    PDE/Build has an extension point where different map file entry format can be contributed. (This is where the support for SVN comes from).

    Build provides a “COPY” extension. Your map file entry would look like:, ,
    which results in a copy from root/element, if element is not specified, then you end up with copy from root/

    For any additional details, you’ll probably need to take a peek at the generated fetch script which results from using this.

  4. Pingback: Eclipse Headless Build Facts « Manuel Selva’s Eclipse blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s