On Jan 30, 2006, at 11:07 AM, David Blevins wrote:
On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote:
Think of what the alternative is that you are asking the end
developer to cope w/. He must grok what is the current correct
collection of versions are. Even if all the APIs mature and their
version numbers never change thereafter, there will be confusion
when we say everything is 1.0 except for CORBA which is 1.3 and
JavaMail which is 1.545. We should also consider the situation
when we accommodate new JSRs as well.
Come on. We are not looking at 545 versions of javamail -- if we
were i would *certainly* put my foot down hard at releasing 545
identical jars for javax.servlet and the other 12 spec jars that
don't change.
We are looking at maybe 8 release of javamail, possibly 4 of
corba. Just guessing. That would give us this repo for all the
public to consume. If you weren't using javamail or corba, you'd
would only ever have to worry about the "1.0" version of
everything. Those are already J2EE 1.4 certified and most haven't
changed in 2 years.
geronimo-activation_1.0.2_spec-1.0
geronimo-corba_2.3_spec-1.0
geronimo-corba_2.3_spec-1.1
geronimo-corba_2.3_spec-1.2
geronimo-corba_2.3_spec-1.3
geronimo-corba_2.3_spec-1.4
geronimo-corba_2.3_spec-1.5
geronimo-ejb_2.1_spec-1.0
geronimo-j2ee-connector_1.5_spec-1.0
geronimo-j2ee-deployment_1.1_spec-1.0
geronimo-j2ee-jacc_1.0_spec-1.0
geronimo-j2ee-management_1.0_spec-1.0
geronimo-javamail_1.3.1_spec-1.0
geronimo-javamail_1.3.1_spec-1.1
geronimo-javamail_1.3.1_spec-1.2
geronimo-javamail_1.3.1_spec-1.3
geronimo-javamail_1.3.1_spec-1.4
geronimo-javamail_1.3.1_spec-1.5
geronimo-javamail_1.3.1_spec-1.6
geronimo-javamail_1.3.1_spec-1.7
geronimo-javamail_1.3.1_spec-1.8
geronimo-jaxr_1.0_spec-1.0
geronimo-jaxrpc_1.1_spec-1.0
geronimo-jsp_2.0_spec-1.0
geronimo-jms_1.1_spec-1.0
geronimo-jta_1.0.1B_spec-1.0
geronimo-qname_1.1_spec-1.0
geronimo-saaj_1.1_spec-1.0
geronimo-servlet_2.4_spec-1.0
geronimo-j2ee_1.4_spec-1.0
geronimo-j2ee_1.4_spec-1.1
geronimo-j2ee_1.4_spec-1.2
geronimo-j2ee_1.4_spec-1.3
geronimo-j2ee_1.4_spec-1.4
geronimo-j2ee_1.4_spec-1.5
geronimo-j2ee_1.4_spec-1.6
geronimo-j2ee_1.4_spec-1.7
geronimo-j2ee_1.4_spec-1.8
That would represent 100% of the jars publicly available and
consumed by the public. Life for people who just use servlets or
jsp is simple and leveraging other projects that use servlets or
jsp is also clean as they will be guaranteed to have the same
servlet jar version as you (there is only one available).
If we did things according to your proposal, there would be 9
choices for each spec, 153 spec jars floating in the public and
exactly 124 of them will be duplicates of previously released
jars. Except the trick is, you won't actually know which ones are
truly diplicates of other jars; you'd have to diff the scm like I
did. Everyone would be forced to upgrade, even if they don't use
javamail or corba, just to be sure and before you know it all 154
of those jars will be in use.
IMHO, this will create a big mess for everyone who uses spec jars
and has to deal with several other artifacts also using different
versions of the spec jars.
As I expressed previously, I think it is a bigger mess to be unable
to determine the contents of the uber-spec jar. If you can suggest a
way to make it easy to find out which individual spec jars are
aggregated into the uber-spec jar, I will stop objecting to
individual versions.
thanks
david jencks
-David
