Choreographed releases (was [RANT] This Maven thing is killing us....)

[Steve Loughran <st...@apache.org>]

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

Re: Choreographed releases (was [RANT] This Maven thing is killing us....)

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 05 July 2006 18:29, Steve Loughran wrote:
> 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?

To some extent. Individual Java Packages can be versioned and one can declare 
a runtime dependency on a specific, ranged or 'later than' version of a 
package.

But problems will still surface.

A dependsOn B
A dependsOn C ver1.0 (only)
B dependsOn C ver1.1 (or later)

In such case, the classes of C may clash and therefor OSGi will not be able to 
(reliably) resolve A (i.e. 'wire' the classloading) and therefor not attempt 
it.

But in many cases it is possible to have scenarios working, which may not even 
be possible to build from Ant and Maven, hence the Eclipse insistence on 
having their own build system, which resolves OSGi packages according to the 
spec.

Cheers
Niclas