portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus: Documentation !)
Date Tue, 07 Jun 2005 07:21:22 GMT
Ate Douma wrote:
> +1
> But, I don't like to see an artificial package name like 'api'. I much
> prefer the commonly used separation and distinction of 
> core/implementation packages using an
> impl subpackage.
> And the same rule should apply for distinction of interfaces and 
> implementations:
> if an Class is an implementation of an interface we should postfix it 
> with Impl.

yes, i don't like api in the package path either

> A special case may be interfaces defined in the core (portal subproject).
> Should these (all) be moved to jetspeed-api?

not if they aren't meant to be public
otherwise they can remain under impl

> I would not be very much in favor as it would require exposure of 
> core/implementation
> specific api. These interfaces are not meant to be used by 
> Portal/Portlet users/developers
> but by integrators needing to configure/adapt the Jetspeed core features 
> itself.
> On the other hand, there are maybe some which are quite independent and 
> as such could be
> moved into jetspeed-api.
well, yes, if we find them to be public apis, then move them

> To get more to the point, do you only want to "cleanup", remove some 
> package mix ups between
> different components/core or do you (also) want to define a more strict 
> separation of the
> (type of) packages?
> Something like a restricted set of root packages as below:
>   o.a.j.portal.
>   o.a.j.container.
>   o.a.j.components.
>   o.a.j.portlets.
>   o.a.j.applications.

would o.a.j.portlets be for reusable portlets that are not a part of any 

>   o.a.j.utils.
>   o.a.j.tools. (e.g. deployer)
overall +1, although see my comments on org.apache.portals.applications 
in my response to Raphael

> In my opinion, the above separation would be a great improvement but 
> also touch almost every
> class in the whole codebase and an awfull lot of work ...
> Although I think I would be in favor of this too, I can imagine some 
> will be strongly against it because then almost all custom enhancements 
> / integrations will have to be modified as result of it.
> But, if we would "like" to do this: not doing it now probably means 
> never doing it...
All my current installations/integrations run against milestone builds.
Shouldn't be too much trouble ...
Im +1 for the refactoring, although I'd like to have a close look at the 
main refactoring of org.apache.jetspeed.portal and 


David Sean Taylor
Bluesunrise Software
[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

View raw message