The "test" code ought to live in the same module as the server side code, if only because the two will be inseperable. Over time, in conjunction with coverage analysis, the test hierarchy will include performance loading tests, threading tests, authentication tests, and places where the specification is in fact ambiguous as to what should be done. With all these specific parts, at best I can see that the test framework can have a portion that is intended to be "standard", and that which is specific to the Slide implementation. Maybe I'm wrong, but I don't see the sense in separation.
As for the client side stuff, it would be very disappointing if the projects were decoupled to the extent that a client might possibly not interoperate with the server on occassion. This is less important, though, as presumably the test hierarchy will dramatically reduce the chances of an interoperability failure. Having worked on Slide client side code, though, I can say that it being a part of a much bigger project was not a big barrier to working with the code. However, having a server against which the code can be tested is/would be helpful (although since Slide didn't have an out-of-the-box solution, I never did figure out how to set it up to test against it).
I guess the real question is whether those of you who are CVS committers really want to narrow your focus, and perhaps restrict your permissions.
-Eric.
Oliver Zeigermann wrote:
I have no objections, but wonder what about the Tomcat specific stuff like contexts, admin and authentication. Will it be kept in jakarta-slide?
As a side note I would want to remark that both "problems" are a bit exaggerated: not everything has found its way into Slide, but only stuff related to WebDAV and there has been a community right from the start of the Slide project :)
Cheers,
Oliver
Stefano Mazzocchi wrote:
Group,
I find the slide project problematic for two reasons:
1) the scope of the project has been so loosely defined that you can find almost everything and its granma in the slide CVS
2) the community has been non-existant until a few weeks ago [but things are getting much better now]
Since I believe that 1 and 2 are related (1 is the effect and 2 is the cause) and since 2 seems to be getting better, I would like to propose that we retarget the scope of the slide project a little.
These are the things that are currently found in the slide CVS:
- the Slide repository core
- the WebDAV/DeltaV/DASL/ACL stack implementation on top of the Slide core
- a few slide stores
- a WebDAV/DeltaV/DASL/ACL test tool
- a WebDAV client library (generic) [works, used in cocoon]
- a CLI frontend for the client library [didn't try]
- a Swing FileChooser-like frontend for the client library [didn't try]
- a GUI (DAVexplorer-like) frontend for the client librar [doesn't compile]
I propose to split the above stuff in three different CVS modules, respectively (with the grouping above)
- jakarta-slide - jakarta-slide-test - jakarta-slide-client
The reason for the separation of the tests from the slide core is that I believe that those tests could be extremely valuable for general WebDAV stacks and should have anything to do with Slide by itself. Moving it away from slide allows us to give commit access on different repositories, for example to new people coming in and willing to work only on the client side or the tests.
What do you think?
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
