On 1/30/2006 11:14 AM, David Jencks wrote:
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.
If we moved to Maven 2 and used its transitive dependencies, would the
the need for an Uber jar be obviated?
Regards,
Alan
