I think cleaning up the package structure for the internal classes is a great idea.
However I'm not so sure about the stuff that is directly used by test writers. AFAICT these classes are getting moved into o.a.c.testcase and o.a.c.wrapper. I don't think this is really necessary for a clean package structure. Maybe you can give some additional reasoning?
Hmm... I'm not sure what the 'initialization' package is for... can you explain?
Vincent Massol wrote:
Hi,
As I am preparing to implement new XXXTestCase (for EJBs, JMS, etc), I am finding that the current cactus packages are limiting and do not provide enough room to extend Cactus. In addition, it is hard to recognize pattern just by looking at the current packages. What I mean by pattern is for example the redirectors is one pattern, the client connectors are another Pattern, the configurations, etc.
I would like to propose a new package structure (of course, we will simply deprecate existing classes and not remove them right away!). Here is my proposal:
o.a.c.testcase o.a.c.configuration o.a.c.util o.a.c.client o.a.c.client.authentication o.a.c.client.connector o.a.c.client.request o.a.c.client.response o.a.c.client.result o.a.c.client.initialization o.a.c.server o.a.c.server.runner o.a.c.server.redirector o.a.c.server.wrapper (J2EE API wrappers) o.a.c.server.object (Implicit Objects - Can't find a better name)
I have mapped all the existing classes to these packages and it seems to work fine.
Committers, are you ok with this and shall I go ahead? Again, I will not remove any existing *public* class (i.e. used by end users) but will mark them as deprecated, remove their content and make them extend the new class.
Thanks -Vincent
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
