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

[Pete Muir]

On 20 Apr 2010, at 01:37, Steven Boscarine wrote:

> 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

These specs will be added into the next release of the BOM.

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

Yes. As we discussed though, JBoss can't publish to the javax. namespace, and Sun won't/don't publish all their specs APIs into Maven (though maybe this is changing?)


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

It's not the same JAR, but it is the same API (subtly different ;-)

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

Agreed. However even if we decided to maintain a BOM for this, we couldn't have it 100% using javax. as some specs in EE6 are missing published Maven artifacts. So, the question becomes whether it is worth doing a split one?

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

Yes, this is what they are doing from now on.

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

Personally, I don't think this is a good idea. It would be better to maintain a separate BOM for the javax. ones.

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

I think this is the plan, but Shelly was working out the details.

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