[jboss-dev] Javaee Spec Jars

[David M. Lloyd]

On 01/22/2010 12:18 PM, Jesper Pedersen wrote:
> Hi.
>
> On Friday 22 January 2010 13:01:05 Paul Gier wrote:
>> There was some discussion about naming conventions and svn structure for
>>   the javaee api spec projects this morning.  There is also more info in
>>   jira [1]. Here is the plan at this point.
>>
>> GroupId: org.jboss.spec.<sun groupId>
>> ArtifactId:<spec name>_<spec version>_spec
>> Version: Standard OSGI versions starting with 1.0.0
>>
>> For example:
>> <dependency>
>>     <groupId>org.jboss.spec.javax.servlet</groupId>
>>     <artifactId>servlet-api_2.5_spec</artifactId>
>>     <version>1.0-SNAPSHOT</version>
>> </dependency>
>>
>> The structure in svn will look similar to the structure that the geronimo
>> project uses for their spec jars [2].  Meaning that each spec version will
>>   have a separate trunk and a separate release cycle.
>>
>
> -1
>
> The API should be maintained by their implementing projects. It is up to the
> project where the code is maintained.
>
> I want full control over the JCA API, hence moved the development of the JCA
> 1.6 API to my project. The reasons for this were that is a real PITA to do 600
> small releases of the API project while the specification was being developed.

-1.

B doesn't follow A.  You can still have "full control" of the JCA API.  It 
doesn't make a difference if the SVN repos happens to live inside your 
project or another; the end result is the same.  Believe it or not, you are 
not the sole stakeholder of the JCA API.

Put another way, we may have more than one implementation of an API spec. 
Who "owns" it then?  There's absolutely no reason to have these projects be 
privately owned by spec implementers; it doesn't really provide any actual 
benefit.  If you're doing 600 small releases of the API project, you've got 
a problem with YOUR development methodology IMO.

> "But after the spec have been released..." you may say - but no. I still want
> full control over the release cycle, revisions update and so on. In my case
> I'll enhance the API document once we hit the Beta and CR stage in project -
> so there will continue to be a lot of updates. And doing a possible once a
> month release of the API project will be an unnecessary step in the release
> process.

The step exists whether you keep the API under your project or in a central 
location.

In short: it benefits everyone to have this API in a public location.  Even 
if it doesn't benefit you - something I have a hard time believing - it 
still benefits far more than it costs.  I just don't see the validity of 
your argument.

- DML