Brett Porter wrote:
Hi Ralph,
You've got a general versioning problem here, and you'll find the answer
to "how do I do this with Maven?" will be more straightforward once
considering the question of how you should generally deal with them. As
you've said, this is already a problem for you as you don't know where
they really came from.
This is broader than just versioning, it is a "how do OSS projects do
coordinated releases?" kind of problem.
In the closed source world, everything targets a single release
milestone and either comes in on time (I'm trying to think of an example
but it escapes me) or horribly late (Vista)
In OSS-land, everyone just pushes releases out when they feel like it,
ideally with some kind of testing/QA stage. Then the downstream projects
take it, finally it is considered stable enough to go into the
"Enterprise" linux distros. Projects like fedora and SuSE get to be more
timely by bundling beta release versions of many things and skipping on
the testing.
This release process *appears* to work, at least as long as you dont
really need everything to work together properly. If you want an
integrated, testing, working distro you need a longer QA process and get
something like RHEL, though even there they sometimes seem to have a
hard time deciding which versions of which java stuff to bundle.
Ignoring Maven for a moment, there's a couple of questions I'd consider
(bear in mind I'm not a Cocoon user so I may be misunderstanding how
they eventually get used):
- how would a user that used one of these dependencies themselves in
addition to that Cocoon component select which version of the dependency
to use? Would they use the Cocoon-supplied one, one they select, or both?
- are the changes Cocoon specific? Will you always be using a custom
release, or will you pick up the next release when it is available?
There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository
file://localhost/${basedir}/extra-jar-repo
- host your own repository of these artifacts (this is basically
equivalent to the above and probably easier to work with, and could be
accommodated in a general ASF repository of such things, once taking
into account the licensing guidelines)
This is effectively what the fedora/core distros do when they use
jpackage to push out releases of various things. historically they've
tended to stick to point releases of java stuff, and custom releases of
stuff like firefox and and OOo, but with redhat getting more into java,
this could change.
- ask projects to do a beta/point release for you (it should be easy to
make a case for this if the version you are using is both stable and
contains critical fixes)
this should be your fundamental goal. You need to persuade projects that
they need to cut a tagged, labelled, supported release on your schedule.
Its pretty hard, especially if you get burned by the first time you ship
something before it is not ready (e.g axis1.0 because websphere wanted
it) and are left maintaining it for a while. The next time the team
comes back for a new release, you are going to push back and say "wait
until we are ready"
The hard part becomes convincing j-random-component.jar that they should
do a point release, with the beta testing and support costs. For
axis1.4, I think geronimo solved the problem by taking on the release
management role.
- "fork" the code (taking into consideration licensing guidelines)
either temporarily or permanently in your own repository (ie
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make
it part of your build, and do the custom group ID thing. We really need
the "provides" functionality planned for Maven 2.1 to make this feasible
if it is intended to be a drop in replacement of the original JAR (so
that you don't get duplicates in the dependency chain), but it can
certainly work.
BTW, I also think we need specific support for this type of artifact (it
is essentially a "vendor" release), and it is under consideration for
Maven 2.1.
Fork someone else's project and you take ownership of all support calls
forever. Take a look at how Axis handles support emails related to the
JBoss fork of Axis 1.x, it is essentially "please, go ask them; we dont
know what they did before they shipped". And don't even get me started
on the BEA version of Ant, the one with the modified manifests and the
broken .bat and .sh files.
Now that Cocoon is using OSGi, does that change versioning rules?
Because that lets components run different versions of things
side-by-side, doesnt it?
-Steve
