As Dan pointed out, if we run that new BOM alone, we're missing:
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@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@redhat.com>
To: "Steven Boscarine" <steven.boscarine@childrens.harvard.edu>
Cc: "Weld-Dev List" <weld-dev@lists.jboss.org>, smcgowan@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
      
_______________________________________________
weld-dev mailing list
weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
    

_______________________________________________
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev