Vincent Massol wrote:
-----Original Message----- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: 22 February 2003 13:49 To: Cactus Developers List Subject: Re: [Proposal] Package Refactoring Proposal
Hi Vincent,
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?
Initially my idea with the Cactus package structure was to separate what was "public" (i.e. used by test writers) and put it in o.a.c. That was fine when cactus was small. However, as it grows, I feel that it is not adequate any more as there is no hierarchy and everything is stuffed in o.a.c.
The new proposal abolishes this way of thinking and (as is done with tge JDK classes for example) put classes in packages related to their functional meaning (and not whether they are user-public).
I had some long thinking with myself before proposing this... and in the end I don't think it is a problem if not all user-visible classes are not in a single o.a.c package.
Okay, but what *is* the problem with having them in the o.a.c. package, as it is now?
I understand you're trying to prepare the package structure for new functional areas... like EJB-Redirectors maybe. What about those new features would create a serious problem with the current package structure?
I also don't necessarily see the proposed 'testcase' and 'wrapper' package as a cleaner structure. There's a pretty strong coupling between ServletTestCase and ServletConfigWrapper (for example), isn't there? One alternative could be to define 'functional area' as what you want to test. So there could be a package o.a.c.servlet with ServletTestCase and the wrappers, and a package o.a.c.servlet.jsp with JspTestCase and the wrappers, etc.
Don't get me wrong, I'm not against these changes, I'd just like to understand them better :-)
[Also, there have been so many changes recently that I'd really prefer to let the dust settle a bit and get a new release out... and give me and others some time to catch up :-P]
We could also have a mixed structure such as:
o.a.c.api |_ testcase |_ configuration |_ [...] o.a.c.spi |_ [...] o.a.c.impl |_ [...]
where .api and .spi will be mostly made of interfaces and impl will contain all the implementation classes.
However, I think I still prefer my first proposal. In order to tell the user what is visible and what is not, we have several solutions: only describe in the doc what they need to use. In addition, separate the javadoc in groups (as you have done I believe): an API group, an SPI one and an implementation one?
What do you think?
Thanks -Vincent
Hmm... I'm not sure what the 'initialization' package is for... can
you
explain?
It contains the client initialization mechanism (only used by the jetty initializer for the time being). It can be used by test writers if they wish to have a one time initialization hook (for the whole test suite).
-Vincent
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]
