ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: Jars in CVS ??
Date Fri, 24 Nov 2000 19:38:04 GMT
on 11/24/2000 11:00 AM, "Craig R. McClanahan" <>

> Actually, it was Sam Ruby that convinced me that putting JAR files into CVS is
> a
> "Bad Thing".  I will let him make the detailed arguments when he has a chance,
> but the key problems are:
> * You always forget to update the stored JAR files
> * Nobody knows what version of the dependent JARs should be used
> * What happens if I have my own xyz.jar that I want to use instead
> of the packaged one?
> and on and on.

How about the positive things for putting .jar files into CVS:

* Users are required to locate and download N number of .jar files (with
Turbine that is now well over 10).
* Having .jar files in CVS allows people to easily get up and running with
just the CVS version of the software.
* It provides version control over which versions of the .jar files are
acceptable for the product.
* It allows people who are using the CVS version to be notified when a new
.jar file or version is required because they see it in the U message from

Sure, you do have to update them in CVS, but it really isn't that hard and
isn't any harder than requiring ALL of the people using your software to go
download newer versions.

> On the other hand, I'm a huge believer in creating distributions that include
> all
> the relevant JAR files.  On that note, the Tomcat binary distribution picks up
> everything you need except a JDK, and except for the JSSE classes (you
> wouldn't
> believe the paperwork it takes to do that one :-).  And the Tomcat build
> process
> even lets you pick things like which XML parser to use, rather than forcing
> you
> to use whichever one was in the CVS tree.

Right, I believe that as well, but some people also like to work from CVS
and at least with Turbine, we don't have a release distribution. Yes, we are
releasing the TDK as alpha versions with the .jar files in it and that is
great, but the TDK actually gets it's .jar files from Turbine.

> For Ant, the right strategy would be to publish builds of the "optional.jar"
> file, or portions of it, on the Jakarta web site whenever significant changes
> occur in between Ant releases.  That way, people can go grab the stuff they
> need,
> without having to build it all.

People who work behind closed doors don't care how hard it is to build it.
That is the fundamental disconnect here I think.

In open source, building it should be as easy as downloading it. By making
building the software easy, you are encouraging people to actually develop
the software further and that is a good thing IMHO.

Once we made building Turbine painless (by checking all the required .jar
files into CVS), more people became interested in it.



twice of not very much is still a lot more than not very much

View raw message