I'm definitely *NOT* in-favor of 8 assemblies.
I also believe that we should use the TCK results from our automated
builds, not those which happen to pass on certain developer
machines. Many issues come up due to varying environments, so tests
that pass on your machine, might not pass on mine depending on how
things are setup. I've tried to get our harness to remove some of
these, but due to the nature of how the TCK works... and how people
run them (ie. re-using previously expanded sun dists, which may alter
future runs). Also, its hard to say exactly which build of the
server or cts server which these users are actually testing against,
which is more reason why I would like to leave this matter to the
automated system which we know what was used for what build and what
was tested, and can re-run tests on the same build to verify that
there are no transient/race-condition problems.
As for plugins... I'm not sure that really changes things all that
much from actually running the tests... though I think its much
better from a build perspective. If we did say have one assembly
zip, and then some scripts to bootstrap plugins, then from a TCK
perspective we'd still have to have N full flights to verify that
each permutation passes. So the problem is the same using plugins or
pre-built assemblies. The only difference is that with plugins we
have to add a pre-test step which will run the proper plugin
bootstrap bits to get the right components in the server.
If you need more details on the TCK specifics I can give them on the
TCK list...
--jason
On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote:
I know everyone is working feverishly on 2.0 so I'll make this
brief. There are a few things that we need to discuss as the train
keeps moving.
First, I'm working on DayTrader 2.0 this week to get the beast
deployed on 2.0. Basically the initial goal is to deploy what we
had working for 1.2-beta and 2.0-M1 which I think will be a fair
but not exhaustive test for the converter.
Next, regarding assemblies. Right now we've been producing two
assemblies which are the traditional Tomcat and Jetty assemblies
with CXF as the web-services component and OpenJPA as the EJB
persistence option. I think we all agree that certifying 8
different assemblies is not workable as getting two done generally
is a herculean task. That said, I think we want to make sure that
projects that want to be part of a certified version have the
option to make that happen. Since those that are doing the work
tend to define what gets in and what ships it seems reasonable to
me that the folks doing TCK can choose a configuration that they
are interested in testing. There are no limits to the number of
people that can TCK a release so the sky is the limit.
For the JPA folks and WebServices folks I wanted to get a feel what
your thoughts are on this topic. Part of the discussion is how
easy is it to include one component versus another and I'll be the
first to admit I'm not really well versed with WebServices to have
an opinion on integration options. It seems that JPA is fairly
simple in terms of plugging in a persistence provider and the user
selecting the one they want. Dain had mentioned on an earlier e-
mail about having a similar plug point for WS and I don't think
there was a lot of discussion at the time. Given where we are at
now what are folks thoughts on a plugin option for WebServices?
If there is a plugin option then I think the TCK discussion becomes
simpler. Anyway, for those more skilled in that art than I what
are the community thoughts on how to address our expanding set of
pluggable components?
I'd like to have the discussion in this thread and if we need to
put a vote together to provide a direction we can do that later.
Thanks
Matt
