Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-ID: <3BA1881E.3040800@arielpartners.com>
Date: Fri, 14 Sep 2001 00:31:26 -0400
From: "Craeg K. Strong" <cstrong@arielpartners.com>
Organization: Ariel Partners LLC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: TASK SUBMISSION: jspc and projectdependencies
References: <002e01c13b40$7cf066c0$0700a8c0@arunta.com.au>
 <3B9FC742.3010805@arielpartners.com>
 <004801c13bf1$0bc12910$0700a8c0@arunta.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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