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