Just a point before Chris answers... :-) I've also been thinking a bit more about it and I feel that changing the package structure for the framework might be a bit harsh on cactus users. If we were starting a new framework it might make sense. I'm not sure it does with our history. I can be swayed one way or another... :-)
The rest seems fine to me. What do you think? -Vincent > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 30 November 2003 11:09 > To: 'Cactus Developers List' > Subject: [proposal] New directory structure for framework project + > consistent packages > > Hi, > > I'd like to change the framework project directory structure, to: > > framework/ > |_ core/ > |_ src/org/apache/cactus/framework > |_ protocols/ > |_ src/org/apache/cactus/framework/protocols/ > |_ brokers/ > |_ src/org/apache/cactus/framework/brokers/ > > Note 1: The protocols and brokers names can be changed later on to > reflect what we prefer. > Note 2: In practice it means decomposing the single framework project in > 3 subprojects. > Note 3: We will still deliver a single unified framework jar > Note 4: Please note the new framework/ package. I believe it is time to > do that. Cactus has expanded and we need more package room. The full > package hierarchy will be: > > o.a.c/ > |_ framework: core framework (there is no core sub-package) > |_ protocols > |_ brokers > |_ extension: Cactus extensions > |_ jetty: Jetty extensions (Jetty Test setup for now) > |_ jsp: JSP testing extensions (JspTagLifecycle for now) > |_ integration: different Cactus integrations > |_ ant: Ant integration > |_ eclipse: Eclipse integration > |_ maven: Maven integration > |_ sample: cactus samples > |_ servlet: Servlet sample > |_ jetty: Jetty sample > |_ ejb: EJB sample > |_ build: classes needed for Cactus build itself > |_ documentation: classes for the documentation project build > > So, why this framework project separation? Because we can put ourselves > in the same exact situation as any user who wishes to extend cactus by > writing a new protocol support or a new broker. The APIs are clearly > shown. Each subproject exposes an API. > > Of course, this will break our users but I feel this is required and now > is the right time: > - we have delivered Cactus 1.5 > - we are already planning on straightening up our public API > > However, I think we can call it Cactus 2.0 if we wish to clearly shows > it involves some breaking changes. > > What do you think? > > I'll start slowly applying this later today, starting with no > fundamental changes (like moving build documentation classes in > build/documentation, etc). > > Thanks > -Vincent > > > --------------------------------------------------------------------- > 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]
