As long as we have inter-dependencies between specs (e.g. javamail depends on activation; jaxrpc on saaj, qname, and servlet; and especially geronimo-spec-j2ee depends on everything), I'm not convinced that this really makes things any better...

I agree that your plan is better than the previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler...

If I understand your proposal, tags/geronimo-spec-jaxrpc-<jax- rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler?

I think the source of complexity is the granularity of versioning we're trying to apply to specs... I wonder if the simplest course of action is to stop releasing individually versioned specs, and instead always release all specs. When an update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version).

--kevan

On Aug 18, 2006, at 7:53 PM, Jason Dillon wrote:

PROPOSAL:

1. Each spec will no longer be split up into trunk+branches+tags. There will instead be one trunk+branches+tags for all specs laid out as follows:

    specs/trunk/pom.xml
    specs/trunk/<artifactId>
    specs/tags/<artifactId>-<version>
    specs/branches/

2. Each plugin will continue to have its own version and will be released independently.

3. The top-level will have it's own version, which will remain independent. When there is a major configuration change in that pom, the version will be changed and the pom will be republished.

4. Releasing will be done with the maven release plugin ('mvn release') and should occur at a stable point after any major change to a spec module.

5. Change all module directories to match artifactIds.

MOTIVATION:

1.  one trunk allows the entire set of specs to be checked out all at
    once and built all at once.

 * * *

[ ] +1 Allow changes
[ ] 0  No opinion
[ ] -1 No, leave the specs asis (provide rationale)

--jason


Reply via email to