On 20 Apr 2010, at 19:11, Dan Allen wrote:
On Tue, Apr 20, 2010 at 12:20 PM, Steven Boscarine
<steven.boscarine(a)childrens.harvard.edu> 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?
This is almost certainly not the case - take for example the JSF API - it contains a lot
of impl-specfic logic. Now, we happen to use the JSF RI in JBoss AS, so it's likely we
use the JSF API RI (javax.faces:jsf-api) too. But it's not the only spec like this...
So, as I said, to be clear, the public API is (of course) exactly the same but the classes
aren't. This is subtle, but important, because you should not use a JBoss AS *at
runtime* inside another container. This could affect us in test cases in exactly the same
ways as the stripped APIs hit test cases
It is however safe to compile against the JBoss versions of the APIs and deploy to
GlassFish.
Given the difficulties around embedded test classpaths, I do wonder if we can even
recommend that people ever use any API jars except those for their target container. We
need to do some brainstorming here. I added it to the meeting agenda.
Yes, identical. This is similar in spirit to what Geronimo has been doing for years.
http://repo2.maven.org/maven2/org/apache/geronimo/specs/
In fact, just about all of my past corporate projects referenced the geronimo specs for
the very reason we are discussing in this thread...many were absent from central. Central
got better for a while, now it's out of date again :(
>
>> 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.
There are two problems here.
1. The spec APIs are not consistently pushed to the central repository (if at all)
2. The JARs contain stripped classes, which blow up test suites, as we have observed
Sonatype has been working on merging the
java.net Maven repository into central.
Here's the story as I know it. They have put a lot of effort into it and they
haven't gotten much support. So this is a one-time important and won't address
future publication needs. So while it gives us the JARs we need in the short term, we
still need a long term strategy.
They will be offering a long-term strategy based on nexus for
java.net projects that want
it (and some projects have popped up and asked for it). So at least there will be an
avenue for projects that want it.
They may be going further, I need to check with the Sonatype guys.