portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Le Strat (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-304) Build Process Clean Up
Date Wed, 13 Jul 2005 00:34:11 GMT
    [ http://issues.apache.org/jira/browse/JS2-304?page=comments#action_12315646 ] 

David Le Strat commented on JS2-304:

As part of step 2 of the build process clean up, I propose to centralize most of the Jetspeed
2 custom goals to the Jetspeed 2 Maven Plugin.  The reasons for doing so are multiple:

1. Provide better reusability of common build goals.  Users creating a new portal application
should be able to leverage Jetspeed 2 Maven plugin for common build operations.
2. Provide the ability to quickly get started with a portal application.  A new target j2:genapp.portal
will be created to create a shell portal application.  The developer of the new
application can reuse the Jetspeed 2 Maven plugin goals for common build operations for quickStart,
portlet deployment, etc.
3. Prepare for a migration to M2 in the future.  With M2, custom goals are encapsulated in
plugins, maven.xml is deprecated.  By centralizing most of the Jetspeed 2 build goals to the
Jetspeed 2 Maven plugin, migration to M2 should be much easier.

In addition, I proposed to remove the site directory as it duplicates application documentation.
It would also be a good idea to revive the documentation framework discussion, and centralize
the documentation location, Raphael had a forrest proposal out there, why not.  We could also
stick with Maven, but in any case, we should clean things up and improve docs.  I remember
reading about a Documentation project going on leveraging the WIKI.  I would be nice to clarify
the approach for improving documentation (xdocs, WIKI, both?)

Finally, as part of this clean up, I have moved a few things around, most notably the /src/sql
and /src/schema directories that are now part of maven-plugin/plugin-resources.

Please find below a much more detailed description of the clean up proposed.


Move the following targets from /maven.xml to maven-plugin:

- start.production.server now called j2:start.production.server
- start.test.server now called j2:start.test.server
- db.execute now called j2:db.execute

- Moved copy.shared.deps to j2:copy.shared.deps

- db.scripts.gen now called j2:db.scripts.gen
- db.test.properties now called j2:db.test.properties
- db.production.properties now called j2:db.production.properties
- db.create.test now called j2:db.create.test
- db.create.production now called j2:db.create.production
- db.create now called j2:db.create
- db.recreate now called j2:db.recreate

- db.drop.test now called j2:db.drop.test
- db.drop.production now called j2:db.drop.production
- db.drop now called j2:db.drop
- db.drop2 now called j2:db.drop2
- db.drop.oracle now called j2:db.drop.oracle

Move the following targets from /portal-webapp to maven-plugin:

- catalina:base-shared moved to j2:catalina.base.shared
- catalina:shared moved to j2:catalina.shared
- Removed db.execute. Duplicated in plugin.
- Removed db.test.properties. Duplicated in plugin.
- Removed db.production.properties. Duplicated in plugin.
- Removed catalina:base-shared. Duplicated in plugin.
- Removed catalina:shared. Duplicated in plugin.
- Removed basicDeploy.  Redundant with minDeploy.
- Removed nodbBasicDeploy.  Redundant with nodbMinDeploy.

- Delete portal-webapp/src/sql.  Not used.

- Moved deploy to maven plugin j2:portal.deploy

- Moved fullDeploy to maven plugin j2:fullDeploy
- Moved nodbfullDeploy to maven plugin j2:nodbfullDeploy
- Moved minDeploy to maven plugin j2:minDeploy
- Moved nodbMinDeploy to plugin j2:nodbMinDeploy

- Moved pam.* to maven plugin j2:pam.*

Clean /maven-plugin maven.xml:

- Removed copyDb target. Not need anymore.  SQL files were relocated.
- Removed db.execute. Duplicated in plugin.
- Remove db.create. Duplicated in plugin.

Clean all maven.xml

- Removed deployJar.  Moved to maven plugin j2:jar.deploy
- Moved shared deployJar target to maven plugin j2:jar.deploy.shared

Update Getting started documentation.

- maven initMavenPlugin allClean allBuild is now required instead of maven allClean allBuild
if the latest version of the maven plugin is not installed.
- I also provide documentation on how to set up the latest version of the plugin without requiring
a J2 checkout.

Documentation Changes.

- Deleted site.  Currently duplicate of xdocs.
- Updated allSite target to generate multiprojects site.  This is not working.  Any suggestions
on this is appreciated.

Creation a new portal application.

- j2:genapp.portal Documentation

- Add to build.properties in {user.home}:
    - org.apache.jetspeed.genapp.home=C:/tools/workspace/testportal
    - org.apache.jetspeed.genapp.groupId=testportal
    - org.apache.jetspeed.genapp.name=My Test Portal
    - org.apache.jetspeed.genapp.currentVersion=1.0
- Get started with new project: maven j2:genapp.portal

- In testportal dir, run maven j2:portal.install

Updated getting started documentation.
Added new documentation section: Under Essentials: Jetspeed 2 Maven Plugin

Until the Jetspeed 2 web site is regenerated, <a href="http://www.geocities.com/dlestrat/etc/j2/buildChangeDocs.pdf">click
here</a> to get documentation on how to use the updated maven plugin.

> Build Process Clean Up
> ----------------------
>          Key: JS2-304
>          URL: http://issues.apache.org/jira/browse/JS2-304
>      Project: Jetspeed 2
>         Type: Improvement
>   Components: Project Build
>     Versions: 2.0-M4
>     Reporter: David Le Strat
>     Assignee: David Le Strat
>      Fix For: 2.0-M4

> 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
> 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:
> \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).
> Building the portal in this structure should be possible by leveraging the deployed Jetspeed
> * 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
> 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
> ## Rename the web application to portal-webapp and the artifact id to jetspeed-portal
(to remove conflict
> with the jetspeed component artifact).
> ## Move the test directory under portal-webapp to components/portal/test as it support
the portal
> components tests.
> ## Add org.apache.jetspeed.PortalTestConstants to centralize initialization of JETSPEED_PROPERTIES_PATH
> Clean up the portal-webapp (previously portal) build and maven-plugin.
> # 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
> Therefore, I propose to perform the following cleanup in the portal-webapp (previously
> ## 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
> ## Remove deployJar and deployClasses.  portal-webapp now uses dependencies for the portal
> library.
> ## Remove jar:jar target.
> ## Clean plugin.jelly: jetspeed2:register and jetspeed2:unregister.  Not used.
> Have portal-webapp depend on the built Portlet dependencies rather that the build target
> # Modify the maven.xml pam.(portlet)deploy target and the maven-plugin to use the archived
portlet war
> deployed to the repository (maven install).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

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

View raw message