portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] Build Process Summer Time Clean Up
Date Tue, 05 Jul 2005 01:01:30 GMT
David Sean Taylor wrote:
> David Le Strat wrote:
>> All,
>> I finally got some time to get back to J2. I have a
>> proposal for some summer time J2 build process clean
>> up.
>> Jetspeed2 current build process is a bit confusing. Through the 
>> various evolutions of J2 build process,
>> many targets have been accumulated that make it
>> difficult to easily understand the build process flow.
>> h2. Cleaning up the build process
>> Using J2 in its current form requires an in-depth
>> understanding of how J2 build internals operate.
>> As an example, an integrator wanting to get starting
>> with J2 will want to start with the portal web
>> application and customize it from there.  It should be
>> made easy for integrators to get started with the web
>> application without requiring an in-depth
>> understanding of the various sequences in the build
>> process.
>> A typical implementation will want to create a project
>> as described below:
>> {noformat}
>> \sample-portal
>> +---\etc                 Contains the build
>> dependencies definition.
>> +---\portal-webapp       Contains the portal web
>> application being built.
>> +---\src                 Contains the portal
>> initialization source (db scripts, etc).
>> {noformat}
>> Building the portal in this structure should be
>> possible by leveraging the deployed Jetspeed
>> dependencies:
>> * Components: All libraries (jars) required for the
>> runtime operation of the portal engine.
>> * Portlets: All web libraries (wars) required for the
>> runtime operation of the portal engine.
>> Integrator using Jetspeed2 should be able to do so
>> easily and to easily get (through dependencies) the
>> latest versions of the release Jetspeed components
>> (libraries as well as portlets).
>> The current maven-plugin and portal build
>> implementation rely on the source build (target
>> directories) rather than the dependencies for the
>> assembly of the portal engine, making it more
>> difficult to get quickly started and to keep up with
>> enhanced components.
>> h2. Proposed changes
>> The proposed changes below clean up the build process
>> and slightly reorganize some elements to more easily
>> achieve the goals outlined above.
>> The first changes restructure the portal directory as
>> follow.
>> # Remove all non web related dependencies from portal:
>> ## Move the portal java source and java tests to
>> components/portal.  This becomes a component that will
>> be released as jetspeed-(version).jar
> +1 in general, but don't all components follow a naming pattern of
> jetspeed-{COMPONENT_NAME}-{VERSION}.jar?
>> ## Rename the web application to portal-webapp and the
>> artifact id to jetspeed-portal (to remove conflict
>> with the jetspeed component artifact).
> Maybe this artifact should be jetspeed-{VERSION}.war
>> ## Move the test directory under portal-webapp to
>> components/portal/test as it support the portal
>> components tests.
> +1
>> ## Add org.apache.jetspeed.PortalTestConstants to
>> centralize initialization of JETSPEED_PROPERTIES_PATH
>> Clean up the portal-webapp (previously portal) build
>> and maven-plugin.
> I think that all build goals should be a part of the plugin.
> Why have both plugin goals and maven.xml goals?
> I'd also like to propose moving to Maven-2 as a part of this refactoring.
> I think we should consider project archetypes for quickstarts and 
> replacing the current build with a M2 build.
> Overview (from my notes at JavaOne):
> * Super-POM: defaults across all projects
> * transitive dependencies
> * dependency scoping
> * dependency management
> * better control over snapshots
>    - only check one snapshot per build
>    - or check snapshot once per time period (day, hour..)
> * post/pre goals removed
> * build is now based on a lifecycle
> * maven.xml, project.properties deprecated
> * parent projects can be declared, no more ../..
> * plugins configurable, POM based, auto-downloaded
> * Plugin languages supported: Java Beanshell, Marmalade
> * Explicit definiition of multiprojects
>    <modules>
>     <module>subproject-1</module>
>     <module>subproject-2</module>
>         ....
> * Project archetypes for quickstarts
>> # Clean portal/maven.xml:
>> ## Remove commented calls to targets.
>> # The deploy and undeploy calls in the portal-webapp
>> (previously portal) build process should be using the
>> maven-plugin to do so.  Multiple deploy, undeploy,
>> register, unregister behaviors create confusion. Therefore, I propose 
>> to perform the following cleanup
>> in the portal-webapp (previously portal):
>> ## Remove pam.template.deploy.  This is not used.
>> ## Remove pam.unregister.  Depends on
>> pam.template.register which is not being used.
>> ## Remove pam.template.register. This is not used.
>> ## Remove pam.template.undeploy. There is a
>> jetspeed2:undeploy target in the jetspeed plugin.
>> ## Rename pam.register to pam.layoutdeploy.  This
>> really deploys the layout portlet and should be
>> consistent with the other deploy targets.
>> ## Rename pam.deploy to pam.demodeploy.  This deploys
>> the demo application.
>> ## Rename pam.undeploy to pam.demoundeploy.  This
>> undeploys the demo applications.
>> ## Rename pam.rss to pam.rssdeploy for consistency
>> purpose.
>> ## Modify the pam.(portlet)undeploy targets to use the
>> jetspeed maven plugin jetspeed2:undeploy target.
>> ## Remove deployJar and deployClasses.  portal-webapp
>> now uses dependencies for the portal component
>> library.
>> ## Remove jar:jar target.
>> ## Clean plugin.jelly: jetspeed2:register and
>> jetspeed2:unregister.  Not used.
> +1, remove all Jelly, move to M2
>> Have portal-webapp depend on the built Portlet
>> dependencies rather that the build target directories.
>> # Modify the maven.xml pam.(portlet)deploy target and
>> the maven-plugin to use the archived portlet war
>> deployed to the repository (maven install).
> I like this idea of the portal-webapp, since its great for starting new 
> projects where the goal is to customize the portal with your own skins, 
> and your own build.
>> Let me know if you are alright with the proposed
>> changes and I will go ahead and create an issue as
>> well as implement the changes. I am almost doen.  I
>> just need to perform some final testing locally and
>> get everyone's blessing.
> You have my +1, although I propose going a step further and moving to M2
I'm +1 on this too (for starters) but like to add some additional ideas.

