ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <cstr...@arielpartners.com>
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?

--Craeg




Mime
View raw message