[weld-dev] (org.jboss.spec.javax.* vs javax.*? ) Re: Maven Archetype Bill of Materials - How should we handle minor variations in point releases of Java EE 6 containers?

Mon Apr 19 20:37:55 EDT 2010

As Dan pointed out, if we run that new BOM alone, we're missing:

    * javax.faces:jsf-api:jar
    * javax.enterprise:cdi-api:jar
    * javax.annotation:jsr250-api:jar
    * javax.validation:validation-api:jar

The issue here is that the dependency name space for this new BOM 
doesn't match the ones we used because they're all prefixed with 
org.jboss.spec.* and have different version numbers.

So the design question for the list is do we want to expose to users:
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>jboss-servlet-api_3.0_spec</artifactId>
<version>1.0.0.Beta2</version>
</dependency>

...or would we prefer:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>3.0</version>
</dependency>

Either is perfectly valid and achieves the same bottom-line result.  
Both are the same jar.

On one hand, I prefer the javax.* because it is more conventional and in 
my opinion, more polished looking, especially for people who choose to 
run weld or Java EE outside of a JBoss container.  On the other hand, it 
would be preferable if the JBoss AS team maintained a BOM for each point 
release of JBoss AS with the precise point release of each API shipped 
with their container.

I imagine this is relatively important for the AS team as I am guessing 
a non-trivial number of errors in the wild occur due to library version 
mismatches.  Perhaps maintaining a good set of archetypes that match 
your container precisely will either reduce these or at least give the 
developers less of an excuse for these errors?

What options are available?
Shelly, are you willing to allow both the javax.* and the 
org.jboss.spec.javax.* entries in the BOM?

If we could maintain the same namespace for dependencies (javax.servlet, 
for example) for every container, then a user could use one pom and 
change the BOM to match his/her precise container version (Glassfish v3 
vs JBoss AS 6.0.0 or JBoss AS 6.0.1).  The AS project can use the 
org.jboss.spec.* jars as before and just help out keeping the javax.* 
entries up to date as new releases are performed.

An example where this would be an issues is javax.enterprise.cdi-api.  
JBoss AS has no use for a CDI-API 1.0.0 as they're using 1.0.1, however, 
to use the BOM and have it work on Glassfish v3 and JBoss AS 6, JBoss 
would have to upload weld 1.0.0 as 
org.jboss.spec.javax.enterprise.cdi-api (if the javax.* entries weren't 
in the BOM).

Shelly, if you think that it's acceptable to keep both the normal jar 
name and the org.jboss.spec jar name in the BOM, I can make the initial 
edits.  IMO, this will really pay off if the server team updates the 
versions of the individual jars down the road as versions change for 
JBoss AS point releases.  Otherwise, the archetype project will have to 
duplicate a lot of effort to keep in sync with the server team.

Thanks,
Steven

On 04/19/2010 04:40 AM, Pete Muir wrote:
> On 19 Apr 2010, at 02:31, Dan Allen wrote:
>
>    
>> Great initiative! This is a real win for JBoss, especially given the debacle of the aggregate jar that Sun published to the java.net repository.
>>
>> It seems that several core specs are missing, such as bean validation, CDI
>>      
> Shelly is working on CDI at least.
>
>    
>> and JSF. I'm I just not seeing them or are they missing for a reason? Also, are we planning on doing profile stack poms such as the web profile?
>>      
> This would be nice.
>
>    
>> Again, nice start.
>>
>> -Dan
>>
>> On Wed, Apr 14, 2010 at 10:44 AM, Shelly McGowan<smcgowan at redhat.com>  wrote:
>>
>> Pete,
>>
>> This morning I released the jboss-javaee_6.0_spec, 1.0.0.Beta3.
>>
>> http://repository.jboss.org/maven2/org/jboss/spec/jboss-javaee_6.0_spec/1.0.0.Beta3
>>
>>
>> This release contains fix for JBEE-33 - update to use JACC 1.4.
>>
>>
>> Shelly McGowan
>> JBoss, by Red Hat
>>
>> ----- Original Message -----
>> From: "Pete Muir"<pmuir at redhat.com>
>> To: "Steven Boscarine"<steven.boscarine at childrens.harvard.edu>
>> Cc: "Weld-Dev List"<weld-dev at lists.jboss.org>, smcgowan at redhat.com
>> Sent: Tuesday, April 13, 2010 8:00:35 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: [weld-dev] Maven Archetype Bill of Materials - How should we handle minor variations in point releases of Java EE 6 containers?
>>
>> Shelly has pointed us at http://repository.jboss.org/maven2//org/jboss/spec/jboss-javaee_6.0_spec/1.0.0.Beta2/jboss-javaee_6.0_spec-1.0.0.Beta2.pom which works great as a jboss-6.0.0-bom. Unfortunately, Sun control the javax namespace, and don't publish a BOM for Java EE, so producing one of these is much harder.
>>
>> I suggest we stick with the JBoss one for now, along with instructions on how to create one for other app servers.
>>
>> WDYT?
>>
>> On 12 Apr 2010, at 16:47, Steven Boscarine wrote:
>>
>>      
>>> Hello All,
>>> The Weld archetypes need to be updated to reflect the latest Weld 1.0.1
>>> release.
>>>
>>> Presently, we're using the weld-extensions-bom
>>>
>>> <dependency>
>>> <groupId>org.jboss.weld</groupId>
>>> <artifactId>weld-extensions-bom</artifactId>
>>> <version>1.0.0-CR2</version>
>>> <type>pom</type>
>>> <scope>import</scope>
>>> </dependency>
>>>
>>> The immediate issue is that the archetypes need to reflect the changes.
>>>
>>> The hairier issue is dealing with minor point release differences
>>>
>>> Now there's 2 variants of weld in the wild, via 2 Java EE containers.
>>> Glassfish has weld-1.0.0 and JBoss 6 will have 1.0.1.  Should this be
>>> reflected via different BOMs?
>>>
>>> Should there be a weld-jboss-6.0.0-bom? glassfish-v3-bom?  Presumably,
>>> down the road, there will be more variants as other APIs have minor
>>> point increases.
>>>
>>> If not, does anyone have suggestions for dealing with trivial variations
>>> in versions between container point releases?
>>>
>>> Thanks,
>>> Steven
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>        
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>>
>> -- 
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://www.google.com/profiles/dan.j.allen
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>      
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100419/c5498558/attachment-0001.html 