portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Jetspeed 2.2 trunk build status
Date Tue, 01 Apr 2008 00:21:56 GMT
I did a of refactoring to the Jetspeed 2.2-SNAPSHOT trunk the last few weeks and especially
the changes I committed 
today are quite big.

So I like to provide a little status update of what I did so far and what's still in the pipeline.
And, at the end of this message, I'll provide instructions how to build/test the current trunk.

Previous weeks, I've been working on updated and new maven-2 plugins for database initialization,
resource unpacking and 
deployment. These are not finished yet, especially the deploy plugin is still very limited,
but I'm planning to work and 
complete those ASAP. The database plugin also needs some additional features, like executing/loading
JetspeedSerializer j2-seed.xml script, and I'm also planning to add a ddlutils schema+data
import/export features.

Another new feature, which was discussed before on the list, is conditional Spring assembly
I've now committed a basic solution for this using extended versions of Spring ApplicationContext
classes for loading 
through FileSystemXml-, ClassPathXml- and XmlWeb- versions (in Jetspeed, we only use these
The concept is simple: by plugging in an extended BeanFactory which checks a loaded Spring
BeanDefinition for some extra 
meta data (defined within the Spring configuration itself) against a predefined configuration,
registering a 
BeanDefinition within Spring can be "prevented", effectively filtering out certain definitions.

Although the Spring assembly filtering is now technically available, configuring and using
it still needs to be done. By 
not yet providing a filter, the current default behavior is still preserved.
I'm planning to add assembly filtering, initially just for testing, later this week.

Lastly, I've modified the default maven surefire execution for all tests to use forkMode=never...
The first reason to do this was to support the m2eclipse plugin (see: http://m2eclipse.codehaus.org).
This great Eclipse plugin supports running maven 2 against a project pom.xml and also provides
a dynamic maven based 
classpath container to eclipse (no more need for generating or hand editing .classpath).
For debugging testcases, this plugin works perfectly (just set a breakpoint and run the goal),
but this only works with 
surefire forkMode=never.

A lot of the changes I committed today were related to fixing running *all* tests in one build
using forkMode=never.
A lot of bugs and issues prevented running multiple test (especially reloading a Spring container
and restarting Derby) 
within one JVM. As of now, everything works again, but ... with some caveats.

For one, maven surefire creates a new ClassLoader instance for every project when it runs
in forkMode=never.
As a consequence (on a Sun JVM) this quickly can result in: "java.lang.OutOfMemoryError: PermGen


For Jetspeed committers and other developers/testers who are required to do a full test build,
make sure to set the 
following evironment variable to prevent running out of PermGen space:

   export MAVEN_OPTS="-XX:MaxPermSize=256m"

Although this JVM PermGen issue might seem problematic, I think the benefit of running all
tests in forkMode=never is 
far more important, and not just to support the m2eclipse plugin. I've discovered and fixed
many issues which would 
prevent reloading the Jetspeed Spring container, and definitely the portal application itself
(which we already knew 
wasn't possible).
Although I haven't been able to test this yet, I think we are now in much better shape to
make this working (if not 
already). So, I definitely think we as committers should stick to using forkMode=never from
now one.

Finally, here are instructions how build/test the current trunk.
All the following instructions should to be run in the root project folder.

After a first clean checkout, first the plugins and jetspeed-portal-resources artifact need
to be build separately *if* 
you want/need to start out by running the tests right away.
(Note: for plain building without running the tests, just run: mvn install, and thereafter
the following won't be needed 
anymore either).

   mvn install -P init

Again: this only needs to be done once, is only needed for running the tests (initially) and
only as long as these 
artifacts are not yet available remote.

If you want to run the tests, first a test database needs to be (re)created:

   mvn jetspeed-db:load -P test-db

If you want to initialize the production database, use profile: -P prod-db
BTW: you can run the jetspeed-db:load goal from within other single (but not multi-module
pom) sub modules too.

Building jetspeed without running tests is plain standard:

   mvn install

And for building/running the tests provide profile -P test:

   mvn install -P test

For the database configuration and the tests using it, some required properties need to be
defined in your local 
settings.xml (by default located in ~/.m2).
As an example and default I've provided a new settings.xml.minimal.derby file in the project
root folder.
Most of the required properties are still the same as before, but some are no longer needed
([...]jdbc.drivers.path for 
instance) while others now are required, like the jdbc driver maven artifact coordinate properties.
The other settings.xml.sample is somewhat outdated and still needs to be synced!

Although I'm going to continue working on the maven build and adding more plugin features
etc., I'm inviting the other 
committers to now take a good look at the current status and if possible help out converting
the other remaining 
modules/projects which need to be integrated for a minimal portal deployment, like j2-admin,
jetspeed-layouts or 
(treecontrol: do we still need this?).

Kind regards,


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message