Hi,
Yes, we discussed this issue, here on jakarta-commons, last week ... :-)
As I mentionned earlier, I really don't like the version in jars because :
* it messes almost all the tools. For example, let's imagine you're in
JBuilder. You create a library that points to commons-httpclient-1.0.jar.
Then comes the 1.1, you need to edit all the places where you references the
jar
* you need special cases to handle nightly builds. It is even worse than the
above mentionned point because you need to change the reference every day
* there is a standard way : using MANIFEST files. As a user, the repository
is something opaque, I don't care how it is managed internally, I just want
to ask it for a given version and it returns the corresponding jar (without
version name). It could easily be implemented with version in directories.
My opinion.
-Vincent
----- Original Message -----
From: "Jason van Zyl" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 22, 2001 9:05 PM
Subject: Naming JARs
> Hi,
>
> I'm sure this has surfaced in the past, but can we discuss a standard for
> naming JARs. Right now I am trying to use a JJAR-like task and the
lib.repo
> method for building and I have the following patterns in use:
>
> project.jar
> project-Major.Minor.jar
> project-Major.Minor.Patch.jar
>
> The automated build I think would work better with version numbers in the
> names of the JARs: it clearly identifies what it is, it additionally
allows
> you to keep a set of jars in the same directory.
>
> So a project descriptor would state what the released version of package
is
> to be used for a build. The project descriptor could also state what the
> latest version of a package is so that could be used if desired. There
could
> also be some local configuration to mix & match these so I don't think
> naming the JARs will be a maintenance problem if it's all taken care of by
> the automated build system. The majority of the JARs I'm using right now
> have version numbers in the names of the JAR.
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
