>Eclipse Build Process

>Why does eclipse require eclipse to build eclipse?

I’ve never gotten a really satisfactory answer to this. It seems counter productive to me for projects to depend on eclipse to build eclipse plugins. What if you need to rebuild an entire platform from scratch, including all jni related code? I understand that there are property files and classpath files that need to be set, but is eclipse really required to build eclipse?

There are two types of builds I see:

1. Complete System rebuilds – these may include incremental builds and clean builds of all related plugin projects.

2. Packaging Builds – which take the pre-complied packages already generated and combine them into one standard package.

In my opinion neither one of these methods should require an existing working eclipse platform to build eclipse itself. It’s extra memory and over head. Two open source projects that help eleviate this need are:

  • Ant 4 Eclipse is a project that allows the ability to read the various eclipse configuration files to help build eclipse projects without requiring eclipse to run headless.
  • Custom Eclipse Builder allows you to specify a build of existing packages to create a custom package or distribution of eclipse with your specific plugins.

There are other packaging projects available like EasyEclipse and the Eclipse Packaging Project. However, I haven’t tried either of these for a headless build system. Maybe during e4, the entire build process needs to be revisited?

Continuous Integration Systems:

Continuous integration or build systems are something I can’t live with out combined with Unit Tests and User Acceptance Tests (something that eclipse is lacking as unit tests and user acceptance tests aren’t the same thing) are a powerful combination. I’m going to give some kudos to one build system that doesn’t get much press but it deserves more mention. It’s the open source version of Luntbuild. I personally find the Web User Interface and usability much better with Luntbuild than I do with Cruise Control or Ant Hill.

Ultimately continuous integration systems come down to the personal preference of those that are using them, but Cruise Control didn’t really make me go wow. Luntbuild did.

This entry was posted in agile, eclipse. Bookmark the permalink.

9 Responses to >Eclipse Build Process

  1. >So to keep my answer short… nothing but Eclipse itself understands how to build plug-ins. Plug-ins are special.However, that shouldn’t keep us from investigating new ways to make the build process in Eclipse much easier.

  2. dcarver says:

    >Chris, I’ll respectfully disagree as the Ant For Eclipse project shows how to package/compile plug-ins.http://ant4eclipse.sourceforge.net/ant-for-eclipse-tutorial.html

  3. >So, the issue here is that in order to properly construct classpaths you need to have access to the OSGi state which properly sets up access rules for the compiler and all that good stuff. Sure you can fake this type of stuff and try it on your own… but why not just use what is available to you :)?I think the main issue is the consumability of PDE Build. For example, pluginbuilder.org provides a good user experience for PDE Build… if that was there today… people wouldn’t complain.

  4. >One of the goals of PDE is to get the build time environment as close as possible to the runtime environment. This helps avoid nasty surprises later. With simple bundles and simple requirements you can achieve this easily enough by manually writing your classpath. More complicated requirements can perhaps be managed with Maven or other build technologies. However, when you have complex bundles that use OSGi in all its glory, I don’t see how you can get the classpath right without reference to an OSGi state.Packaging builds are an easier proposition and I can see this being accomplished without OSGi if you know the full list (with versions) of what you want.

  5. steve.taylor says:

    >At Openmake Software we have a process to automate PDE builds from inside or outside of Eclipse. The information is there to do it without the need to write Ant or Maven script but to generate them. The plug-ins are not special themselves. A simple plugin is simple to build. But plugins that are dependent upon other plugins and so on are beyond a manual process and has to be automated.

  6. David Carver says:

    >Thanks for the feedback guys. I still think that there is a way to handle the OSGI state with out having to ahve OSGI running. It looks like Ant For Eclipse has accomplished some of this by making sure there ant tasks implement the osgi rules, as well as leverage the eclipse java compiler.Eclipse is the only java program that I’m aware of that requires a running version of it self to build itself. I plan on working on automating my own builds and will post another blog entry with my findings.

  7. Kurt says:

    >If you like automated build systems then take a look at Hudson which can be found at: https://hudson.dev.java.net/

  8. Neale says:

    >Thanks for the ref to Luntbuild, which I chose over CruiseControl for Whirlwind (on sf.net).I’m using TeamCity at work, and looking to Eclipse to see if we can solve some of our problems.We don’t want a TC project for building each component… something I’m sure Eclipse has had to deal with

  9. David Carver says:

    >@Neale: Glad you like Luntbuild. I like the interface and options better than cruise control. 1.4.2 has been the most stable for me, haven’t taken a look at the most current versions yet though.

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s