avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Excalibur ant.properties.sample
Date Thu, 28 Mar 2002 10:05:34 GMT
On Thu, 28 Mar 2002 20:30, Leif Mortenson wrote:
> >>Also, what do you think about creating a lib directory in the root where
> >> many of these jars could be placed by default.
> >
> > Placed there by us (checked into CVS) or users?
> I was thinking that it would be good to have them checked in.  It increases
> the size of the distribution, but it makes it so much easier for new users
> to get up and running. The jars wouldn't change often so it shouldn't
> affect update times at all once they are checked out.

Well if you can handle holding off for a few weeks we may be able to avoid. 
If we adopt maven then it will download the correct jars (if needed) into a 
central location and we wont need to keep jars in CVS. Even if we don't adopt 
maven we can add in a auto-download capability to our build scripts.

The reason I am reluctant to do it is because of something that happened in 
the phoenix module. A while back I downloaded phoenix and couldn't get 
certain features of parser to work. Anyways it was because some one had 
checked in a different parser into tools/lib/* or tools/ext/* or something. 
And this broke phoenix which had been using a library compiled against a 
different version of parser.

Then the next week I did the same and it was broken again because of a 
mismatch between jars stored in phoenixs lib and jars stored in tools/**. 
Then the same thing happened to cornerstone CVS, and phoenix CVS again.

At that point I decided to never use the build.* scripts ever again and so 
far I have only had one jar mismatch problem and all has been good. 

Sometimes checking in jars is fine if they are unstable or you need a 
specific snapshot. But for jars like xerces/xalan/ant/junit which are stable 
I don't think its a good idea. 

If we can integrate an update-jars functionality (via maven or otherwise) 
then I think that would still keep things easy. It would also make things 
much easier to manage in long term IMHO.



First, we shape our tools, thereafter, they shape us.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message