We have the same issues, but we also have some additional requirements for our build environment:
The <projectdependencies> task is another matter. I understand (all too well) the problem you are trying to solve: build repeatability. This area includes requirements such as:
- record the versions of every project/technology upon which your project depends - sort out the dependency tree-- make sure there are no incompatibilities or conflicting requirements among subprojects/technologies
Exactly - this is precisely what it does.
All buildmasters must solve this problem, one way or another. The issue I have with <projectdependencies> is that it makes assumptions about how the build environment is organized and essentially implements a management policy.
It does to a degree - in posting it I was hoping to get this sort of feedback to hopefully make it more customisable and "policy free". I would be very interested to know how other people arrange there development environment and see if I can incorporate flexibility enough to incorporate those as possibilities, by making projectdependencies more flexible.
- must be able to build while on the road (plane, train, etc.) disconnected from servers
- must be able to build on "any" platform (where any in { mac OS/X, Win32, Linux, Solaris, etc } )
- must be able to use client equipment where we do not have root/administrator priviledge.
We therefore concluded that the most we can count in is a SINGLE DIRECTORY. Therefore,
we created the concept of $TOP. $TOP is a "root context" within which we copy all
technologies upon which we depend. In this way, we can actually use a specific version of jboss,
tomcat, cocoon2, saxon/xerces, JDK, netbeans, Ant, etc. etc. -- all the while leaving the client's machine with its
configuration totally undisturbed. When we leave, we simply remove $TOP and we are done.
What we need, therefore, is a tool that enables us to copy the _relevant portions_ of our tools and
technologies into $TOP (often a single jar file) and to create a manifest file such that:
- we always know which versions of everything we are using - can verify and validate the environment - can upgrade/downgrade/install/remove technologies easily
Does this sound an awful lot like RPM (Redhat package manager)? We thought so, too-- but
found to our chagrin that it is really problematic to use in this way, on all these platforms. We are therefore considering designing and building
a new Java-based package manager. Interestingly, it could reuse many of the Ant Tasks.
We are looking forward to Ant 2.0 and pluggable Tasks which should make this much easier.
I went into some detail here to illustrate my point about policies-- our policy is clearly different from
yours, for good reason (our additional requirements). There are, however, interesting common requirements
in the area of package management. What do you think?
--Craeg
