On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote:
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?
I don't see how. I don't think any parts of geronimo should use the
uber jar no matter which maven version we are using: my understanding
is that it is for the convenience of users who don't want to figure
out exactly which specs they are relying on.
Cant we solve this dilemma by generating a little text file that
says which jars were aggregated and sticking it in META-INF? Is there
some more "official" way to do this like with manifest entries?
thanks
david jencks
Regards,
Alan
