On Jan 30, 2006, at 2:38 PM, David Jencks wrote:
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.
FYI, console-standard currently has a dependency on geronimo-
j2ee_1.4_spec-1.1-SNAPSHOT.jar which is where our builds currently
(since the jar has yet to be published -- Alan when will this be
fixed?) Even if we removed this dependency, we'd eventually die in
new5...
--kevan
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
