www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Apache project as a JSR reference implementation
Date Mon, 16 Jan 2006 10:37:17 GMT
Geir Magnusson Jr wrote:
> Jukka Zitting wrote:
>> Hi,
>> I'm a committer of the incubating Apache Jackrabbit project that was
>> used as the reference implementation of the JSR 170 (Content
>> Repository for the Java Technology API). A second version of the API
>> is currently being specified by JSR 283 and there is interest to keep
>> using Jackrabbit as the reference implementation also for JSR 283.
> Sounds good.
>> Currently most of the active Jackrabbit committers (me included) are
>> members of the JSR 283 expert group, so I there shouldn't be many
>> problems doing this in practice, but I'm a bit concerned about how
>> this will affect the project as the community evolves. How should we
>> communicate design decisions based on API details not yet published by
>> the expert group?
> Well, if you guys can control the EG, I'd propose that you work entirely 
> in public, just like an Apache (or other community-oriented open source 
> project does).
> For example, you might offer to have the Jackrabbit project 'host' the 
> EG's work, add a separate, public mailing list for the expert group 
> traffic, and a part of your SVN for their work.   I suggest a separate 
> list only to keep clear what is normal jackrabbit developer traffic, and 
> what is the EG traffic.

Public is good, under gump is good too.

I would go for

1-a separate SCM repository for spec: api+test cases that is decoupled 
from any implementation, so that all of the spec team can have commit 
access to the spec repository.

2-a junit based testrunner that can run test suites against any 
implementation that implements the right factory interface.

3-test-centric API/spec

I've got the first two up and running on sourceforge for our deployment 
project, http://sourceforge.net/projects/deployment

if you grab everything from CVS you can find the abuse of Junit that 
lets me take a manifest of XML files and turn each document into a test 
case. We have two open source API impls, and one closed source one all 
sharing the same test runner, so it will be easy to compare the results.

The big barriers to (3) are ignorance of the value of testing amongst 
some of the spec team (its hard to work with a team leader who believes 
we should focus on implementation ahead of testing), and not enough 
experience among team members about how to write good tests. 
Interestingly, it is the OSS projects that are better at this than 
anyone else.


View raw message