Costin can you take the lead and put the ant jars for 1.5 up.
Any other projects leads please do the same.
Once this is started, we can move on to the intersting stuff.
My plan is, as I need a jar that is not published that way, I will bug the project in question to publish it.
Costin Manolache wrote:
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
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------