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

Costin



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

Reply via email to