On Mon, 10 Mar 2003, Nick Chalko wrote:
> Excelent, lowest amount of change that will work, solution.
> So how do we go about encouraging projects to publish there jars.
How did we go about encouraging projects to use the mirror spec :-) ?
I think first we need to agree on this list that we can all live with
this, then extend this to [EMAIL PROTECTED]
This is only 1/2 - the other part is finding a middle ground on the
> Costin Manolache wrote:
> >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/.
> >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
> >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.
> >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 ).
> >Using the mirroring layout:
> >- the mirror system seems accepted and is already implemented in most
> >- jars and wars and .sos and other project artifacts are part of the
> >release, there is no reason to treat them differently
> >- it is clear that both verioned and unversioned jars have valid use
> >- 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
> >- 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