You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by wo...@apache.org on 2008/11/04 19:09:04 UTC
svn commit: r711335 [2/2] - in /portals/jetspeed-2/portal/trunk: maven/src/
src/site/ src/site/xdoc/maven/
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 <packaging>pom</packaging>.
+ </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, <packaging>war</packaging>
+ 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
+ <packaging>war</packaging> 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 <project file>).</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 <packaging> 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