portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus: Documentation !)
Date Tue, 07 Jun 2005 21:19:09 GMT
Scott T Weaver wrote:
> I think another question we might want to ask ourselves is "Does having all
> the individual sub-projects really have any true benefits?"  I know
> initially this was to show lines between the different components.  However,
> this can be accomplished with good documentation and naming standards.
> Also, moving things into a smaller number of subprojects would *GREATLY*
> simplify our build scripts which, IMOHO, have gotten way out of control to
> the point that synchronizing the Jetspeed 2 plugin with the actual build
> process has become an incredibly painful task.
> 
> This is just a quick suggestion of a new structure:
> 
> |--commons* (no change)
> |
> |--jetspeed-api* (no change, possibly renamed to just plain, old "api")
> |
> |--components* (All component implementations currently in separate 
> |              subprojects would go here)
> |
> |--engine* (All engine/container/pipeline stuff goes here)
> |
> |--management (All Jetspeed 2 specific management apps and portlets live
> |              here)
> |
> |--deployment* (Since the  deployment system is somewhat complex, it gets
> |              its own subproject.  I left it out of management as 
> |              management should be an optional build requirement
> |              but deployment is mandatory.) 
> |
> |--demos (All demo applications/portlets)
> |
> |--plugins (Maven plugin goes here along IDE-specific plugins.)
> 
> * Signifies mandatory subproject for a minimal working build
> 
> I left out all the bridges' api pieces as they will be moving into their own
> project.
> 
> This leaves the random bits and pieces that are in the portal subproject,
> which we could iron out as we refactor.  Please point out anything I missed
> and feel free to modify/suggest changes to the structure.
> 
> Flame away,
> -Scott
Ok, I'll bite ;-)

I'm definitely -1 on this (merging all components into one subproject).

I just started with Jetspeed-2 around the time the big refactoring to a component based model
took
place and I think it is a very smart thing done.

In my opinion, there is much more value in having clearly defined *and* separated components
(based
on a clear contract/api) than only to show a "line" between the many functional parts of what
makes 
a portal (engine).

One point has already been mentioned by David: it makes it much easier to swap out one 
implementation for another (for integrators for instance).
For me though, this is only one benefit, albeit an important one.

What about:
- much better identification of the different functional area's
- a much clearer and cleaner documentation path (but something which still needs to be done
   of course)
- getting to "know" the internals of the portal and its many facets is much easier to tackle

Also, from a more technical view:
- a stronger enforcement of (classpath) independence and thus required recognition of
   inter-component dependencies (which we should always try to keep a low as possible).
   Mixing multiple components into one classpath will most likely lead to (much) increased
Law of
   Demeter violations.
- much easier independent testing
- The possibility to swap out a component with a different *version* of itself by just replacing
   one jar.
   Although we don't have reached the level of maturity yet where this is needed *now*, I
surely
   expect this to happen once we get past the 2.0-FINAL release.
   What about wanting to release a new version of the persistence component because a new
and much
   quicker version of OJB is available. Why (would we have to) release a complete new portal
only for
   that?
   A component does have a version, and we might just as well use it...

Merging the different components back into one subproject will kill off a major aspect of
our
future options in my view. Although it might bring a quick and dirty simplification *now*,
I think
we are going to pay a high price later ...

Maybe some functional parts have been split too far. I haven't reviewed the current codebase
from
this perspective yet so I don't have an opinion on it yet.
If we've gone too far separating in some area's though, then lets fix that.
If the build setup is getting (too) difficult to maintain, then lets discuss that and see
how we can
improve it.
But please, let us try to stick to CBD: divide, isolate and conquer.

Regards, Ate

(awaiting being flamed in turn now ;-)

> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: David Sean Taylor [mailto:david@bluesunrise.com]
>>Sent: Tuesday, June 07, 2005 3:15 AM
>>To: Jetspeed Developers List
>>Subject: Re: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus:
>>Documentation !)
>>
>>Raphaƫl Luta wrote:
>>
>>>David Sean Taylor wrote:
>>>
>>>>Is that along the lines you are proposing?
>>>>
>>>
>>>I didn't have any definite structure in mind and just wanted to start
>>>the thread, I just know what I don't like: that separate "physical"
>>>package share the same java namespace.
>>>
>>>Example:
>>>
>>>- jetspeed-api has some classes for org.apache.jetspeed.page.document
>>>but components/page-manager defines some classes there too.
>>
>>I agree with Ate that we should move all impls into impl directories
>>
>>
>>>- org.apache.jetspeed.security.impl is shared between portal
>>>and components/security
>>>
>>
>>yup we have a few of those with the core valves
>>Somehow the valves got moved out of the valve directory structure,
>>although it didn't start that way. Maybe we should move all valve impls
>>back to org.apache.jetspeed.portal.valves.impl
>>
>>
>>>- in the applications directory, we have sometimes
>>>org.apache.portals.applications, sometimes org.apache.jetspeed.portlets,
>>>org.apache.jetspeed.demo, org.apache.jetspeed.portlet,
>>>org.apache.portals.gems (not including the iBatis and Struts code)
>>>
>>
>>a lot of the demo portlets are early tests that could probably be either
>>  cleaned up or thrown away. Since Gems got voted out of Apache, we can
>>drop that package. Also, Portals Applications was also voted out (much
>>to my dissappointment), but i still like the package name :P, thus I
>>propose org.apache.portals.applications as the root of all portlets
>>
>>so we would have org.apache.portals.applications.demo for example
>>or org.apache.portals.applications.database (to replace the database
>>browsers under gems)
>>
>>
>>
>>>I can understand why we would have 2 base packages one for
>>>jetspeed-specific
>>>and one more generic JSR-168 portlets but 5 packages is a lot :)
>>>
>>
>>yes perhaps a secondary package for jetspeed administrative portlet
>>applications such as
>>
>>org.apache.jetspeed.applications.admin
>>org.apache.jetspeed.applications.palm
>>...
>>
>>
>>>All in all, I think we'd get a lot of value in rationalizating the
>>>whole packages structure although I agree with Ate that doing it right
>>>is difficult.
>>>
>>>My objectives for the refactoring would be:
>>>
>>>- packages should not be shared between components, except one "util"
>>>  package for generally useful code not tied to any Jetspeed
>>
>>fonctionality
>>
>>>- it should be possible by looking at the package to know if a class is
>>>part of the Jetspeed API, Portal implementation, Portlets or stand-alone
>>>component.
>>>
>>>- if possible, components should have all the classes rooted in a single
>>>  package, although they may define sub-packages from there as they wish
>>>
>>>- components and portlets should follow predictable "patterns" of
>>
>>package
>>
>>>  naming conventions.
>>>
>>>Would you agree with objectives or would add/remove some of these ?
>>>
>>>
>>
>>i agree
>>
>>--
>>David Sean Taylor
>>Bluesunrise Software
>>david@bluesunrise.com
>>[office] +01 707 773-4646
>>[mobile] +01 707 529 9194
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 
> 
> 
> 




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


Mime
View raw message