RE: property naming (Re: cvs commit: jakarta-commons/digester bui ld.properties.sample)

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 21 Mar 2002, Immanuel, Gidado-Yisa wrote:

> Date: Thu, 21 Mar 2002 13:21:34 -0500
> From: "Immanuel, Gidado-Yisa" <av...@cdc.gov>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: 'Jakarta Commons Developers List' <co...@jakarta.apache.org>
> Subject: RE: property naming (Re: cvs commit: jakarta-commons/digester
>     bui ld.properties.sample)
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Thursday, March 21, 2002 12:36 PM
> ...
> > commons-collections.jar=${commons-collections.home}/commons-co
> > llections.jar
> >   commons-logging.home=../logging/dist
> >   commons-logging.jar=${commons-logging.home}/commons-logging.jar
> >   junit.home=/usr/local/junit3.7
> >   junit.jar=${junit.home}/junit.jar
> >
> > So, the proposal would be to change this to the following:
> >
> >   commons-collections.jar=${lib.repo}/commons-collections.jar
> >   commons-logging.jar=${lib.repo}/commons-logging.jar
> >   junit.jar=${lib.repo}/junit.jar
>
> Could you use naming conventions like:
>
>    commons-collections.jar=${lib.repo}/commons-collections_1.2.jar
>
> to refer to the explicit version (1.2 in this case) of the jar?
> Whereas, the following line:
>
>    commons-collections.jar=${lib.repo}/commons-collections.jar
>
> would mean you're using the latest and greatest build (probably
> something built off of CVS MAIN, but *not* a symlink to a
> versioned jar)?
>

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.

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.

But the naming convention works either way.

> - Gidado

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: property naming (Re: cvs commit: jakarta-commons/digester bui ld.properties.sample)

["Craig R. McClanahan" <cr...@apache.org>]

On 21 Mar 2002, Jason van Zyl wrote:

> Date: 21 Mar 2002 14:01:13 -0500
> From: Jason van Zyl <jv...@zenplex.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: property naming (Re: cvs commit: jakarta-commons/digester
>     bui ld.properties.sample)
>
> 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?
>

My normal approach is to maintain a directory structure of
production-level package distributions for all the stuff that I use
(/usr/local/commons-collections-1.0, /usr/local/jakarta-struts-1.1b1, and
so on).  Thus, the version number is baked in to the directory rather than
the filename.  In addition, the documewntation and Javadocs are
conveniently available as well -- not just the JAR file -- and it scales
to packages that are larger than a single JAR as well.

The appropriate properties for these packages are all set in my
${user.home}/build.properties file, so they become my defaults for all
uses, unless I override them.

If a particular project needs a different version of something, I just
create a build.properties in that source directory, with just the
"exception to the rule" properties.

Given this, I can download and build a new source repository with zero
setup, unless it has a dependency that I don't already have on my
computer, or if it needs a version different from my default for that
package.  In those cases, I either download the package and add it to my
${user.home}/build.proeprties, or set up the per-this-package
build.properties, as needed -- but I only have to deal with exceptions,
not the entire set of dependencies.

> 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.

Yep.

>
> > But the naming convention works either way.
> >
> > > - Gidado
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: property naming (Re: cvs commit: jakarta-commons/digester bui ld.properties.sample)

[Jason van Zyl <jv...@zenplex.com>]

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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>