On Fri, 4 May 2001, Peter Donald wrote:
> At 08:21 4/5/01 -0400, Geir Magnusson Jr. wrote:
> >However, I still think my concern if valid. In the happy event of us
> >getting component users that don't also happen to be jakarta committers
> > people who may actually use the jars in environments different than the CVS
> >tree :->) why not have more than one build target? The normal user
> >dist/jar target adds the version number and a 'developer' dist/jar target
> >builds w/o appending the version. That way we can have the nice build setup
> >where a cvs update and a build will update the developer environment w/o
> >having to mess with build.properties, and for a user, its easy to see what
> >jar is what when deployed out to webapps, apps, and whatnot.
>
> 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.
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.
> >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 also note the precedent of standard Java packages -- take JAXP for
example, where "jaxp.jar" and "crimson.jar" do not have version numbers in
the filenames -- as well as many other packages (Xerces does the same
thing).
> Cheers,
>
> Pete
>
Craig
