After working on the geronimo integration for a bit I have an opinion
on what the most important reorganization step is :-)
The current jetspeed.war is basically a tomcat-specific artifact. In
order to work in geronimo, I had to build a jetspeed war without any
classes or lib entries. I think the current war should be built in a
module inside app-servers rather than as the top level artifact. I
also think there needs to be either separate builds for including
different amounts of lib jars or a way of customizing the build to
include different jars. (In M2 I think profiles give you some
control like this).
I'm also not exactly sure what the meaning of most of the stuff in
jetspeed.war is. My uneducated impression is that there are at least
one skin and a site layout. Assuming this bears some relationship to
the actual contents, I think that having these as separate modules
that are unpacked into the jetspeed war would make it much easier for
someone to either construct additional skins or assemble a portal
with exactly the parts they want to use.
I'd be happy to work on a patch for customizing the contents of
jetspeed.war, but I don't think moving the war build into app-
servers is appropriate for a patch since mostly it would be an svn mv
command.
thanks
david jencks
On Jan 8, 2006, at 6:51 AM, David Le Strat wrote:
David,
What about a common-components section? There ought
to be common-components between all the projects. For
instance:
- Component Manager
- Deploy Tools
- Rdbms
- Security (maybe)
- Prefs (maybe)
Thoughts? Also, can we help out.
Let me know.
Regards,
David Le Strat
--- David Sean Taylor <[EMAIL PROTECTED]> wrote:
Ate Douma wrote:
I don't want to restart the discussion we had
about this subject last
month on
the general@ list, but I'd like to see a more
architectural discussion
first which
components are to be considered not j2-specific
or portals generic
before we
start moving things around.
Why don't we move ALL components out to the jetspeed
components project?
Yes, this does mean everything.... but if that makes
it easier to build
the system, and to reuse the components to build
different
configurations of jetspeed, then isnt that a good
thing?
Im going to give this a try...
/portals
/jetspeed-components
/jetspeed-api
/applications
/bridges
/docs
/installers
/configuration
/j2ee-geronimo
/j2ee-tomcat
/j2ee-jetty
/j2ee-jboss
/j2me-geronimo
/j2me-tomcat
/j2me-jetty
....
Here are the top level directories currently in J2:
app-servers - move to configurations
applications - move to applications
archives - do we need this?
commons - move to jetspeed-components/commons
components - move to components
content-server - drop
design-docs - move to docs
docs - move to docs
etc - move to configuration
graphic_design - move to docs
installer - move to installers
installer2 - move to installers
jetspeed-api - move to jetspeed-api
layout-portlets -
maven-plugin - move to configuration
patched-jars - ?
portlet-api - drop
src - move to configurations
taglibs - move to applications
xdocs - move to docs
Basically we are breaking Jetspeed apart.
There will be nothing left but configurations!
We are victims of our own component architecture :)
Thats why Im leaving the jetspeed name on both the
api and components.
We could also call these portals-api or
portals-components or just plain
components or api...but I think anything other than
the jetspeed name
seems a bit destructive. I mean do we want to kill
the jetspeed name
just after our final release? :)
Or is jetspeed now nothing more than just another
configuration of
"components". I think the jetspeed team is in a
funny situation. We want
others to use our api and components, but we don't
want to give up the
ownership.
I also think we need to make a pass over the
components
All of the components found under components/portals
should be moved to
top level components
Are any of the components "jetspeed" specific?
You could argue that the engine or the pipeline is
As for the build, we need to switch over to Maven-2
This refactoring and build conversion seems like a
lot of work
Using a branch to do so might be the best solution
Its either that or we all stop developing against
the trunk for a few
days and work together to migrate
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
