commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: property naming (Re: cvs commit: jakarta-commons/digester bui ld.properties.sample)
Date Thu, 21 Mar 2002 19:25:08 GMT


On 21 Mar 2002, Jason van Zyl wrote:

> Date: 21 Mar 2002 14:01:13 -0500
> From: Jason van Zyl <jvanzyl@zenplex.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@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:   <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
>

Craig


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