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 Mon, 06 Jun 2005 20:05:28 GMT
Raphaël Luta wrote:
> David Sean Taylor wrote:
>> Raphaël Luta wrote:
>  > <snip>
>>> #2 Start a thread on how to manage our java packages and adopt a 
>>> clear package
>>>   naming policy for the different main code blocks:
>>>   - jetspeed-api
>>>   - jetspeed engine core components
>>>   - jetspeed engine optional components
>>>   - application level code (admin stuff, portlet stuff, etc...)
>>>   - generic utility code
>> So if I understand correctly, you are proposing that if a class is in 
>> the api, say
>> org.apache.jetspeed.aggregator.Aggregator
>> change to:
>> org.apache.jetspeed.api.aggregator.Aggregator
>> another example, in the portal directory, we have
>> org.apache.jetspeed.aggregator.impl.PageAggregatorImpl
>> change to:
>> org.apache.jetspeed.core.aggregator.impl.PageAggregatorImpl
>> final example, in the components/capability directory:
>> org.apache.jetspeed.capabilities.impl.CapabilityImpl
>> change to:
>> org.apache.jetspeed.components.capabilities.impl.CapabilityImpl
>> 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.
> - org.apache.jetspeed.security.impl is shared between portal
> and components/security
> - 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)
> 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 :)
> 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.
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
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.

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

> - 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.
(also see my comment above)

> Would you agree with objectives or would add/remove some of these ?

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.tools. (e.g. deployer)

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
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...


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

View raw message