geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
Date Mon, 30 Jan 2006 20:03:40 GMT

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


Mime
View raw message