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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
