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:14:31 GMT
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


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