Jetspeed 2.2 trunk build status

[Ate Douma <at...@douma.nu>]

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 a 
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 loading.
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 3).
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 space".

So:

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

Ate

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

Re: Jetspeed 2.2 trunk build status

[David Sean Taylor <da...@bluesunrise.com>]

On Mar 31, 2008, at 5:21 PM, Ate Douma wrote:
> 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?).


As long as j2-admin continues to use it, yes. See the Portlet  
Application Manager portlet


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