You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/11/30 11:09:27 UTC

[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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


Re: [proposal] New directory structure for framework project + consistent packages

Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,

see also my answer to your other proposal, which will show some 
scepticism from my side :-P Of course that is also directly related to 
this proposal, which proposes real actions to follow the words ;-)

So I'm concerned about premature abstraction. I think we should discuss 
more before shuffling stuff around the repository again. Unfortunately, 
I'm not gonna be available for the discussion for the next couple of 
hours today, but I'll try respond to any points etc this evening 
(european time).

-chris

Vincent Massol wrote:
> 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


-- 
Christopher Lenz
/=/ cmlenz at gmx.de


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


RE: [proposal] New directory structure for framework project + consistent packages

Posted by Vincent Massol <vm...@pivolis.com>.
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:vmassol@pivolis.com]
> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org