JJAR in jakarta commons already uses xml descriptors.
CJAN developers are using it for a frontend to their peer2peer distribution system.
Kurt Schrader wrote:
After talking with a number of people at Apachecon, I have come up with a proposal for an improvement to the way that we distribute jars. The current method of downloading, renaming, and then uploading every jar that we need is not sustainable in the long run, because of the large amount of work involved with adding a new jar to the repo. I would instead like to propose the adoption of a collection of small xml files that represent each of the jars instead. This would change the search path for a jar from[Check local repo] -> [Get from remote repo] to [Check local repo] -> [Get XML descriptor file] -> [Get from remote repo] An example of what one of these xml files would consist of would be something like: torque-3.0-rc2.xml: <distribution> <id>torque</id> <version>3.0-rc2</version> <jarLocations> <jarLocation>http://www.ibiblio.org/maven/torque/jars/torque-3.0-rc2.jar</jarLocation> <jarLocation>http://jakarta.apache.org/turbine/torque/jars/torque-3.0-rc2.jar</jarLocation> </jarLocations> <md5sumLocations> <md5sumLocation>http://www.ibiblio.org/maven/torque/jars/torque-3.0-rc2.md5</md5sumLocation> <md5sumLocation>http://jakarta.apache.org/turbine/torque/jars/torque-3.0-rc2.md5</md5sumLocation> </md5sumLocations> ... </distribution> This file would be automatically generated whenever the jar goal is run in maven. The advantages that this extra layer of indirection would afford would be: 1. Projects not using maven to build could continue naming their jar files however they like. The intermediate XML would simply point to them and we could rename them to the Maven standard jar file naming conventions during the download process. We would get all of the advantages of the filenaming and repository we have now, without forcing other projects to follow our guidelines. 2. We would abstract the support for mirroring away from the user and keep it centralized. Different projects could have their own set of mirrors, but they would all be resolved from the xml file that we control. 3. The amount of bandwidth and disk space needed to mirror the maven jar repo would go down tremendously, as we would only need to mirror the xml files, not a huge collection of renamed jars. 4. The central download point for the maven jar repo could move back to Apache, as we would no longer be hosting jars that have an unacceptable license. This would also allow us to eventually open up the directory we would be using to store these xml files in to maintainers of any number of projects to maintain their own descriptors. 5. It would give us the ability to change things for future versions of Maven without breaking backwards compatability. If the need to add a new tag to the intermediate descriptor file arises for use with a future feature, then we're free to do that. 6. If a security problem is found in one of the jars, we can handle it gracefully by replacing the foo-1.0.xml file with a special version containing a message that the file has a security hole and is no longer available. Right now we would just have to delete the file, which would break everyone's builds with no explaination of why. We could have also used this feature to clean up the xmlParserAPIs mess that we ran into last week. Comments? -Kurt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
