Costin Manolache wrote:

I don't think package name is a good idea - you may have multiple packages, it doesn't allways match the project name,etc.


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

Is a mandatory version dir and a optional version suffix on artifacts ok?


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

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

Any download tool will need: - the name of the repository ( which implies the style of mirroring and
naming )
- 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
complex ).

Just trying to avoid collisions of project names, and help the URI have a long shelf life.

I am ok with using a common name, such as ant, maven, log4j.


Nick Chalko                                         Show me the code.
 Ant + autodownloadable build plugins + needed jars autodownload.

Reply via email to