commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@zenplex.com>
Subject RE: property naming (Re: cvs commit: jakarta-commons/digester bui ld.properties.sample)
Date Thu, 21 Mar 2002 19:01:13 GMT
On Thu, 2002-03-21 at 13:55, Craig R. McClanahan wrote:

> 
> As long as the Ant property names themselves do not include the version
> numbers, the scheme would accomodate filenames that do.  But, for the
> defaults (i.e. in build.properties.sample) the unversioned version of the
> names should be used.

So you are actually swapping a JAR when you change it? So if you have a
project that requires has moved from v1.1 to v1.2 of foo.jar what do you
do with the v1.1 of the jar and what do you do if you have a project
that requires v1.1 of foo.jar?

Do you keep a directory structure with version numbers and version jars
with no version numbers contained within that structure? I am trying to
figure out a document that describes a JAR repository. The way Maven
works both methods would work: a versioned directory structure with
versionless jars, or a single directory with versioned jars. Even if the
version is in the manifest, if you want to store more than a single
version of the JAR you obviously can't put them in the same directory.

The JAR repository could be made to work both ways. If it's on a unix
machine symlinks could be used on the server and if this was to cause
problems on a windows machine they could be duplicated I suppose.
 
> Personally, I think version numbers belong inside the JAR (in the
> META-INF/MANIFEST.MF file) where tools can get to them reliably, rather
> than in the filename itself, where users can easily mess them up.  It
> should be up to a repository system (JJAR, Maven, whatever) to grab me
> version x.y of foo.jar when I ask for it.

Then it is just a matter of how you store them. You need to store by
version in some fashion or other.

> But the naming convention works either way.
> 
> > - Gidado
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


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


Mime
View raw message