ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <>
Subject Re: TASK SUBMISSION: jspc and projectdependencies
Date Fri, 14 Sep 2001 04:31:26 GMT
>>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.
We have the same issues, but we also have some additional requirements 
for our build environment:

- 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?


View raw message