On Thu, 6 Mar 2003, Dirk-Willem van Gulik wrote:
> > Why not use the package name with '/' instead of '.', e.g.
> > org/
> > apache/
> > ant/
> > 1.5.1/
> > avalon/
> > commons/
> > httpclient/
> > 2.0/
> > etc?
> I'd like that structure - but still would argue that returning a piece of
> metadata is propably better - and taking thigns from there.
I don't think package name is a good idea - you may have multiple
packages, it doesn't allways match the project name,etc.
Metadata is a different issue - people should be able to get the .jar
directly, or get the metadata - there are 2 different URIs.
IMHO we should try to keep things as simple as possible. The only
important and critical decision is if we want version number in the jar
Most java projects ( including almost all Sun distributions ) don't
include it, and if this is to change we'll have some work to do.
Maven uses versioned jars, and it seems a number of people preffer this
One way or another - this has to be decided ( and I see no other way to
choose except for going with the majority ). If the decision
is to use versioned jar names - then we should start checking the code
and fix all the pieces where the jar names are used, modify the build
files to generate Classpaths with versioned numbers and figure out how
to deal with updates and bug fixes - since Classpaths in manifest or
code that references a jar with version number will need to use the
Any download tool will need:
- the name of the repository ( which implies the style of mirroring and
- the name of the project/component - which can be used to compute the
exact URI of the .jar and/or for the metadata.
- an optional version if a specific release is needed.
The only major problem is having the jar names in sync and working
with the project code. How the name of the project is translated into
a URI is not that important ( as long as it doesn't become too