Ainsi parlait Berin Loritsch :
[..]
> I propose we borrow a number of conventions from the GNU
> "make" utility manual
> (http://www.gnu.org/manual/make-3.79.1/html_chapter/make_14.html).
Some other GNU conventions (not specilay related to make) that would be very
useful concerns naming.
It makes you sure version x.y.z of foo program is contained in a
foo-x.y.z.tar.gz archive, that will expand in a foo-x.y.z top-level directory.
Currently jakarta and xml individual projects use a mixture of version number
vs cvs tag (x.y.z vs x_y_z), of project vs group-project name (foo vs
jakarta-foo), of complete name vs shortname (xerces vs xerces-j), and case
(Xerces-J vs xalan-j) that make final users and packagers crazy.
Why not just state all archives should be named after the following
conventions:
project-version-bin.tar.gz (or .zip) for binary releases
project-version-src.tar.gz (or .zip) for source releases
project-version.tar.gz (or .zip) for mixed source-binary releases
And all should expand in a project-version top-level dir ?
It also concerns jar naming. Some projects use a main project.jar archive,
some other a project-version.jar. Additional jars case is worst: some use a
something.jar (ant optional.jar), some use projectSomething.jar
(xercesSamples.jar), some use project-something.jar. All these names are
either hard-coded directly in jar task, or set a property. Again, this is a
mess.
I would suggest to always use property for specifying jar names, using the
following conventions:
main.jar=${name}-${version}
optional.jar=${name}-${optional}-${version}
sample.jar=${name}-${sample}-${version}
etc...
Of course, i fully agree with initial proposition :-)
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
