(Sorry about the formatting - at least it's not HTML...)
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> On Fri, 4 May 2001, Peter Donald wrote:
>
> > I know it can be easier to upport if you rely on filename
> versioning - as
> > long as it is turned off by default and the versions only
> appear in the jar
> > distributions I don't see any problem with it. Especially
> when cjan gets
> > going as filename embedding of version numbers will
> virtually be required -
> > unless someone thinks of something brilliant ;)
> >
> > However as Craig saids - it is a PITA for developer if jar
> keeps changin
> > names ;)
> >
> IMHO version information belongs *inside* the JAR's MANIFEST.MF file
> (where it can be checked by tools), not outside. We're already doing
> that, and CJAN etc. can certainly be programmed to extract that and
> display it on the download pages.
I agree it belongs inside the manifest - but the two aren't exclusionary.
For developers, you just keep it as commons-collections.jar so you don't
have the classpath problems or brittle/broken configurations, as you pointed
out.
> Having been bit by the "commons-collections-*" style of classpath
> building, and ending up with multiple versions of the same
> JAR file, I shy
> away from this approach at all costs.
Right. Agreed. I don't know if you read through my posts that Peter was
responding to - having the target that produces a version-filename jar would
exists for 'mere mortal' downloads for support reasons, and another
versionless filename for developers. It can be 'harder' for developers
(like 'ant devjar' or something :)
> > >BTW : is it possible to override the default target in
> build.properties?
> > >That way the default target in the build.xml can build the
> 'user' targets,
> > >and you can override for development.
> >
> > I would prefer it the revers - only the equivelent of
> "distributions"
> > target embeds version. Considering it already has to do
> special property
> > manipulation to change dist directory name this shouldn't
> be a problem.
> > (see ant or avalon build files for an example).
> >
>
> We can override any property you want, but we need a build
> process that
> is intelligible to mere mortals, or we end up with "Building
> Commons is
> Hard!" ...
?
I was asking if it was possible to overried the default target in the
project tag, so a mere mortal can just type 'ant' and get something useful
because the default target in build.xml does the right thing for 'mere
mortals', and a developer can override the default target in the
build.properties to prevent the named jar creation.
To summarize, I am not too hot and bothered by this subject - just fear that
as the number of parts grows (and we are growing very fast), and the
audience for these parts grows (broad and deep in their usefulness -
everything from the generic [collections] to specific [Cactus]), that user
support will be a nightmare if the 'average user' has to do extra work to
figure out the versions of things people have problems and questions about.
geir
