The work on integrating Jetspeed with Geronimo is currently in the sandbox.
This is what the following modules do.
This module installs 5 common jetspeed jars into the G repository.
jetspeed-api-2.0.jar, jetspeed-commons-2.0.jar, pluto-1.0.1.jar, portals-bridges-common-1.0.jar, portlet-api-1.0.jar, derby-10.1.1.0.jar
This is the CAR configuration for jetspeed's derby datasource. It includes the connector module tranql-connector-embed-local.rar. It invokes the o.a.g.connector.DatabaseInitializationGBean which executes the derby SQL scripts that were carried in the above etspeed-database module.
This module carries and installs the jars for jetspeed's portal runtime. It has the JetspeedSerializerGBean which will be used to seed/populate the databases before the portal starts.
This is a configuration for Jetspeed portal application on Tomcat web container.
It carries -
a) db-page-manager.xml, interceptor.xml and request-context.xml that will be needed to seed some tables.
b) geronimo-datasource.xml which will be used by Spring to seed the tables.
c) j2-seed.xml which provide data for seeding the tables.
It invokes the JetspeedSerializerGBean from the above module which uses a bunch of other xmls in the web-inf/assembly directory of the jetspeed application to seed the tables.
During the process-resources phase of building this configuration, the j2-layouts.jar is dropped in the jetspeed app's web-inf/deploy dir. Once the portal app starts running, it deploys the layouts appropriately.
Configuration for the above jetspeed-builder.
The jetspeed portal application starts up fine.
The j2-layouts portlet application seems to deploy fine when placed under web-inf/deploy.
The j2-admin portlet app seems to deploy fine using the jetspped-deployer.
However, accessing the portal app at http://localhost:8080/portal returns a 500 error because the portal loads web-inf/pages/default-pages.psml. This contains fragments from j2-layouts and j2-admin portlet apps. The portal app cannot recognize portlet apps under it.
The portlet app deployed in this portal should have the portal configuration as it's parent. But the portal app now cannot see the child portlet app when it tries to load fragments from it. I think this is what is happening.