On Aug 22, 2006, at 12:45 PM, David Blevins wrote:
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
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
6) tag branches/1_1/pom.xml
7) release pom.xml
If the version information for any given module is only contained
in the parent, we have to release the parent when we release the
module.
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, this question was directed at you.
On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
This just came into mind. Any thoughts on what we'd do for the
specs that are javaee 5 only versions (corba, servlet, soon jta
and ejb, etc.) and the ones that overlap between j2ee 1.4 and
javaee 5 like jms, jca and jacc?
Something like:
specs/branches/1.1 will remain a more or less "pure" 1.4 level of the
specs.
specs/branches/1.2 would contain the 1.4 specs and roll-in the Java
EE 5 specs as we need and implement them. The geronimo-j2ee_1.4_spec
(if we keep it) would contain only 1.4 versions of specs. Java EE 5
specs would stand on their own (e.g. geronimo-ejb_3.0_spec-1.2.0). If
we wanted, we could introduce a geronimo-javaee_5_spec (which
includes new specs).
specs/branches/2.0 would contain only Java EE 5 specs (and any non-EE
specs that we're moving forward/maintaining).
There is of course, duplication of source (just like you have anytime
you branch...) and problems might need to be fixed in (and released
from) multiple branches).
--kevan
