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