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