geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
Date Mon, 30 Jan 2006 19:38:40 GMT

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
>
>
>


Mime
View raw message