[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 17:20, Steven Boscarine wrote:

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

I don't believe this is true across all APIs. Some APIs contain more than abstract classes and interfaces.

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

I will see if we can do this. Certainly we can where:

a) Sun has published a jar into java.net
b) the license supports this

however very soon now (tm) all of java.net will be sync'd into central anyhow. I would prefer to wait for that.

However, as I originally said, some stuff just isn't published AT ALL in Maven - not in central or java.net. Dealing with that is harder. Where do we get the jar to publish from?

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

Agreed.

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

Shelly is pretty reliable :-)