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:
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
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...
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.
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 :)
Post a Comment