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

View: New views

1 Messages — Rating Filter: Alert me

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

by Ate Douma-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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"?>
+
+<document>
+ <properties>
+ <title>Configuration and usage of the jetspeed-unpack:unpack Maven Plugin</title>
+ <authors>
+ <person name="Ate Douma" email="ate@..." />
+ </authors>
+ </properties>
+ <body>
+ <section name="Configuration and usage of the jetspeed-unpack:unpack Maven Plugin">
+ 
+ The Jetspeed Unpack Maven Plugin provides one goal: <code>jetspeed-unpack:unpack</code>, which can be used to extract selected resources
+ from a (remote) Maven artifact or an local (archive) file.
+ 
+ 
+ At the time this plugin was written, none of the required features was fully available from other (standard) Maven plugins.
+ 
+ 
+ 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.
+ 
+ 
+ However, this wasn't yet the case initially, and still the jetspeed-unpack plugin is easier to configure and use. 
+ 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.
+ 
+ 
+ This plugin is intended to be used as attached to the Maven <code>process-resources</code> or possibly <code>generate-resources</code>
+ 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.
+ 
+ <subsection name="Side track: the jetspeed-portal-resources artifact">
+ 
+ While this plugin is not dependent on the <code>jetspeed-portal-resources</code> 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.
+ 
+ 
+ The <a href="jetspeed-portal-resources.html">Jetspeed Portal Resources</a> page further describes the jetspeed-portal-resources artifact and its intended usage.
+ 
+ </subsection>
+ </section>
+ <section name="Quick Overview">
+ 
+ This is a listing of all the elements which can be configured for the jetspeed:unpack plugin:
+ 
+ 
+ <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>
+ 
+ </section>
+ <section name="Configuration">
+ <subsection name="Resource archive specification and references">
+ <h4>Using Maven artifacts as resource archive</h4>
+ 
+ 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).
+ 
+ 
+ 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>
+ 
+ Note: Maven 2.0 (as of now, version 2.0.9) requires that for a plugin dependency its <version/> is defined, even if a default version is
+ configured in the project <dependencyManagement/> section for the same artifact.
+ 
+ 
+ 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.
+ 
+ <h4>Referencing a plugin dependency as resource archive</h4>
+ 
+ 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>
+ Note: the default packaging of a dependency is <code>jar</code>
+ 
+ 
+ Using the <code>jetspeed-portal-resources</code> artifact as example, its artifact reference configuration would be:
+ <source><![CDATA[<artifact>org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar</artifact>]]></source>
+ 
+ 
+ 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.
+ 
+ <h4>Using a local file archive</h4>
+ 
+ Alternatively, it is also possible to directly use local archive files, in which case a <code>file</code>
+ element should be specified instead of an <code>artifact</code> element:
+ <source><![CDATA[<file>localArchiveFilePath</file>]]></source>
+ 
+ </subsection>
+ <subsection name="Plugin configuration">
+ 
+ The jetspeed-unpack plugin allows two general options to be configured besides specific <code>unpack</code> configurations:
+ 
+ <table>
+ <tr>
+ <th>Element</th>
+ <th width="90%">Description</th>
+ </tr>
+ <tr>
+ <td>skip</td>
+ <td>
+ <code>default: false</code> 
+ This optional element is primarly intended to allow skipping plugin execution under certain conditions, like not 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 <code>process-test-resources</code> phase, regardless if it actually is going to execute
+ unit tests.
+ </td>
+ </tr>
+ <tr>
+ <td>verbose</td>
+ <td>
+ <code>default: false</code> 
+ When unpacking resources, the <code>verbose</code> setting controls if detailed logging is performed which files are extracted. 
+ </td>
+ </tr>
+ </table>
+ </subsection>
+ <subsection name="unpack configuration">
+ 
+ As already described above, the actual resource archive to unpack from has to be specified either as <code>artifact</code> reference or
+ local <code>file</code>.
+ 
+ 
+ 
+ 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.
+ 
+ 
+ 
+ Additionally, two other optional unpack configuration elements can be speficied:
+ 
+ <table>
+ <tr>
+ <th>Element</th>
+ <th width="90%">Description</th>
+ </tr>
+ <tr>
+ <td>targetDirectory</td>
+ <td>
+ <code>default: ${project.build.directory}</code> 
+ The targetDirectory is used as base directory under which the selected resources from the resource archive will be extracted. 
+ 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> 
+ 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. 
+ Note: if the archived resource has a more recent timestamp the existing resource will always be overwritten. 
+ This setting can also be overruled for specific <code>resource</code> configurations (see below).
+ </td>
+ </tr>
+ </table>
+ </subsection>
+ <subsection name="<resources combine.children="append">">
+ 
+ A potentially very important part of the configuration is the <code>combine.children="append"</code> attribute specified
+ for the <code>resources</code> element.
+ 
+ 
+ Maven 2 plugin configuration parsing (using Xpp3) by default merges configuration elements for children elements if not defined!
+ This default behavior allows to only define overriding properties for a certain configuration element.
+ 
+ 
+ But, for the resources configurations this is not very convenient because it requires to specify all optional properties for
+ a <code>resource</code> element to prevent "merging in" property values from unrelated previously defined resource elements.
+ 
+ 
+ To solve this inconvenience, a <code>combine.children="append"</code> attribute can be specified on a parent element to use append
+ instead of merge when parsing the child elements.
+ 
+ 
+ For the jetspeed-unpack plugin defining this attribute is recommended unless only one, or exactly similar resource child elements are configured
+ (e.g. using all the same set of elements).
+ 
+ </subsection>
+ <subsection name="resource configuration">
+ 
+ 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.
+ 
+ 
+ Note: it is not required to specify any resource configuration. If none is specified all resources from the resource archive will be extracted!
+ 
+ 
+ The following (all optional) elements can be defined for a specific <code>resource</code> configuration:
+ 
+ <table>
+ <tr>
+ <th>Element</th>
+ <th width="90%">Description</th>
+ </tr>
+ <tr>
+ <td>path</td>
+ <td>
+ <code>default: /</code> 
+ 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> 
+ If defined, the destination specifies the sub directory of the default project build directory or the otherwise specified <code>targetDirectory</code>
+ 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> 
+ 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. 
+ 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 
+ For this kind of configurations (and sometimes these are needed), defining <flat>true<flat> will "drop" the relative position of the resource. 
+ Then, only its entry name will be used, resulting in (the probably desired): ${targetDirectory}/tomcat/context.xml 
+ 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> 
+ The include element can define a comma separated list of resources to extract. 
+ 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: none</code> 
+ Potentially mached resources to extract (see include above) may be excluded from extraction using the exclude element. 
+ Like with the include element, the exclude element can define a comma separated list of resources to exclude.
+ 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>
+ 
+ As can be determined from the above, as all resource configuration elements are optional, specifying an empty <resource/> definition will simply
+ extract all the resources from the archive to the targetDirectory.
+ 
+ </subsection>
+ </section>
+ <section name="Examples">
+ <subsection name="Unpacking of jetspeed unit test resources">
+ 
+ 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 NO resource archive is specified!
+ 
+ 
+ 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.
+ 
+ </subsection>
+ <subsection name="Unpacking the tomcat context.xml to be filtered before deployment">
+ 
+ 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.
+ 
+ 
+ The standard Maven Resources Plugin is also configured in this example because a custom jetspeed-mvn Maven project file is commonly configured using
+ <packaging>pom</packaging>. 
+ 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. 
+ 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.
+ 
+ </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"?>
+
+<document>
+ <properties>
+ <title>Standard structure of Jetspeed Portal Maven projects</title>
+ <authors>
+ <person name="Ate Douma" email="ate@..." />
+ </authors>
+ </properties>
+ <body>
+ <section name="Standard structure of Jetspeed Portal Maven projects">
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ <subsection name="The super project">
+ 
+ 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>.
+ 
+ 
+ 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>).
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ </subsection>
+ <subsection name="The portal sub project">
+ 
+ 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
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ 
+ 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 only contains the default (demo) Jetspeed Portal web application resources.
+ 
+ 
+ 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.
+ 
+ </subsection>
+ <subsection name="Portlet Application sub project(s)">
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ </subsection>
+ </section>
+ <section name="Conceptable project directory layout and contents">
+ 
+ Using the above specification a conceptable custom Jetspeed Portal directory layout and its contents looks like this:
+ 
+ <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">
+ 
+ In practice not all of the above possible directories and files will be needed.
+ 
+ 
+ A typical custom Jetspeed Portal project is much simpler and by default will looks like this:
+ 
+ <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>
+ 
+ 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.
+ 
+ </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"?>
+
+<document>
+ <properties>
+ <title>The need for a custom Maven build lifecycle</title>
+ <authors>
+ <person name="Ate Douma" email="ate@..." />
+ </authors>
+ </properties>
+ <body>
+ <section name="The need for a custom Maven build lifecycle">
+ 
+ A standard Maven 2.0 project provides 3 fixed build "lifecycles" called clean, default and site. 
+ See also:
+ <a href="http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html">Introduction to the Build Lifecycle"</a>.
+ 
+ 
+ These standard build lifecycles all focus on, and only on, the project artifact(s) themselves.
+ This means the build lifecycle and all the possible configurations thereof really concerns the final artifact(s) itself,
+ NOT the (target) environment where it is intended to be used.
+ 
+ 
+ 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 usage 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).
+ 
+ 
+ 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 NOT.
+ 
+ 
+ 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 itself 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.
+ 
+ 
+ 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.
+ 
+ For these requirements, the standard provided Maven build lifecycles and extension points are (currently) falling a bit short.
+ <subsection name="Options to customizing the Maven build lifecycle">
+ There are many ways to customize the Maven build lifecycle:
+ <ol>
+ <li>
+ Using (only) profiles
+ 
+ 
+ Profiles within a Maven project (pom) file allows to augment or replace default lifecycle behavior, but maintains
+ 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).
+ 
+ 
+ 
+ </li>
+ <li>
+ Using "standalone" plugins
+ 
+ 
+ An alternative is writing and/or leveraging so called "standalone" Maven plugins which run outside
+ 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.
+ 
+ 
+ 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!
+ 
+ 
+ Finally, while a standalone plugin can "fork" off a default lifecycle (phase), this also means (potentially) all
+ the standard provided lifecycle behavior is executed too again, leading to the same problems as with the previous option (see: above).
+ 
+ </li>
+ <li>
+ Using separate dedicated sub projects
+ 
+ 
+ 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).
+ 
+ While this is certainly a good solution, and allows one to leverage the full Maven-2 feature set, it has a few caveats too.
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ </li>
+ <li>
+ Using custom project (pom) files
+ 
+ Maven-2 allows execution of non-default (pom.xml) project files using a command line option (-f <project file>).
+ 
+ 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.
+ 
+ On the other hand, this solution now requires using additional command line parameters and thus again more effort from the developer.
+ </li>
+ <li>
+ Using a custom lifecycle extension
+ 
+ 
+ Finally, it is possible to replace the default lifecycle of a project (pom) file alltogether by using a custom <packaging> type.
+ 
+ 
+ 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.
+ 
+ 
+ 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.
+ 
+ </li>
+ </ol>
+ 
+ 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.
+ 
+ 
+ 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 for a specific custom project and its environment
+ .
+ 
+ 
+ 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.
+ 
+ </subsection>
+ <subsection name="The jetspeed:mvn Maven Plugin - Automating Maven tasks using Maven">
+ 
+ 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 within a (parent) project file very similar to Apache Ant target definitions.
+ 
+ 
+ The jetspeed:mvn plugin is 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.
+ 
+ 
+ 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>
+ 
+ 
+ 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 full control of the target Maven execution environment.
+ 
+ 
+ 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.
+ 
+ 
+ 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 chain 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.
+ 
+ 
+ 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).
+ 
+ 
+ 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.
+ 
+ </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@...
For additional commands, e-mail: jetspeed-dev-help@...