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

[Steven Boscarine]

On 04/20/2010 06:14 AM, Pete Muir wrote:
> It's not the same JAR, but it is the same API (subtly different ;-)
>    

The contents are the same, correct?  There is no JBoss-specific magic in 
an org.jboss.spec.javax.* jar, right?  The classes and interfaces are 
otherwise identical, right?

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

Fully understood.  Sun/Oracle hasn't been good about pushing their APIs 
to maven central.  It's been frustrating me and every other maven user 
for many years now.

Is JBoss willing to push the missing javax.* jars to their nexus repo 
using the javax.* namespace?

If so, wouldn't that fix the problem?  The developers will be pulling 
from repository.jboss.org instead of maven central until Sun gets their 
act together & pushes their jars to central, but it should be pretty 
painless, right?  Hopefully, down the road, Sun/Oracle will post their 
jars to central and the projects will stop pulling basic things like 
javax.servlet from the JBoss repo (3.0 is still not in central, for 
example).

For me, the motivation of using javax.* namespaced jars is that 
everything would be self explanatory.  Presumably most serious 
developers are smart enough to figure out why JBoss has to maintain 
tight control over their dependencies, especially the ones shipped with 
their product.  However, many of us have our work audited and might not 
have an easy time explaining it to everyone we answer to, especially if 
our weld project isn't deployed to a JBoss AS instance.




>> 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.
>
>    
I am personally happy with whatever approach JBoss thinks is best.  I 
proposed that one because I thought it would be easier for them to 
update it and they'd be less likely to forget the javax.* BOM.  We could 
have the javax.* BOM extend the org.jboss.spec.javax.* BOM so users 
could easily use either the org.jboss.spec.javax* dependency or the 
javax.* dependency for individual API jars.