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

[Dan Allen]

On Tue, Apr 20, 2010 at 12:20 PM, Steven Boscarine <
steven.boscarine at 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?
>

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.

Uh, and to think all of this over just needing to compile and app to use the
platform. Frustrating for sure.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100420/a0c25a04/attachment-0001.html