Hi Chris, (see below).
> -----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. 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
