portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From woon...@apache.org
Subject svn commit: r711335 [2/2] - in /portals/jetspeed-2/portal/trunk: maven/src/ src/site/ src/site/xdoc/maven/
Date Tue, 04 Nov 2008 18:09:04 GMT
Added: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml?rev=711335&view=auto
==============================================================================
--- portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml (added)
+++ portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml Tue Nov  4 10:09:03
2008
@@ -0,0 +1,181 @@
+<?xml version="1.0"?>
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+  
+  http://www.apache.org/licenses/LICENSE-2.0
+  
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+
+  $Id$
+-->
+<document>
+  <properties>
+    <title>Standard structure of Jetspeed Portal Maven projects</title>
+    <authors>
+      <person name="Ate Douma" email="ate@douma.nu" />
+    </authors>
+  </properties>
+  <body>
+    <section name="Standard structure of Jetspeed Portal Maven projects">
+      <p>
+        A typical custom Jetspeed Portal project usually concerns not only a (sub) project
for building and configuring the custom Jetspeed Portal
+        itself but also one or more specific portlet (sub) projects delivering the portlet
application(s) to be deployed to the Jetspeed Portal.
+      </p>
+      <p>
+        The following standard project structure is commmon practice and in line with standard
Maven project guidelines and easily expandable and adjustable
+        to incorporate future changes of the project goals and requirements. 
+      </p>
+      <p>
+        The <a href="jetspeed-archetype.html">Jetspeed-archetype Maven Plugin</a>
can be used as a quickstart to setting up a new custom Jetspeed Portal project
+        and will create a project structure using this standard layout. Furthermore, the
Jetspeed archetype plugin will also provide a typical and default
+        setup and configuration for the <a href="jetspeed-maven-plugins.html">Jetspeed
Maven Plugins</a> for automating and performing Portal integration tasks for the
+        target environment(s) directly from within the Maven build itself. 
+      </p>
+      <subsection name="The super project">
+        <p>
+          To support central management and configuration of all (or most) the individual
(Maven) project artifacts and (Jetspeed) integration tasks, a
+          master "super" root Maven project pom.xml is used of type &lt;packaging&gt;pom&lt;/packaging&gt;.
+        </p>
+        <p>
+          This root project will contain one or more modules, defined as subprojects, which
in turn will have this root project defined as their parent
+          project. This way, all artifacts will be buildable and installable as a whole directly
from the root project, and (Jetspeed) integration tasks
+          can be executed from anywhere within this project structure (using the <a href="jetspeed-mvn-plugin.html">jetspeed:mvn
plugin</a>).
+        </p>
+        <p>
+          In addition to the "standard" pom.xml, one or more custom jetspeed-mvn-(target
name)-pom.xml Maven project files can be defined for the super project,
+          as well as corresponding jetspeed property files and even a custom override of
the default Maven settings.xml configuration with a jetspeed-settings.xml file.          
+        </p>
+        <p>
+          The custom jetspeed property files and custom jetspeed-settings.xml will serve
a default and fallback configuration which will be automatically
+          looked up through the project parent chain if a sub project doesn't provide these
by itself when performing sub project specific integration tasks
+          using the <a href="jetspeed-mvn-plugin.html">jetspeed:mvn</a> Maven
plugin.
+        </p>
+      </subsection>
+      <subsection name="The portal sub project">
+        <p>
+          For building and configuring the custom Jetspeed portal itself, as well as configuring
and running Jetspeed Portal specific integration tasks,
+          a separate "portal" subproject of the root project is used. As a Jetspeed Portal
is "just" a web application, &lt;packaging&gt;war&lt;/packaging&gt;
+          is used for its pom.xml
+        </p>
+        <p>
+          In addition to the "standard" pom.xml, one or more custom jetspeed-(target name).xml
or even jetspeed-(target name)-(target alias).xml Maven
+          project files can be defined for this sub project, as well as corresponding property
and even a custom override of the default Maven settings.xml
+          configuration with a ((sub)project specific) jetspeed-settings.xml file.  
+        </p>
+        <p>
+          Custom jetspeed property files and a custom jetspeed-settings.xml defined within
a subproject can be used to override other defined files higher up
+          the project parent chain when performing sub project specific integration tasks
using the <a href="jetspeed-mvn-plugin.hyml">jetspeed:mvn</a> Maven plugin.
+        </p>
+        <p>
+          For building the custom Jetspeed Portal war artifact, the war overlay mechanism
is used in the pom.xml, using the Jetspeed-2 provided jetspeed application
+          project war artifact as overlay. This jetspeed war <em>only</em> contains
the default (demo) Jetspeed Portal web application resources.
+        </p>
+        <p>
+          For pulling in the required web application jar dependencies (to be put under its
WEB-INF/lib) folder, the pom.xml can include a dependency on the
+          jetspeed-dependencies project (pom) artifact. The advantage of separating the dependencies
from the default jetspeed application war is that the
+          jetspeed-dependencies dependency itself can be further restricted or overridden
within the pom. This wouldn't be possible (using standard Maven configuration)
+          when these dependencies were part of the prebuild jetspeed war already.
+        </p>
+      </subsection>
+      <subsection name="Portlet Application sub project(s)">
+        <p>
+          For building additional portlet application particular to the custom Jetspeed Portal,
one or more separate "portlet application" subproject of the root project
+          can be added (note: a common abbriviation for "portlet application" is "pa"). As
a pa also is "just" a web application, again
+          &lt;packaging&gt;war&lt;/packaging&gt; is used for its pom.xml.
+        </p>
+        <p>
+          And, like with the portal sub project, a pa sub project can have, in addition to
the "standard" pom.xml, one or more custom jetspeed-mvn-(target name)-pom.xml
+          Maven project files defined for this sub project, as well as corresponding property
and even a custom override of the default Maven settings.xml configuration
+          with a ((sub)project specific) jetspeed-settings.xml file.  
+        </p>
+        <p>
+          For a portlet application sub project though, this really is optional, as by default
a portal only requires just its war file to deploy and install it.
+        </p>
+        <p>
+          One typical use-case where additional integration tasks might be needed is when
the portlet application defines and makes use of a custom database
+          backend (or likewise: ldap, JCR etc.) which might need to be setup/created/upgraded
or whatever. If an appropriate Maven plugin is available for performing
+          such an integration task (e.g. like the <a href="jetspeed-db-init-plugin.html">jetspeed-db:init
plugin</a>), standardizing and automating the execution of such
+          tasks using the <a href="jetspeed-mvn-plugin.html">jetspeed:mvn plugin</a>
will be very easy.
+        </p>
+        <p>
+          Like with the portal project, custom jetspeed property files and a custom jetspeed-settings.xml
defined within a subproject can be used to override other defined
+          files higher up the project parent chain when performing sub project specific integration
tasks.
+        </p>
+      </subsection>
+    </section>
+    <section name="Conceptable project directory layout and contents">
+      <p>
+        Using the above specification a conceptable custom Jetspeed Portal directory layout
and its contents looks like this:
+      </p>
+      <source><![CDATA[
+/my-portal-project
+  | pom.xml                                                  // standard maven "super" pom
for the whole of the my-portal project
+  | jetspeed-mvn.settings.xml                                // project scoped maven settings
configuration for integration tasks execution
+  | jetspeed-mvn-<target name>-pom.xml                       // custom pom providing
the "build" tasks for a global/generic jetspeed:mvn target
+  | jetspeed-mvn.properties                                  // default                 
    properties for jetspeed:mvn target execution
+  | jetspeed-mvn-${target name}.properties                   // default target name specific
properties for jetspeed:mvn target execution
+  | jetspeed-mvn-${target name}-${target id}.properties      // default target id   specific
properties for jetspeed:mvn target execution
+  + /my-pa1
+      | pom.xml                                              // standard maven my-pa1 war
pom
+      | jetspeed-mvn.settings.xml                            // my-pa1 scoped maven settings
configuration for integration tasks execution
+      | jetspeed-mvn-${target name}-pom.xml                  // custom pom providing the
"build" tasks for my-pa1 specific jetspeed:mvn target
+      | jetspeed-mvn.properties                              // my-pa1 specific         
       properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}.properties               // my-pa1 and target name specific
properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}-${target id}.properties  // my-pa1 and target id   specific
properties for jetspeed:mvn target execution              
+  + /my-pa2
+      | pom.xml                                              // standard maven my-pa2 war
pom
+      | jetspeed-mvn.settings.xml                            // my-pa2 scoped maven settings
configuration for integration tasks execution
+      | jetspeed-mvn-${target name}-pom.xml                  // custom pom providing the
"build" tasks for my-pa2 specific jetspeed:mvn target
+      | jetspeed-mvn.properties                              // my-pa2 specific         
       properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}.properties               // my-pa2 and target name specific
properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}-${target id}.properties  // my-pa2 and target id   specific
properties for jetspeed:mvn target execution              
+  + /my-portal
+      | pom.xml                                              // standard maven my-portal
war pom using war overlay mechanism 
+      | jetspeed-mvn.settings.xml                            // my-portal scoped maven settings
configuration for integration tasks execution
+      | jetspeed-mvn-${target name}-pom.xml                  // custom pom providing the
"build" tasks for my-portal specific jetspeed:mvn target
+      | jetspeed-mvn.properties                              // my-portal specific      
          properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}.properties               // my-portal and target name
specific properties for jetspeed:mvn target execution
+      | jetspeed-mvn-${target name}-${target id}.properties  // my-portal and target id 
 specific properties for jetspeed:mvn target execution]]>
+      </source>
+    </section>
+    <section name="Simple project directory layout and contents">
+      <p>
+        In practice not all of the above possible directories and files will be needed.
+      </p>
+      <p>
+        A typical custom Jetspeed Portal project is much simpler and by default will looks
like this:
+      </p>
+      <source><![CDATA[
+/my-portal-project
+  | pom.xml                                // standard maven "super" pom for the whole of
the my-portal project
+  | jetspeed-mvn-dev.settings.xml          // project only maven development settings configuration
for integration tasks execution
+  | jetspeed-mvn-prod.settings.xml.sample  // sample project only maven production settings
configuration for integration tasks execution:
+                                           //   typically, production settings contain security
sensitive parameters which should not be
+                                           //   committed to a version control system and
a concrete jetspeed-mvn-prod.settings.xml would
+                                           //   not be allowed to be committed.
+                                           //   the sample configuration then just provides
a template to be copied and further configured
+                                           //   by the developer/deployer locally. 
+  | jetspeed-mvn-db-pom.xml                // custom Maven pom for executing the jetspeed-db
plugin through jetspeed:mvn 
+  | jetspeed-mvn.properties                // common (shared for development and production)
properties for jetspeed:mvn target execution
+  + /my-pa
+      | pom.xml                            // standard maven my-pa war pom
+      + /my-portal
+          | pom.xml                        // standard maven my-portal war pom using war
overlay mechanism 
+          | jetspeed-mvn-deploy-pom.xml    // custom Maven pom for executing the jetspeed-deploy
plugin through jetspeed:mvn]]>
+      </source>
+      <p>
+        The above example project structure is what the <a href="jetspeed-archetype.html">Jetspeed
Archetype Maven plugin</a> generates, where
+        the "my-" prefix and the maven artifact coordinates (groupId,artifactId,version)
are configurable.
+      </p>  
+    </section>
+  </body>
+</document>
\ No newline at end of file

