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