portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject proposal for war assembly reorganization
Date Sat, 18 Nov 2006 18:10:35 GMT
I'm hoping to create some time to work on the geronimo-jetspeed2 integration I started last
year at this time and started looking at jetspeed a bit again.  I've never been happy with
how the wars are assembled but now after watching Jason Dillon m2-ize and clean up the geronimo
build I have an idea how to improve it.

So right now the war assembly module "portal" runs an ant script that reaches into all sorts
of place outside the module and has a lot of conditional logic to try to decide what to copy
from src and etc and what to filter and where to put it into the war.  I find this impossible
to understand and it is certainly very anti-maven philosophically.

What I propose is that each bit of stuff for which there's a choice about including in the
war be moved to a separate "resource-bundle" module and jarred up into an artifact.  Then
to assemble a war you can unpack the resource-bundles you want, add the classes and libs you
want, and war it up.  This is easy to do entirely in m2 and I find it much clearer.

I cooked up a  quick start on this idea that I put at 

http://people.apache.org/~djencks/jetspeed-2/

The jar unpacks to the project (unpack in jetspeed2/trunk) and there's also a patch file.
 My experience is that large svn patches don't work so the jar is likely to give better results.

After unpacking, cd assembly;mvn

I've verified that the list of files in the war in jetspeed-portal-full is the same as the
list of files in the normal jetspeed war except for a bunch of maven pom-like files and WEB-INF/pages/minimal-default-page.psml
which can be left out of the full war since with this scheme copying files over each other
by hand isn't needed.

I verified that maven filtering is working but not that the results of filtering are identical
to those from the existing build.  If they aren't this is just a matter of adding some maven
properties.

At the moment this just makes a full build.  It's easy to add things like the db page manager
by having a resource-bundle jar for it: if people like this idea I'll finish converting all
the other choices to this scheme.  Choices about what to include can be handled either by
profiles or by simply building a lot of different wars.

From my perspective this looks like a big improvement.  I'd like to get some other opinions
fairly soon and perhaps commit this in the next few days.  We could maintain 2 copies of this
stuff for a while but it is extra work.

Currently I'm using a maven plugin from geronimo that jason dillon wrote to help with the
resource bundles.  If people don't like this geronimo dependency we can simple copy the plugin
into jetspeed or see if we can get it into m2.

I have some other questions about the build...

Is the maven 1 stuff still used? Can I delete it?
Can I reorganize the modules to standard m2 dir structure? (such as src/main/java instead
of src/java)
Can I rename the modules so they match the artifactId?  This lets you remove a bunch of cruft
from the poms.

Where did the dojo.zip come from?  It's not the same as the dojo zip file we found for geronimo....

Many thanks,
david jencks




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