Monday, July 16, 2007

Build Systems

I will admit to being a bit ‘old school’ when it comes to build processes… I will tend to use a tool like Ant that gives me a lot of control over how a project is built, and that is often launched from a command line… I’ve given Maven 2 a chance, and I like a lot of the concepts involved, especially that of Convention over Configuration, but I found that it requires a Herculean effort to do something as simple as building a JEE 5 compliant ear file – this is apparently what happens when the Conventions are based on a previous version of a spec you’re using (to be fair to the Maven 2 project, I found that my biggest frustration was with the documentation – my issues may certainly have been user error, and may be solved with a little better documentation, but my feeling is that it’s simply not there yet)

I’ve also worked a lot with the build processes inherent to Eclipse and NetBeans, but I have not used these for any projects that I collaborate with others on – I think this is mainly because I would prefer not to restrict people to just use my favorite IDE (which most people don’t seem to like – more on that later)…

I have worked most often in a system that uses a bit of both – the best setup for me seems to be one in which the primary build is a series of Ant scripts (Maven, or something else would fit just fine here), while developers are able to work in whatever IDE they like – if that IDE provides its’ own compilation system, then great, but the code that is compiled here doesn’t actually matter for anything, because the runtime system uses the class files created from the Ant scripts…

In some ways, this feels more like a compromise system to me than anything else, and it’s often difficult to get less experienced developers to realize that if their IDE is showing that they have an error, but the Ant script still builds, then it’s not a big deal (not to mention that a situation like that just seems a bit smelly anyway)…

Do other projects work in this way, or is there a ‘better’ way, in which both the IDE and the build scripts use the same class folders? I’m willing to bet that this is doable, but I haven’t had the opportunity (or patience ) to pursue it yet…

4 comments:

mkleint said...

in netbeans, the maven project will be actually recognized by the IDE and the IDE builds using maven. check http://mevenide.codehaus.org/m2-site

Matt Corey said...

Interesting, I'll have to look into this... my first reaction is to say "great, but Maven can't even build a standard JEE ear without spending a week of customizations", but perhaps this is unfair... can anyone comment on this issue? Last I tried it a few months ago, Maven would not build an ear without an application.xml, which is no longer required with JEE 5...

Alex Miller said...

I've done the shared class folder thing between Eclipse and Ant and it's worked well for the most part. I use ant4eclipse to create classpaths in Ant based on the Eclipse .classpath files, so I only maintain the classpaths in exactly one place.

I've also worked with a build system where the automated build was based on the Eclipse build process. That kind of worked but was a bit error prone.

The holy grail is definitely to have an automated build process and an IDE build process that are as close as possible to each other. The farther apart they are, the more time you spend debugging weird stuff that fails in one but not the other.

Matt Corey said...

Now that you mention it, I have seen ant4eclipse, but I haven't experimented with it at all... I will have to give it a go-round...

Wasting time chasing weird bugs really goes to the heart of the problem -- in my experience, every 5 minutes I spend with someone explaining why a compilation bug in Eclipse doesn't mean anything to the Ant scripts is also probably at least 30 minutes of that person tearing their hair out trying to figure it out themselves :)