Propchange: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/project-structure.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Added: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml?rev=711335&view=auto
==============================================================================
--- portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml
(added)
+++ portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml
Tue Nov  4 10:09:03 2008
@@ -0,0 +1,265 @@
+<?xml version="1.0"?>
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+  
+  http://www.apache.org/licenses/LICENSE-2.0
+  
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+
+  $Id$
+-->
+<document>
+  <properties>
+    <title>The need for a custom Maven build lifecycle</title>
+    <authors>
+      <person name="Ate Douma" email="ate@douma.nu" />
+    </authors>
+  </properties>
+  <body>
+    <section name="The need for a custom Maven build lifecycle">
+      <p>
+        A standard Maven 2.0 project provides 3 <em>fixed</em> build "lifecycles"
called clean, default and site.<br/>
+        See also:
+        <a href="http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html">Introduction
to the Build Lifecycle"</a>.
+      </p>
+      <p>
+        These standard build lifecycles all focus on, <em>and only on</em>, the
project artifact(s) themselves.
+        This means the build lifecycle and all the possible configurations thereof really
concerns the final artifact(s) itself,
+        <em>NOT</em> the (target) environment where it is intended to be used.
+      </p>
+      <p>
+        The final phase of the default lifecycle, <code>deploy</code>, concerns
the deployment of the project artifact(s) to a remote Maven repository.
+        The intended <em>usage</em> of a deployed artifact comes only after this
phase, and is in general out-of-scope from the POV of Maven itself,
+        except when such and artifact itself is used as dependency by another Maven project.
(actually the most common, "expected" use-case).
+      </p>
+      <p>
+        For the most common Maven artifact type, jars, this is perfectly fine, but for application
server integration frameworks like the Jetspeed-2 Portal, 
+        it is <em>NOT</em>.
+      </p>
+      <p>
+        In contrast to more generic low-level (development) frameworks like Springframework,
Jetspeed-2 comes with a very specific set of components usually
+        assembled and configured only on integration level. While Jetspeed-2 <em>itself</em>
is assembled and configured using Maven-2 and Springframework on
+        a very low-level detail, it should require only a few specific configurations (and
provide room for extensions) to adapt and integrate for a custom
+        project and its environment.
+      </p>
+      <p>
+        Furthermore, these custom project and enviroment specific changes and extensions
should be possible separated from and independently of the base
+        Jetspeed-2 Portal components (and their base configuration) to allow proper maintainenance
of the custom project lifecycle itself.
+      </p>
+      <p>For these requirements, the standard provided Maven build lifecycles and extension
points are (currently) falling a bit short.</p>
+      <subsection name="Options to customizing the Maven build lifecycle">
+        <p>There are many ways to customize the Maven build lifecycle:</p>
+        <ol>
+          <li>
+            <b>Using (only) profiles</b>
+            <br />
+            <p>
+              Profiles within a Maven project (pom) file allows to augment or replace default
lifecycle behavior, but <em>maintains</em>
+              the lifecycle phase handling. And because the default lifecycle already configures
standard behavior, trying to achieve something very different
+              from the standard behavior (like deploying and configuring a complete Portal
application for a specific application server) quickly becomes very
+              unwielding and difficult to setup and maintain (if at all).
+            </p>
+            <p>
+            </p>
+          </li>
+          <li>
+            <b>Using "standalone" plugins</b>
+            <br />
+            <p>
+              An alternative is writing and/or leveraging so called "standalone" Maven plugins
which run <em>outside</em>
+              a lifecycle. These plugins don't affect or are affected by the default lifecycle.
But... with the current Maven 2.0 model they can also only have
+              a single configuration within a project (pom) file, so many different tasks
(and possible different environments) are needed, their configuration
+              quickly becomes very large and complex and/or require splitting them up using
multiple profile definitions. But then, the complexity moves to
+              making sure the right profile combinations are executed which mean complex
and error prone (manual) build instructions.
+            </p>
+            <p>
+              Furthermore, as these plugins run outside any lifecycle, none of the standard
Maven plugins can be leveraged (nor directly "invoked" which isn't
+              supported by Maven). Often needed standard functionality like the default copying/filtering
of resource files will have to be provided by the
+              standalone plugin itself too!
+            </p>
+            <p>
+              Finally, while a standalone plugin can "fork" off a default lifecycle (phase),
this also means (potentially) <em>all</em>
+              the standard provided lifecycle behavior is executed too again, leading to
the same problems as with the previous option (see: above).
+            </p>
+          </li>
+          <li>
+            <b>Using separate dedicated sub projects</b>
+            <br />
+            <p>
+              This is the "standard" Maven-2 solution if multiple "artifacts" are needed
for a certain project: split the project up in separate sub projects
+              each providing its own "dedicated" result (note: with Maven-1 it was easy and
common practice to write custom jelly "goals" in maven.xml for this
+              purpose).
+            </p>
+            <p>While this is certainly a good solution, and allows one to leverage
the full Maven-2 feature set, it has a few caveats too.</p>
+            <p>
+              First of all, it can clutter the project structure quite a bit when many different
"tasks" are required. Additionally, as these "tasks" usually
+              are not meant to be run automatically during the normal build lifecycle, they
should not be configured as sub modules of a parent project but will
+              require manual navigation to and execution of by the developer. One could use
(again) multiple profiles (see above) to "merge" several of these
+              tasks in one common project (pom) file, but this still requires the developer
to know and specify each needed (combination of) profile(s) to
+              execute.
+            </p>
+            <p>
+              Additionally, while maybe "good" practice by itself, it also requires that
all artifacts and resources needed by such a dedicated "task" project
+              are build and usually installed in the local or a remote Maven repository.
This potentially adds additional complexity to a project configuration
+              when some resources already are available locally within the context of another
(sub) project.
+            </p>
+          </li>
+          <li>
+            <b>Using custom project (pom) files</b>
+            <br />
+            <p>Maven-2 allows execution of non-default (pom.xml) project files using
a command line option (-f &lt;project file&gt;).</p>
+            <p>
+              This solution elevates some of the caveats of the previous solution: there
is no need to expand the project with several sub projects and a custom
+              "task" project file can directly access the project local resources.
+            </p>
+            <p>On the other hand, this solution now requires using additional command
line parameters and thus again more effort from the developer.</p>
+          </li>
+          <li>
+            <b>Using a custom lifecycle extension</b>
+            <br />
+            <p>
+              Finally, it is possible to <em>replace</em> the default lifecycle
of a project (pom) file alltogether by using a custom &lt;packaging&gt; type.
+            </p>
+            <p>
+              Such a custom lifecycle definition must be provided through a custom plugin
extension and specifically configured within the project file. But the
+              custom lifecycle will have to provide the complete definition of all the intended
behavior, and if that includes "old" standard behavior (like
+              building and installing a war) this solution quickly falls back again to the
first option, albeit with more (but still fixed) flexibility and
+              choices for configuration.
+            </p>
+            <p>
+              Other caveats of this option are that probably multiple custom lifecycles are
going to be required (e.g. different ones for pom,war,jar,ear etc.),
+              and that (future) default IDE tooling support will be very unlikely.
+            </p>
+          </li>
+        </ol>
+        <p>
+          Of the above options, option 2. and 5. are most difficult to maintain and use.
Option 3. or 4., possibly combined with option 1. are more keeping in
+          line with the intended usage of Maven-2, but have as caveat that it requires more
complex manual (commandline) usage instructions.
+        </p>
+        <p>
+          What really is missing here is some kind of automation: some kind of scripting/configuration
of the different usages and required commandline
+          parameters as needed <em>for a specific custom project and its environment</em>
+          .
+        </p>
+        <p>
+          While writing custom shell scripts for just this purpose, or maybe even using a
<a href="http://ant.apache.org">Apache Ant</a>
+          script to automate the different Maven-2 commands, this will easily will lead to
every project having its own custom (and thus different) way of doing
+          things. And as it depends on yet another build tool incompatible environment problems
(e.g. bash scripts usually don't run on Windows) are evident
+          too.
+        </p>
+      </subsection>
+      <subsection name="The jetspeed:mvn Maven Plugin - Automating Maven tasks using Maven">
+        <p>
+          To "solve" the problem described above, Jetspeed-2 provides a specific Maven plugin,
jetspeed:mvn, which supports automating Maven-2 execution from
+          within Maven itself, using a configuration <em>within</em> a (parent)
project file very similar to Apache Ant target definitions.
+        </p>
+        <p>
+          The jetspeed:mvn plugin <em>is</em> a standalone plugin (see discussion
above), but requires only a very straightforward configuration and
+          only one additional runtime parameter to be specified on the commandline.
+        </p>
+        <p>
+          An example commandline usage and the configuration used within the Jetspeed-2 project
build itself to build, install, configure the database and
+          finally deploy a full Jetspeed Demo Portal is: <source>$mvn jetspeed:mvn
-Dtarget=demo</source>
+          <source><![CDATA[<plugin>
+  <groupId>org.apache.portals.jetspeed-2</groupId>
+  <artifactId>jetspeed-mvn-maven-plugin</artifactId>
+  <version>${org.apache.portals.jetspeed.version}</version>
+  <configuration>
+    <targets combine.children="append">
+      <target>
+        <id>testdb</id>
+        <name>db-init</name>
+        <properties>
+          <database.type>test</database.type>
+        </properties>
+      </target>
+      <target>
+        <id>proddb</id>
+        <name>db-init</name>
+        <properties>
+          <database.type>production</database.type>
+        </properties>
+      </target>
+      <target>
+        <id>demo-install</id>
+        <dir>@rootdir@/applications/jetspeed-demo</dir>
+      </target>
+      <target>
+        <id>demo-dbpsml-install</id>
+        <dir>@rootdir@/applications/jetspeed-demo</dir>
+        <profiles>dbpsml</profiles>
+      </target>
+      <target>
+        <id>demo-seed</id>
+        <name>demo</name>
+        <dir>@rootdir@/applications/jetspeed-demo</dir>
+        <profiles>seed</profiles>
+      </target>
+      <target>
+        <id>demo-seed-dbpsml</id>
+        <depends>demo-db</depends>
+        <name>demo</name>
+        <dir>@rootdir@/applications/jetspeed-demo</dir>
+        <profiles>seed-dbpsml</profiles>
+      </target>
+      <target>
+        <id>demo-deploy</id>
+        <name>demo</name>
+        <dir>@rootdir@/applications/jetspeed-demo</dir>
+        <profiles>deploy</profiles>
+      </target>
+      <target>
+        <id>demo-db</id>
+        <depends>proddb,demo-seed</depends>
+      </target>
+      <target>
+        <id>demo-db-psml</id>
+        <depends>demo-db,demo-seed-dbpsml</depends>
+      </target>
+      <target>
+        <id>demo</id>
+        <depends>demo-install,demo-db,demo-deploy</depends>
+      </target>
+      <target>
+        <id>demo-dbpsml</id>
+        <depends>demo-dbpsml-install,demo-db-psml,demo-deploy</depends>
+      </target>
+    </targets>
+  </configuration>
+</plugin>]]></source>
+        </p>
+        <p>
+          A target can optionally "depend" on other targets which then will be executed beforehand.
Additionally, specific properties, profiles and goals can be
+          defined to be passed on to the Maven execution environment as well as (the location
of) a custom project file to execute, and even a custom maven
+          settings file, allowing easy and <em>full</em> control of the target
Maven execution environment.
+        </p>
+        <p>
+          The jetspeed:mvn plugin is based upon and adapted from the standard <a href="http://maven.apache.org/plugins/maven-invoker-plugin/">Maven
Invoker Plugin</a>,
+          which is (only) targetted at running integration test projects as attached to the
integration-test lifecycle phase.
+        </p>
+        <p>
+          The jetspeed:mvn expands upon the Invoker Plugin by allowing to be invoked directly
from the commandline as well as providing a more generic and
+          configurable <em>chain</em> of execution targets, similar to Apache
Ant build scripts, but fully using and delegating to standard Maven-2 project
+          build lifecycle handling for the actually execution of the individual target tasks.
+        </p>
+        <p>
+          Other than allowing execution from the commandline and the enhanced configuration
options, the jetspeed:mvn doesn't really provide new behavior
+          compared to the standard Maven Invoker Plugin and uses the same Maven API and components
(the shared maven-invoker component).
+        </p>
+        <p>
+          A full description and configuration definition for the jetspeed:mvn plugin is
provided on the <a href="jetspeed-mvn-plugin.html">Using jetspeed:mvn</a>
+          page. And example usages are also available from the "Examples" menu item to the
left.
+        </p>
+      </subsection>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Propchange: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: portals/jetspeed-2/portal/trunk/src/site/xdoc/maven/the-need-for-a-custom-lifecycle.xml
------------------------------------------------------------------------------
    svn:keywords = Id



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


Mime
View raw message