ATTENTION: This blog has moved to a new location. Please update your bookmarks, browsing habits, and aggregators.

	Friday, April 18, 2003

A Thought on Software for Software Development This post (and this weblog) has a new home. The maturation and growing ascendency of Maven in the Java open source community and recent JDJ article by Franz Garsombke have me thinking about build systems and more generally about software development process and quality.  (Never mind my recent displeasure with JDJ for dropping the integration category of the "Reader's Choice" Awards at the last minute and moving our business process integration product into the application server category without so much as a whisper to let us know; we asked to be removed from consideration instead of competing in an inappropriate category.)  Franz's article is a nice overview of the build/continuous integration system that he put in place at Global Healthcare Exchange, and it sounds like the build system that we've built-up over the past few years. There is an opportunity to create a build system product, and I know that there is a long line of people willing to pay for the perfect build system.  Perhaps something like Maven will fit the bill, since the necessary level and frequency of customization would demand an open source (but not necessarily free) product.  (I'm waiting for good documentation on the Reactor plug-in, since we work in a multi-project environment, and it looks like it's finally there.)  We've passed our internally developed build system on to some of our larger customers for use on their own projects. I can boil the abstract idea of the ideal build system down to three principles: A software application should be the output of an autonomous program. The program and its inputs should themselves be the output of an autonomous program.  A version-controlled object and the "get version" program are the only initial inputs. "Autonomous" is used in the sense that the program should return exactly the same output when provided with the same input.  The "get version" program might be a check-out or it might be something like downloading a specific Java version. These principles would be satisfied by something like a CVS checkout that retrieves a version of Ant, a version of Java, and an Ant script that then performs additional check-outs, compilation, etc.  The third principle is subtle but extremely important.  For example, a newer version of Ant shouldn't be used to compile an older version of the software application. 10:55:53 PM

Personal Reverie on the Perfect IDE This post (and this weblog) has a new home. As a user of both IntelliJ IDEA and Eclipse, I could easily take either side in the debate as to which is the better IDE for Java development.  Ant, JUnit, CVS integration in the IDE are all Good Things, what I really want is IDE integration in Ant and not the other way around. More concretely, instead of being able to run Ant against a set of Java source files with defined classpaths and other environment settings, I would like to work with either a set of Java source files appropriate to a specific Ant task or Ant target with classpath and other parameters drawn from the build file. 8:25:47 AM