On Oct 28, 2005, at 7:21 AM, Jason van Zyl wrote:

On Thu, 2005-10-27 at 21:35 -0700, David Jencks wrote:
On Oct 26, 2005, at 3:30 AM, Greg Wilkins wrote:

Ideally, I think apache should branch all the standard javax
stuff into a project of it's own.   That way tomcat, jetty and
geronimo would all be siblings and there would be no cross
dependancies and versioning could be correctly done.

+10000

Several geronimo developers have discussed this as well but we haven't
had time to gather support from the other apache projects bundling
specs such as tomcat, axis, pluto, etc etc etc.

Where do you think the best place might be to organize something like
this? A separate TLP where all the projects could get involved?

yes

I think that we will still need to include more versioning information
than the spec version, such as
<groupId>org.apache.specs</groupId>
<artifactId>servlet-2.4</artifactId>
<versionId>1.0</versionId>

Just as you have needed to modify spec code when problems appear, at
geronimo we've recently found some problems in e.g. jacc, which has
been passing the tck for months and months.  So, I think we need the
ability to fix bugs within a spec version.

So if some project were formed that housed all the specs the same
project would house (privately) the TCKs? I assume fixes to the specs
would be infrequent but would require the running of the TCK for each
change.

well, i think we'd all have to cooperate to make sure all relevant tck tests passed before a particular spec version was released. Most of the tck tests are not directly tests of the spec classes, and not all behavior is completely specified and not all specified behavior is tested for. But, obviously, the relevant tck passing is a precondition for release. Since such a small part of the tcks are relevant to the specs I doubt trying to tie them together would be useful. There may be other issues as well: the apache copy of j2ee tck relevant material is housed in a separate svn repo to (at least) make access control easier.

thanks
david jencks


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to