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 16:50:01 GMT


> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Tuesday, June 07, 2005 12:30 PM
> To: Jetspeed Developers List
> Subject: Re: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus:
> Documentation !)
> 
> Scott T Weaver wrote:
> > 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.
> 
> It also makes it very easy to replace a component.
> If someone wants to override the page manager component, simply swap out
> the jar. If we merge all components into one jar it will make this kind
> of pluggable component integration more difficult for integrators.

I don't see how this makes it any more difficult than what we already have
in place.  There has never been a need to remove the existing component jar
when creating a custom code to replace it.  All the developer has to do is
drop in there custom jar/classes and change the Spring configs to point to
their custom classes.  I don't see how being able to remove the default
implementation jar increases the efficiency of this process.


> 
> > 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.
> >
> 
> What if we based the entire build on the plugin?
> That way we wouldn't have both the maven.xml and plugin to maintain.
> Might be a good time to look at Maven 2


+1.  That would be great to use the plugin to perform all builds.  This
would probably require a major refactoring of the current plugin, but I feel
it needs it anyways.

As for Maven 2, that seems a bit scary.  Just as all of our end users are
starting to tolerate Maven 1, we pull the rug right out from under them so
to speak.  As much as Maven 2 is probably an improvement over Maven 1, I am
a bit leery to disenfranchise people with requiring them to learn yet
another build system.  I guess it really depends on how much better 2 is,
unfortunately, I know nothing about 2 :(

> 
> > 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.)
> >
> sounds good, i link the name 'engine', although 'portal' is good too
> i think i prefer 'applications' over demos though as they can be useful
> as is not just demos

Sure "applications" is fine.

> 
> a few odd ones not covered here:
> 
> content-server
I think we could stick that under engine.

> installer
Installer could go under deployment as an optional task to build it.

> layout-portlets
Hmmm, might do well as its own subproject.

> taglibs
This might also be able to live happily under engine.

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