geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
Date Mon, 30 Jan 2006 19:24:00 GMT
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




Mime
View raw message