I looked into M2 for the first time this evening (but not tried it yet)
and I do like it so far.
But, I'm not sure its ready for use yet for J2. At least, the website docs
didn't give me that impression. Maybe in a month or two?

Anyway, I agree with David Sean Taylor that I'd like to see all portal build/deploy/install
goal functionality moved to the plugin *only*.
The way it now duplicates things I don't very much like.
But, I also don't like the way a specific plugin version is so much dependent on a
specific Jetspeed configuration. I currently packs all configuration scripts, dependency
definitions, sql scripts etc. inside the plugin.

In my own integration builds for clients I don't use the plugin but base my portal setup
directly on an repo installed version of the jetspeed war.
For a specific portal, I extract the jetspeed.war in the project build folder, run some ant
and/or replace assembly files and remove/overlay some others files (like new decorators and
additional portlet applications etc.

I think we could provide a solution which has the benefits of both solutions and without
the problems I see with the plugin.

The main idea of David Le Strat that we should provide an integration build based on installed
components from the repository I'd like to extend to providing the integration build *configuration*
too as installed (template) component (thus *not* embedded in the plugin).

What if we would build a jetspeed-portal-template-<VERSION>.jar (not .war) which contained
the proposed portal-webapp as well as its dependency (pom) definitions, sql (or schema) scripts,
app server templates (like the different tomcat context files, JBoss/Webspere/BEA configs
and a default build.properties.
Then the plugin could use that template to build a concrete portal,
support (merge) overlay definitions (if any) and *not* be dependent on the concrete jetspeed
resources itself but derive those from the template and/or from a custom user build.properties.

For our current portal project we then could be a completely empty project except for a project.xml
a maven.xml executing nothing but the default plugin goals. A nice starter project for integrators!
We can even add an integrators project template goal to the plugin setting up such a project.
Stuff like portal name, context path and app server version can then be setup already for

The plugin itself wouldn't need to be build and installed each and every time again. Only
when new
features to the plugin are added. It really can have its own release cycle and version then,
from Jetspeed.

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

View raw message