Re: [proposal] URI format

[Nicola Ken Barozzi <ni...@apache.org>]

I'm reposting what I percieved was the last decision on this list, now 
that others are listening and that needs have arisen.

The main part here is that there is mirroring in place, which is 
important for us. And as Nick has already said, it's the "lowest amount 
of change that will work".

Please read all of it, in the end it comes out that this seems a 
Maven-compatible repository!

Costin Manolache wrote, On 10/03/2003 19.05:
> Here's my proposal: 
> 
> 1. The .jars and other artifacts ( docs, wars, etc ) will be distributed
> in the same layout and directory structure with the regular Apache 
> files, based on the rules for mirroring ( http://... ).
> Each project may add a jars/,  wars/ directory next to ( or below ?) bin/.

What is preferred? What mimics the most the Maven format? (IMHO "next 
to" is better)

> 2. Each jar in the repository will be versioned, with a symbolic link
> to the latest released stable version and a symbolic link to the latest 
> milestone. 
> The "latest stable version" will be referenceable by both the simple jar 
> name ( the symbolic link ), and by the full versioned names. Same for the 
> latest milestones.

This makes it very easy to always get the latest without having to list 
the files in the repository.

> 3. The symbolic name should be changed on every incompatible API or major
> release. Projects should be able to deal either with full 
> versioned names, or at least with major-version names. Example: 
> catalina5.jar will be used as the "base names". 
> First-version projects or projects where backward compatibility is 
> strictly enforced will not have to use a version ( we can keep the 
> current names for existing projects ).

This has a reason that I understand, because it easily makes it possible 
to get the latest compatible version of a library.

But -

usually major versions are used for this. That means that if I need the 
latest ocoon-2.x.x.jar, I can get it specifying the major version.

In the end, IMHO it's not something that needs to be specified, it just 
depends on what the project changes really entail. Sometimes even a 
minor change can make APIs incompatible, so it all boils down to what 
projects prefer.

Hence -0

> Why:
> Using the mirroring layout:
> - the mirror system seems accepted and is already implemented in most
> projects
> - jars and wars and .sos and other project artifacts are part of the 
> release, there is no reason to treat them differently

And we get mirroring "for free", greatly alleviating bandwidth usage.

> Versioning:
> - it is clear that both verioned and unversioned jars have valid use 
> cases.
> - unversioned jars can be used in projects where the use case applies -
> for example if ClassPaths are used in jars or if file-based access id
> done for any reason. 
> - Using the latest stable version guarantee that upgrades will get the
> bug and security fixes and get maximum stability
> - Upgrading to the latest milestone will allow people to benefit from
> recent features and deal with API changes. ( again - the stable name 
> will keep the process predictible )
> - It seems this practice is acceptable in maven 
> - Versioned jars will be available to satisfy Maven's use case - people
> building or running against a fixed version of a particular software.
> 
> 
> Major version number in jar names:
> - it'll allow people to use/build projects depending on multiple 
> versions
> - it'll help the use case of tomcat or other containers where multiple
> versions may be used at the same time. We still want to use the latest 
> minor version out of each major version - for security and bugfix reasons.
> - it'll allow people to deal with the API changes
> - stable and existing projects can keep the current simple name

How would this differ from a Maven Repository?

Repository:
    http://www.ibiblio.org/maven/

Projects:

   ${repo}/project1/
   ${repo}/project2/
   ${repo}/project3/

Artifacts:

   ${repo}/${project}/distributions/
   ${repo}/${project}/jars/
   ${repo}/${project}/licenses/
   ${repo}/${project}/poms/

So:

   ${repo}/${project}/${artifact-type}/${artifact}


In this proposal:

Reference:
   http://www.apache.org/dev/mirrors.html

Repository:
   http://www.apache.org/dist/

Projects:

   ${repo}/project1/
   ${repo}/project2/
   ${repo}/project3/

Artifacts:

   ${repo}/${project}/
   ${repo}/${project}/binaries/
   ${repo}/${project}/source(s)/
   ${repo}/${project}/old/

So:

   ${repo}/${project}/${artifact-type}/${artifact}

Hey, the layout is basically the same!!!!

The only thing that changes is that here there can be files in 
${repo}/${project}/* while Maven doesn't have them there.

So, what about starting simply to publish jars in the mirroring system?
We can easily make the mirroring cgi script handle us the correct jar 
from mirroring, the code is really straightorward.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------