[jboss-dev] Javaee Spec Jars

[Andrew Lee Rubinger]

I don't see how this discussion is any different from a generic 
dependency issue.  We have some API which may be consumed by N projects. 
  The namespace must be "javax.something".  Would you look in some 
project implementation for this, or somewhere externally shared?

"Multimodule builds are to be used to group modules together in a single 
build."[1]

 From this I infer that modules are intended to share release cycles.

Now, I don't consider the EJB Specification APIs to be a part of the 
JBoss EJB implementation.  We want to continually publish updates, bug 
fixes, and enhancements without re-releasing the Spec APIs.

 From this setup I'd conclude that the JBoss EJB Impl should depend upon 
the EJB Spec APIs, exporting the dependency to consumers.  If we want to 
change the Spec APIs to adjust source or JavaDoc or whatever, we can 
update the module shared by all, cut a new release, and update our 
dependency.

Contrast that with the ShrinkWrap API; here we actually re-release the 
API as a module as part of the main release cycle, but only because:

1) It's just plain easier to manage given the tools available.
2) We may want to update user-visible implementation classes (in a way 
that doesn't break binary compatibility)
3) We may want to update JavaDocs, and have there be a 1:1 relationship 
between releases and docs.  Easier for users.

Spec APIs on the other hand are:

1) Shared by N impls
2) Intended to be locked and done after TCK passes

S,
ALR

[1] 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-multi-vs-inherit.html

On 01/22/2010 02:50 PM, Jesper Pedersen wrote:
> On Friday 22 January 2010 13:57:21 Brian Stansberry wrote:
>>> The project will release the API under its own Maven artifact using the
>>> project group id - as the JCA container has a life besides AS.
>>
>> What is the rationale for this? The naming convention Paul outlined is
>> in no way JBoss AS specific. The whole point of this exercise is to
>> reduce confusion around what the correct spec impl is for use in
>> jboss.org projects. Having two releases of the same thing under the
>> org.jboss namespace is totally confusing.
>>
>
> My point is that AS will have one public API and the standalone JCA project
> will have its own public API.
>
> Each of these should be clear and documented, and will target different groups
> of developers. Yes, with some overlap I know.
>
>> If that point's accepted, I don't see the significance of where in the
>> svn repo the source lives. The only thing I could see is if you don't
>> want to have the rest of the JCA project depend on an external spec jar,
>> but instead manage it as a single project with multiple modules, the way
>> the AS was before it was mavenized. But then you're releasing a new
>> version of the spec every time the rest of the project needs a release.
>>
>
> EJB3 seems to be managing individual version identifiers for their components
> just fine.
>
> Best regards,
>   Jesper
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger