> -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED] > Sent: 24 February 2003 11:06 > To: Cactus Developers List > Subject: Re: [Proposal] Package Refactoring Proposal > > Hi Vincent, > > 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?
Simply that there are too many classes doing lots of different things. > > 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. Indeed, there are several options: 1/ o.a.c.client.servlet and o.a.c.server.servlet 2/ o.a.c.servlet.client and o.a.c.servlet.server 3/ o.a.c.servlet but then there are lots of other support classes like: AbstractClientTestCase, AbstractWebClientTestCase, AbstractWebServerTestCase, etc. where do we put these? I wanted to put them in o.a.c.testcase: o.a.c.testcase o.a.c.testcase.servlet o.a.c.testcase.jsp [...] As you mention, there are 2 functional aspects: Servlet/JSP/etc vs TestCase/Redirector/Connectors/etc. ATM, I was more following the later route (i.e. functional WRT what the class does) rather than the former (i.e. functional WRT a test domain). > > Don't get me wrong, I'm not against these changes, I'd just like to > understand them better :-) sure :-) > > [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] This, I agree. I'd really like to release 1.5 now. I wanted to wait for Julien to deliver a working Eclipse plugin. He just told me he will have a working version by the end of today! We're still missing some documentation and we're ready to deliver. Thanks -Vincent > > > 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]
