portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus: Documentation !)
Date Tue, 07 Jun 2005 14:53:45 GMT
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




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


Mime
View raw message