portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From a..@apache.org
Subject svn commit: r678019 [3/3] - in /portals/jetspeed-2/portal/trunk: ./ applications/jetspeed-demo/ maven/ maven/jetspeed-mvn-maven-plugin/ maven/jetspeed-mvn-maven-plugin/src/ maven/jetspeed-mvn-maven-plugin/src/main/ maven/jetspeed-mvn-maven-plugin/src/m...
Date Fri, 18 Jul 2008 19:57:50 GMT
Added: portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/jetspeed-unpack-plugin.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/jetspeed-unpack-plugin.xml?rev=678019&view=auto
==============================================================================
--- portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/jetspeed-unpack-plugin.xml (added)
+++ portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/jetspeed-unpack-plugin.xml Fri Jul 18 12:57:49 2008
@@ -0,0 +1,465 @@
+<?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>Configuration and usage of the jetspeed-unpack:unpack Maven Plugin</title>
+    <authors>
+      <person name="Ate Douma" email="ate@douma.nu" />
+    </authors>
+  </properties>
+  <body>
+    <section name="Configuration and usage of the jetspeed-unpack:unpack Maven Plugin">
+      <p>
+        The Jetspeed Unpack Maven Plugin provides one goal: <strong><code>jetspeed-unpack:unpack</code></strong>, which can be used to extract selected resources
+        from a (remote) Maven artifact or an local (archive) file.
+      </p>
+      <p>
+        At the time this plugin was written, none of the required features was fully available from other (standard) Maven plugins.
+      </p>
+      <p>
+        Now, some of these features are also possible using the standard Maven Dependency Plugin
+        <a href="http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html">dependency:unpack</a> goal or the Remote Resources Plugin
+        <a href="http://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html">remote-resources:process</a> goal.
+      </p>
+      <p>
+        However, this wasn't yet the case initially, and still the jetspeed-unpack plugin is easier to configure and use.<br/>
+        Furthermore, the same functionallity as provided by this plugin is also available embedded within the <a href="jetspeed-db-init-plugin.html">jetspeed-db:iniit</a> plugin using
+        exactly the same configuration.
+      </p>
+      <p>
+        This plugin is intended to be used as attached to the Maven <strong><code>process-resources</code></strong> or possibly <strong><code>generate-resources</code></strong>
+        lifecycle phase for embedding pre-defined resources in a final Maven artifact like a war file, or use such resources for integration tasks like deploying (possibly filtered)
+        configuration files to a target environment application server. 
+      </p>
+      <subsection name="Side track: the jetspeed-portal-resources artifact">
+        <p>
+          While this plugin is not dependent on the <strong><code>jetspeed-portal-resources</code></strong> artifact in anyway (nor on any other part of Jetspeed-2 for that matter),
+          it is primarily written and used for unpacking specific pre-packaged Jetspeed-2 Portal resources.  
+        </p>
+        <p>
+          The <a href="jetspeed-portal-resources.html">Jetspeed Portal Resources</a> page further describes the jetspeed-portal-resources artifact and its intended usage.
+        </p>
+      </subsection>
+    </section>
+    <section name="Quick Overview">
+      <p>
+        This is a listing of all the elements which can be configured for the jetspeed:unpack plugin:
+      </p>
+      <p>
+        <source><![CDATA[<plugin>
+  <groupId>org.apache.portals.jetspeed-2</groupId>
+  <artifactId>jetspeed-unpack-maven-plugin</artifactId>
+  <version>${org.apache.portals.jetspeed.version}</version>
+  <configuration>
+
+    <unpack>
+      <artifact>...</artifact>
+      <file>...</file>
+      <targetDirectory>...</targetDirectory>
+      <overwrite>...</overwrite>            
+      <resources combine.children="append">
+
+        <resource>
+          <path>...</path>
+          <destination>...</destination>
+          <overwrite>...</overwrite>
+          <flat>...</flat>
+          <include>...</include>
+          <exclude>...</exclude>
+        </resource>
+        ...
+      </resources>
+    </unpack>
+
+    <skip>...</skip>
+    <verbose>...</verbose>
+
+  </configuration>
+</plugin>]]></source>
+        </p>
+    </section>
+    <section name="Configuration">
+      <subsection name="Resource archive specification and references">
+        <h4>Using Maven artifacts as resource archive</h4>
+        <p>
+          As with the <a href="jetspeed-db-init-plugin.html">jetspeed-db:init</a> plugin and the <a href="jetspeed-deploy-plugin.html">jetspeed-deploy:deploy</a> plugin,
+          the jetspeed-unpack plugin can (and primarily is intended to) use Maven Artifacts retrieved from the local Maven repository as resource (archives).
+        </p>
+        <p>
+          To use Maven artifacts as resource archive they need to be specified as plugin dependencies:
+        <source><![CDATA[<plugin>
+  <groupId>org.apache.portals.jetspeed-2</groupId>
+  <artifactId>jetspeed-unpack-maven-plugin</artifactId>
+  <version>${org.apache.portals.jetspeed.version}</version>
+  ...
+  <dependencies>
+    <dependency>
+      <groupId>org.apache.portals.jetspeed-2</groupId>
+      <artifactId>jetspeed-portal-resources</artifactId>
+      <version>${org.apache.portals.jetspeed.version}</version>
+    </dependency>
+  </dependencies>
+</plugin>]]></source>
+          <em>
+            Note: Maven 2.0 (as of now, version 2.0.9) <strong>requires</strong> that for a plugin dependency its &lt;version/&gt; is defined, even if a default version is
+            configured in the project &lt;dependencyManagement/&gt; section for the same artifact.</em>
+        </p>
+        <p>
+          As standard Maven functionality, if such a dependency isn't available yet from the local Maven repository, it will automatically (try to) download it from a
+          remote Maven repository.
+        </p>
+        <h4>Referencing a plugin dependency as resource archive</h4>
+        <p>
+          To actually use a specific resource archive specified as a plugin dependency it can be referenced with:
+          <source><![CDATA[<artifact>${groupId}:${artifactId}:${packaging}</artifact>]]></source>
+          <em>Note: the default packaging of a dependency is <strong><code>jar</code></strong></em>
+        </p>
+        <p>
+          Using the <strong><code>jetspeed-portal-resources</code></strong> artifact as example, its artifact <em>reference</em> configuration would be:
+          <source><![CDATA[<artifact>org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar</artifact>]]></source>
+        </p>
+        <p>
+          Note: the same type of definition and usage of (remote) Maven repository artifacts is also used by the <a href="jetspeed-db-init-plugin.html">jetspeed-db:init</a> and
+          <a href="jetspeed-deploy-plugin.html">jetspeed-deploy:deploy</a> plugins.
+        </p>
+        <h4>Using a local file archive</h4>
+        <p>
+          Alternatively, it is also possible to directly use local archive files, in which case a <strong><code>file</code></strong>
+          element should be specified instead of an <strong><code>artifact</code></strong> element:
+          <source><![CDATA[<file>localArchiveFilePath</file>]]></source>
+        </p>
+      </subsection>
+      <subsection name="Plugin configuration">
+        <p>
+          The jetspeed-unpack plugin allows two general options to be configured besides specific <strong><code>unpack</code></strong> configurations:
+        </p>
+        <table>
+          <tr>
+            <th>Element</th>
+            <th width="90%">Description</th>
+          </tr>
+          <tr>
+            <td>skip</td>
+            <td>
+              <code>default: false</code><br/>
+              This optional element is primarly intended to allow skipping plugin execution under certain conditions, like <em>not</em> extracting resources
+              which are only needed when actually performing unit tests:
+        <source><![CDATA[<phase>process-test-resources</phase>
+  <configuration
+    <skip>${maven.test.skip}</skip>
+    ...
+  </configuration>]]></source>
+              Maven always invokes plugins attached to the <strong><code>process-test-resources</code></strong> phase, regardless if it actually is going to execute
+              unit tests.
+            </td>
+          </tr>
+          <tr>
+            <td>verbose</td>
+            <td>
+              <code>default: false</code><br/>
+              When unpacking resources, the <strong><code>verbose</code></strong> setting controls if detailed logging is performed which files are extracted.<br/>
+            </td>
+          </tr>
+        </table>
+      </subsection>
+      <subsection name="unpack configuration">
+        <p>
+          As already described above, the actual resource archive to unpack from has to be specified either as <strong><code>artifact</code></strong> reference or
+          local <strong><code>file</code></strong>.
+        </p>
+        <p>
+          <em>
+            But if only one plugin dependency is specified, no resource archive has to be specified, in which case the single plugin dependency will be
+            used as resource archive.
+          </em>
+        </p>
+        <p>
+          Additionally, two other optional unpack configuration elements can be speficied:
+        </p>
+        <table>
+          <tr>
+            <th>Element</th>
+            <th width="90%">Description</th>
+          </tr>
+          <tr>
+            <td>targetDirectory</td>
+            <td>
+              <code>default: ${project.build.directory}</code><br/>
+              The targetDirectory is used as <strong><em>base</em></strong> directory under which the selected resources from the resource archive will be extracted.<br/>
+              If this directory does not yet exist, it will be created by the plugin automatically before (possibly) extracting resources.  
+            </td>
+          </tr>
+          <tr>
+            <td>overwrite</td>
+            <td>
+              <code>default: true</code><br/>
+              When a selected resource from the resource archive already exists in its target directory, the overwrite setting will determine if the existing resource
+              is overwritten, even if it has a more recent timestamp than the archived resource.<br/>
+              Note: if the archived resource has a more recent timestamp the existing resource will <em>always</em> be overwritten.<br/>
+              This setting can also be overruled for specific <strong><code>resource</code></strong> configurations (see below).
+            </td>
+          </tr>
+        </table>
+      </subsection>
+      <subsection name="&lt;resources combine.children=&quot;append&quot;&gt;">
+        <p>
+          A potentially very important part of the configuration is the <strong><code>combine.children="append"</code></strong> attribute specified
+          for the <strong><code>resources</code></strong> element.
+        </p>
+        <p>
+          Maven 2 plugin configuration parsing (using Xpp3) by default <strong><em>merges</em></strong> configuration elements for children elements if not defined!
+          This default behavior allows to only define <strong>overriding</strong> properties for a certain configuration element.
+        </p>
+        <p>
+          But, for the resources configurations this is <strong><em>not</em></strong> very convenient because it requires to specify <strong><em>all</em></strong> optional properties for
+          a <strong><code>resource</code></strong> element to prevent "merging in" property values from <em>unrelated</em> previously defined resource elements.
+        </p>
+        <p>
+          To solve this inconvenience, a <strong><code>combine.children="append"</code></strong> attribute can be specified on a parent element to use <strong><em>append</em></strong>
+          instead of <strong><em>merge</em></strong> when parsing the child elements.
+        </p>
+        <p>
+          For the jetspeed-unpack plugin defining this attribute is recommended <em><strong>unless</strong></em> only one, or exactly similar resource child elements are configured 
+          (e.g. using all the same set of elements).
+        </p>
+      </subsection>
+      <subsection name="resource configuration">
+        <p>
+          The final part of the jetspeed-unpack plugin configuration concern the actual resoure(s) to unpack:
+        <source><![CDATA[<resource>
+  <path>/conf/tomcat</path>
+  <destination>tomcat</destination>
+  <include>context.xml</include>
+</resource>]]></source>
+          The above example will extract the context.xml resource from the conf/tomcat folder within the resource archive and write it to a sub directory tomcat of the project
+          build directory or otherwise specified (base) targetDirectory.
+        </p>
+        <p>
+          Note: it is not required to specify any resource configuration. If none is specified <em>all</em> resources from the resource archive will be extracted!  
+        </p>
+        <p>
+          The following (all optional) elements can be defined for a specific <strong><code>resource</code></strong> configuration:
+        </p>
+        <table>
+          <tr>
+            <th>Element</th>
+            <th width="90%">Description</th>
+          </tr>
+          <tr>
+            <td>path</td>
+            <td>
+              <code>default: /</code><br/>
+              The path specifies the sub folder within the resource archive as (base) path to search resources to extract.
+            </td>
+          </tr>
+          <tr>
+            <td>destination</td>
+            <td>
+              <code>default: ${configuration.targetDirectory}</code><br/>
+              If defined, the destination specifies the sub directory of the default project build directory or the otherwise specified <strong><code>targetDirectory</code></strong>
+              of the plugin where the matched resource(s) will be unpacked. 
+            </td>
+          </tr>
+          <tr>
+            <td>overwrite</td>
+            <td>
+              <code>default: ${unpack.overwrite}</code>
+              If defined, overwrite overrules the default overwrite setting of the unpack element (see above).              
+            </td>
+          </tr>
+          <tr>
+            <td>flat</td>
+            <td>
+              <code>default: false</code><br/>
+              By default resources to be extracted from the resource archive are written out to a sub directory of the target destination directory (see above) using their
+              relative position of the (base) path within the resource archive where they have been looked up against.<br/>
+              For example, with the following (probably incorrect) resource configuration:
+        <source><![CDATA[<resource>
+  <path>conf</path>
+  <destination>tomcat</destination>
+  <include>tomcat/context.xml</include>
+</resource>]]></source>
+              the matched context.xml resource will be written out to: ${targetDirectory}/tomcat/tomcat/context.xml<br/><br/>
+              For this kind of configurations (and sometimes these are needed), defining &lt;flat&gt;true&lt;flat&gt; will "drop" the relative position of the resource.<br/>
+              Then, only its entry name will be used, resulting in (the probably desired): ${targetDirectory}/tomcat/context.xml<br/><br/>
+              Of course the same result can also (and even simpler) be achieved using:
+        <source><![CDATA[<resource>
+  <path>conf</path>
+  <include>tomcat/context.xml</include>
+</resource>]]></source>
+            </td>
+          </tr>
+          <tr>
+            <td>include</td>
+            <td>
+              <code>default: ${resource.path}/**</code><br/>
+              The include element can define a comma separated list of resources to extract.<br/>
+              These may contain (standard Ant like) wildcards and sub folder references relative to the (base) path sub folder within the resource archive:
+        <source><![CDATA[<include>profile.xml,security*.xml,boot/*.xml</include>]]></source>
+            </td>
+          </tr>
+          <tr>
+            <td>exclude</td>
+            <td>
+              <code>default: <em>none</em></code><br/>
+              Potentially mached resources to extract (see include above) may be excluded from extraction using the exclude element.<br/>
+              Like with the include element, the exclude element can define a comma separated list of resources to <em>exclude</em>. 
+              These also may contain (standard Ant like) wildcards and sub folder references relative to the (base) path sub folder within the resource archive:
+        <source><![CDATA[<exclude>security-spi*.xml,security-managers.xml</exclude>]]></source>
+            </td>
+          </tr>
+        </table>
+        <p>
+          As can be determined from the above, as all resource configuration elements are optional, specifying an empty &lt;resource/&gt; definition will simply
+          extract all the resources from the archive to the targetDirectory. 
+        </p>
+      </subsection>
+    </section>
+    <section name="Examples">
+      <subsection name="Unpacking of jetspeed unit test resources"> 
+      <p>
+        The following example taken from the Maven project file for the jetspeed-profiler component extracts several Spring assembly files, all files from the db-ojb folder
+        and the seed/min/j2-seed.xml file to the project testOutputDirectory as needed for running the unit tests: 
+        <source><![CDATA[<plugin>
+  <groupId>${pom.groupId}</groupId>
+  <artifactId>jetspeed-unpack-maven-plugin</artifactId>
+  <version>${pom.version}</version>
+  <executions>
+    <execution>
+      <id>unpack-test-resources</id>
+      <goals>
+        <goal>unpack</goal>
+      </goals>
+      <phase>process-test-resources</phase>
+      <configuration>
+        <skip>${maven.test.skip}</skip>
+        <unpack>
+          <targetDirectory>${project.build.testOutputDirectory}</targetDirectory>
+          <resources>
+            <resource>
+              <path>assembly</path>
+              <include>profiler.xml,transaction.xml,prefs.xml,cache.xml,security-*.xml,boot/datasource.xml</include>
+            </resource>
+            <resource>
+              <path>db-ojb</path>
+            </resource>
+            <resource>
+              <path>seed/min</path>
+              <include>j2-seed.xml</include>
+            </resource>
+          </resources>
+        </unpack>
+      </configuration>
+    </execution>
+  </executions>
+</plugin]]></source>
+        The interesting part of this example is that <em><strong>NO</strong></em> resource archive is specified!
+      </p>
+      <p>
+        But the above example actually does work because the root Maven project file for the Jetspeed-2 Portal project already defined the jetspeed-portal-resources artifact
+        as default dependency for the jetspeed-unpack plugin in its dependencyManagement section:  
+        <source><![CDATA[<plugin>
+  <groupId>org.apache.portals.jetspeed-2</groupId>
+  <artifactId>jetspeed-unpack-maven-plugin</artifactId>
+  <version>${pom.version}</version>
+  <dependencies>
+    <dependency>
+      <groupId>${groupId}</groupId>
+      <artifactId>jetspeed-portal-resources</artifactId>
+      <version>${pom.version}</version>
+    </dependency>
+  </dependencies>
+</plugin>]]></source>
+        But please note: this is a special use-case which only works when only one dependency is (pre)configured. 
+      </p>
+      </subsection>
+      <subsection name="Unpacking the tomcat context.xml to be filtered before deployment">
+        <p>
+          A more elaborate and common use-case is extracting a specific resource during the generate-resources lifecycle phase so that it can be filtered
+          (using the standard Maven resources plugin):
+        <source><![CDATA[<plugins>
+  <plugin>
+    <groupId>org.apache.portals.jetspeed-2</groupId>
+    <artifactId>jetspeed-unpack-maven-plugin</artifactId>
+    <version>${org.apache.portals.jetspeed.version}</version>
+    <executions>
+      <execution>
+        <id>unpack-appserver</id>
+        <goals>
+          <goal>unpack</goal>
+        </goals>
+        <phase>generate-resources</phase>
+        <configuration>
+          <unpack>
+            <artifact>org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar</artifact>
+            <resources>
+              <resource>
+                <path>conf</path>
+                <include>tomcat/context.xml</include>
+              </resource>
+            </resources>
+          </unpack>
+        </configuration>
+      </execution>
+    </executions>
+  <dependencies>
+    <dependency>
+      <groupId>org.apache.portals.jetspeed-2</groupId>
+      <artifactId>jetspeed-portal-resources</artifactId>
+      <version>${org.apache.portals.jetspeed.version}</version>
+    </dependency>
+  </dependencies>
+  </plugin>
+  <plugin>
+    <groupId>org.apache.maven.plugins</groupId>
+    <artifactId>maven-resources-plugin</artifactId>
+    <executions>
+      <execution>
+        <id>resources</id>
+        <goals>
+          <goal>resources</goal>
+        </goals>
+        <phase>process-resources</phase>
+      </execution>
+    </executions>
+  </plugin>
+</plugins>
+...
+<resources>
+  <resource>
+    <directory>${project.build.directory}/tomcat</directory>
+    <targetPath>../resources</targetPath>
+    <filtering>true</filtering>
+  </resource>
+</resources>]]></source>
+          This example is taken from a custom Maven project file invoked with the <a href="jetspeed-mvn-plugin.html">jetspeed-mvn</a> plugin for deploying a custom Jetspeed-2 Portal
+          on a Tomcat server.
+        </p>
+        <p>
+          The standard Maven Resources Plugin is also configured in this example because a custom jetspeed-mvn Maven project file is commonly configured using
+          &lt;packaging&gt;pom&lt;/packaging&gt;.<br/>
+          Such custom jetspeed-mvn project files are used for executing specific integration tasks, not for producing a "normal" artifact like a jar or war file.<br/>
+          But as a pom project doesn't have the maven-resources-plugin attached to its lifecycle it needs to be configured directly to have it perform the needed
+          resource filtering during the process-resources phase. 
+        </p>
+      </subsection>
+    </section>
+  </body>
+</document>
\ No newline at end of file

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

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

Added: portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/project-structure.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/project-structure.xml?rev=678019&view=auto
==============================================================================
--- portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/project-structure.xml (added)
+++ portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/project-structure.xml Fri Jul 18 12:57:49 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/maven/src/site/xdoc/project-structure.xml
------------------------------------------------------------------------------
    svn:eol-style = native

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

Added: portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/the-need-for-a-custom-lifecycle.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/the-need-for-a-custom-lifecycle.xml?rev=678019&view=auto
==============================================================================
--- portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/the-need-for-a-custom-lifecycle.xml (added)
+++ portals/jetspeed-2/portal/trunk/maven/src/site/xdoc/the-need-for-a-custom-lifecycle.xml Fri Jul 18 12:57:49 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/maven/src/site/xdoc/the-need-for-a-custom-lifecycle.xml
------------------------------------------------------------------------------
    svn:eol-style = native

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

Modified: portals/jetspeed-2/portal/trunk/pom.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/pom.xml?rev=678019&r1=678018&r2=678019&view=diff
==============================================================================
--- portals/jetspeed-2/portal/trunk/pom.xml (original)
+++ portals/jetspeed-2/portal/trunk/pom.xml Fri Jul 18 12:57:49 2008
@@ -1290,6 +1290,82 @@
             </dependency>
           </dependencies>
         </plugin>
+
+        <plugin>
+          <groupId>org.apache.portals.jetspeed-2</groupId>
+          <artifactId>jetspeed-mvn-maven-plugin</artifactId>
+          <version>${pom.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>test-install</id>
+                <depends>testdb</depends>
+                <dir>@rootdir@</dir>
+                <goals>install</goals>
+                <profiles>test</profiles>
+              </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>
+        
       </plugins>
     </pluginManagement>
 
@@ -1368,126 +1444,6 @@
         <module>applications</module>
       </modules>
     </profile>
-    <profile>
-      <id>prod-db</id>
-      <build>
-        <plugins>
-          <plugin>
-            <groupId>${pom.groupId}</groupId>
-            <artifactId>jetspeed-db-maven-plugin</artifactId>
-            <version>${pom.version}</version>
-            <goals>
-              <goal>init</goal>
-            </goals>
-            <configuration>
-              <connection>
-                <username>${org.apache.jetspeed.production.database.user}</username>
-                <password>${org.apache.jetspeed.production.database.password}</password>
-                <url>${org.apache.jetspeed.production.database.url}</url>
-                <driver>${org.apache.jetspeed.production.database.driver}</driver>
-              </connection>
-              <unpack>
-                <artifact>${groupId}:jetspeed-portal-resources:jar</artifact>
-                <resources>
-                  <resource>
-                    <destination>ddl/production</destination>
-                    <path>ddl</path>
-                    <include>${org.apache.jetspeed.production.database.default.name}/</include>
-                  </resource>
-                </resources>
-              </unpack>
-              <sql>
-                <scripts>
-                  <script>
-                    <path>
-                      ${project.build.directory}/ddl/production/${org.apache.jetspeed.production.database.default.name}/drop-schema.sql
-                    </path>
-                    <ignoreErrors>true</ignoreErrors>
-                  </script>
-                  <script>
-                    <path>
-                      ${project.build.directory}/ddl/production/${org.apache.jetspeed.production.database.default.name}/create-schema.sql
-                    </path>
-                  </script>
-                </scripts>
-              </sql>
-            </configuration>
-            <dependencies>
-              <dependency>
-                <groupId>${groupId}</groupId>
-                <artifactId>jetspeed-portal-resources</artifactId>
-                <version>${pom.version}</version>
-              </dependency>
-              <dependency>
-                <groupId>${org.apache.jetspeed.production.jdbc.driver.groupId}</groupId>
-                <artifactId>${org.apache.jetspeed.production.jdbc.driver.artifactId}</artifactId>
-                <version>${org.apache.jetspeed.production.jdbc.driver.version}</version>
-              </dependency>
-            </dependencies>
-          </plugin>
-        </plugins>
-      </build>
-    </profile>
-    <profile>
-      <id>test-db</id>
-      <build>
-        <plugins>
-          <plugin>
-            <groupId>${pom.groupId}</groupId>
-            <artifactId>jetspeed-db-maven-plugin</artifactId>
-            <version>${pom.version}</version>
-            <goals>
-              <goal>init</goal>
-            </goals>
-            <configuration>
-              <connection>
-                <username>${org.apache.jetspeed.test.database.user}</username>
-                <password>${org.apache.jetspeed.test.database.password}</password>
-                <url>${org.apache.jetspeed.test.database.url}</url>
-                <driver>${org.apache.jetspeed.test.database.driver}</driver>
-              </connection>
-              <unpack>
-                <artifact>${groupId}:jetspeed-portal-resources:jar</artifact>
-                <resources>
-                  <resource>
-                    <destination>ddl/test</destination>
-                    <path>ddl</path>
-                    <include>${org.apache.jetspeed.test.database.default.name}/</include>
-                  </resource>
-                </resources>
-              </unpack>
-              <sql>
-                <scripts>
-                  <script>
-                    <path>
-                      ${project.build.directory}/ddl/test/${org.apache.jetspeed.test.database.default.name}/drop-schema.sql
-                    </path>
-                    <ignoreErrors>true</ignoreErrors>
-                  </script>
-                  <script>
-                    <path>
-                      ${project.build.directory}/ddl/test/${org.apache.jetspeed.test.database.default.name}/create-schema.sql
-                    </path>
-                  </script>
-                </scripts>
-              </sql>
-            </configuration>
-            <dependencies>
-              <dependency>
-                <groupId>${groupId}</groupId>
-                <artifactId>jetspeed-portal-resources</artifactId>
-                <version>${pom.version}</version>
-              </dependency>
-              <dependency>
-                <groupId>${org.apache.jetspeed.test.jdbc.driver.groupId}</groupId>
-                <artifactId>${org.apache.jetspeed.test.jdbc.driver.artifactId}</artifactId>
-                <version>${org.apache.jetspeed.test.jdbc.driver.version}</version>
-              </dependency>
-            </dependencies>
-          </plugin>
-        </plugins>
-      </build>
-    </profile>
   </profiles>
 
 </project>

Modified: portals/jetspeed-2/portal/trunk/quickStart.sh
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/trunk/quickStart.sh?rev=678019&r1=678018&r2=678019&view=diff
==============================================================================
--- portals/jetspeed-2/portal/trunk/quickStart.sh (original)
+++ portals/jetspeed-2/portal/trunk/quickStart.sh Fri Jul 18 12:57:49 2008
@@ -1,4 +1 @@
-cd applications/jetspeed-demo
-mvn -o jetspeed-db:init -P demo 
-mvn -o jetspeed-deploy:deploy -P demo
-cd ../..
+mvn -o jetspeed:mvn -Dtarget=demo



---------------------------------------------------------------------
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