Hi Mike, met you at your seminar at "No Fluff Just Stuff" earlier this month in Chicago.
Here's a question I have pondered many times and before I go off half-cocked and create a half-xssed solution again, I want to run this one by some knowledgeable people.
I am on a small team that is building a project that runs in
JBoss. Our development environment of choice is the JBoss
IDE inside Eclipse. Our project consists of a main war file, and some EJBs packaged in an
EJB jar. Shared by these two is a common jar that is built separately.
Up to now, it has been fairly painless to simply develop and deploy onto local jboss servers owned by each developer. Nice, fast, responsive, includes debugging, a great tool. But now that we move toward production, the need for an automated build becomes apparent as always, and the quick and dirty builds done by Eclipse and the JBossIDE's "Run Packaging" command are not going to cut it much longer.
Now, I could easily throw together an
ant script for an autobuild that would do all of what needs to be done, but the problem here is that now you've got two build processes to keep in synch, which is a maintenance problem in and of itself. So I would like the autobuild to somehow sit on top of the packaging-build.xml files that the JBoss IDE makes. But these, unfortunately, rely on hardcoded paths on the user's machine rather than on ant variables that could be set somewhere.
I suppose this is a limitation you run up against when you rely on the convenience of an IDE build. But has anyone ever created a system that can work either in the IDE or the automated context? So that, for example, a classpath change to the IDE build would automatically be propagated to the automated build?