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 ;)
>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).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
