On Aug 22, 2006, at 1:37 AM, David Jencks wrote:
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
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?
That'd be right. I'm not sure how complicated that is, though.
None of those specs have changed in a year. Can you give an non-
hypothetical example of something that does change and causes this
problem that isn't the J2EE uber-jar?
Well, the current activation spec is at version 1.1. When that
version was bumped from 1.0 (or 1.0.x), you'd have needed to know/
remember to change the poms in the following specs: geronimo-spec-
j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo-spec-
saaj.
A question for you, Jason: If someone wants to build our released
specs from source, what's the process?
Maybe I don't understand the proposal, but otherwise IIUC every
time we've found a problem in e.g. the jacc spec we'd need to
release every spec jar, and update all the versions. I guess we do
this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but
I think having a lot of identical-contents spec jars would be too
confusing.
No, I don't think that's what is happening (at least not in theory),
but I've never actually "released" specs. So, I may be mistaken...
Current Process for updating jacc
1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new
geronimoSpecsJaccVersion
2) Update jacc spec sources
3) Build all specs
4) Release jacc and uber-jar spec
5) tag branches/1_1 as tags/1.1.x
Current Proposed Process
1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec
version and new jacc spec version
2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version
3) Update jacc spec sources
4) Build jacc and uber-jar (build seperately or together?).
6) Release jacc
7) tag jacc-<version>
8) Release uber-jar
9) tag uber-jar-<version>
Single-version Proposed Process
1) Update branches/1_1_/pom.xml with new specs version
2) Update jacc spec sources
3) Build all specs
4) Release all specs
5) tag branches/1_1 as tags/1.1.x
I don't see that releasing identical content spec jars are
necessarily confusing (as you point out, we essentially do it with
every Geronimo release). Less confusing to have only a single version
to worry about... What's the latest release 1.1.x geronimo specs? Use
that for all of my j2ee 1.4 spec dependencies. Seems simpler than
knowing the latest jacc spec is at version x and the latest servlet
2.4 spec is at version y.
--kevan
