[jboss-dev] Javaee Spec Jars

[Anil Saldhana]

We have gone the individual projects implementing the EE specs individually route before
and had to make an attempt at consolidating it in the javaee project.  Previously it worked
because there were very few consumers. But now something like the annotation api that was
part of EJB3 project is a dependency of the WS project (@Resource as example).

Please keep the EE api/impl in the central javaee project.

On 01/22/2010 02:37 PM, Andrew Lee Rubinger wrote:

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