portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <raph...@apache.org>
Subject Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus: Documentation !)
Date Mon, 06 Jun 2005 08:36:39 GMT
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.

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


-- 
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://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