Page History

...

Code Block

title	pom.xml

<?xml version="1.0" encoding="UTF-8"?>

<!--
Maven 2 is shortly identified as maven. If we want to give a reference to Maven 1.0.2 we will call Maven 1.
This POM extends SuperPOM, which means that the following elements are already defined:
maven central repository (http://repo1.maven.org/maven2)
maven plugin repository  (http://repo1.maven.org/maven2)

default build directories:

  target
  target/classes
  target/test-classes
  target/site
  src/main/java
  src/test/java
  src/main/scripts
  src/main/resources
  src/test/resources


as well as default profiles: release-profile

and default plugins:
	maven-source-plugin
	maven-javadoc-plugin
	maven-deploy-plugin

-->


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  	<modelVersion>4.0.0</modelVersion>
	<artifactId>org-glast-groupmanager</artifactId>
	<groupId>glast</groupId>
	<version>1.6-SNAPSHOT</version>
	<description>Glast Group Manager</description>
	<url>http://glast-ground.slac.stanford.edu/GroupManager/</url>
	<name>Glast Group Manager</name>
	<inceptionYear>2005</inceptionYear>
 	<repositories>
		<!-- Not yet defined -->
	</repositories>
  	<scm>
		<developerConnection>
			scm:cvs:ext:${maven.username}@glast   java.slac.stanford.edu:/cvs/java:${pom.artifactId}  <!-- to be verified -->
                </developerConnection>
         </scm>
         <dependencies>
		<!-- dependencies here -->
		<dependency>
      			<groupId>tomcat</groupId>
      			<artifactId>servlet-api</artifactId>
      			<version>5.0.18</version>
    		</dependency>
		<!-- ... -->
		<!-- Needed by cruisecontrol -->
		<dependency>
      			<groupId>maven</groupId>
      			<artifactId>maven-scm-plugin</artifactId>
      			<version>1.5</version>
      			<type>plugin</type>
   		 </dependency>
	</dependencies>
	<build>
   		 <resources>
     			 <resource>
			<directory>src/main/resource</directory> <!-- should have been resources -->
			<includes>
	  			<include>META-INF/*.tld</include>
			</includes>
      		</resource>
    </resources>
  </build>
</project>

...

As such, profiles can easily lead to differing build results from different members of your team. However, used properly, you can still preserve build portability with profiles. You can define profiles in one of the following three places:?

The Maven 2 settings file (typically <your -home-directory>/.m2/settings.xml)

...

A file in the the same directory as the POM, called profiles.xml

...

The POM itself

In terms of which profile takes precedence, the local-most profile wins. So, POM-specified profiles override those in profiles.xml, and profiles.xml overrides those in settings.xml. This is a pattern that is repeated throughout Maven 2, that local always wins, because it is assumed to be a modification of a more general case. settings.xml profiles have the potential to affect all builds, so they're sort of a "global" location for profiles. profiles.xml allows you to augment a single project's build without altering the POM.
And the POM-based profiles are preferred, since these profiles are portable (they will be distributed to the repository on deploy, and are available for subsequent builds originating from the repository or as transitive dependencies).

Because of the portability implications, any files which are not distributed to the repository are NOT allowed to change the fundamental build in any way. Therefore, the profiles specified in profiles.xml and settings.xml are only allowed to define:?

repositories

...

pluginRepositories

...

properties

Everything else must be specified in a POM profile, or in the POM itself, or not at all. For example, if you had a profile in settings.xml that was able to inject a new dependency, and the project you were working on actually did depend on that settings-injected dependency in order to run, then once that project is deployed to the repository it will never fully resolve its dependencies transitively when asked to do so. That's because it left one of its dependencies sitting in a profile inside your settings.xml file.

...

You can define the following elements in the POM profile:?

repositories

...

pluginRepositories

...

dependencies

...

plugins

...

properties (not actually available in the main POM, but used behind the scenes)

...

modules

...

reporting

...

dependencyManagement

...

distributionManagement

A subset of the build element, which consists of:?

defaultGoal

...

resources

...

testResources

...

finalName

(d) Activating profiles

Since you build profiles for specific tasks (like debug build or test build), you need to have mechanism to identify and activate the profiles in different situations.

...

Code Block

title	GLAST parent POM

<project xmlns="http://maven.apache.org/POM/4.0.0"   
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>glast</groupId>
  <artifactId>maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>
  <organization>
    <name>Glast</name>
    <url>http://glast-ground.slac.stanford.edu</url>
  </organization>
  <repositories>
    <repository>
<id>glast.      <id>glast-maven</id>
      <name>GLAST Maven 2 Repository</name>
      <url>

        http://glast-ground.slac.stanford.edu/maven2/
      </url>
      	<releases>
        <enabled>false</enabled>
<      </releases>
    </repository>
    <repository>
<id>glast.maven.      <id>glast-maven-snapshots</id>
      <name>GLAST Snapshot Repository</name>
      <url>
        http://glast-ground.slac.stanford.edu/maven2/SNAPSHOTS </url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<distributionManagement>

      </url>
   <!-- use the following<releases>
 if you're not using a snapshot version. --> <enabled>false</enabled>
        <repository>
            <id>glast-maven2</id></releases>
    </repository>
  </repositories>
</project>

The Maven GLAST POM declares the elements that are common to all of its sub-projects.

The GLAST snapshot repository and the release repository deployment locations should be defined in children of the parent POM.
It is the best practice to follow open source releases which separate SNAPSHOTS and PLUGINS directory from the release directory.

In children, you should point to the following GLAST distribution repositories:

Code Block

title	GLAST repositories


        <name>GLAST Maven 2 central repository</name>
            <url>scp://glast-java.slac.stanford.edu:/nfs/slac/g/glast/ground/maven2/</url>
        </repository>
        <!-- use the following in  if you're AREnot using a snapshot version. xxxx-->
  <repository>
      <snapshotRepository>
            <id>glast-maven2-snapshots<<id>glast-maven2</id>
            <name>GLAST Maven2Maven centreal2 SNAPSHOTScentral repository</name>
            <url>scp://glast-java.slac.stanford.edu:/nfs/slac/g/glast/ground/maven2/SNAPSHOTS<</url>
          </repository>
  <!-- thisuse isthe setfollowing toif false,you toARE preventusing multiplea versionssnapshot of SNAPSHOT files version. -->
  <snapshotRepository>
	     <uniqueVersion>false</uniqueVersion><id>glast-maven2-snapshots</id>
     <name>GLAST Maven2  </snapshotRepository>centreal SNAPSHOTS repository</name>
    </distributionManagement>
</project>

...

 <url>scp://glast-java.slac.stanford.edu:/nfs/slac/g/glast/ground/maven2/SNAPSHOTS</url>
     <!-- this is set to false, to prevent multiple versions of SNAPSHOT files -->
     <uniqueVersion>false</uniqueVersion>
   </snapshotRepository>

Or if you want to maintain a set of plugins use:

Code Block

title	GLAST plugin repository


    <pluginRepositories>
        <pluginRepository>
            <id>glast-maven2-plugins</id>
            <name>GLAST Maven2 central PLUGINS repository</name>
            <url>scp://glast-java.slac.stanford.edu:/nfs/slac/g/glast/ground/maven2/PLUGINS</url>
	    <uniqueVersion>false</uniqueVersion>
        </pluginRepository>
    </pluginRepositories>

An issue that can arise, when working with this type of hierarchy, is regarding the storage location of the source POM files. Source control management systems like CVS and SVN (with the traditional intervening trunk directory at the individual project level) do not make it easy to store and check out such a structure. These parent POM files are likely to be updated on a different, and less frequent schedule than the projects themselves. For this reason, it is best to store the parent POM files in a separate area of the source control tree, where they can be checked out, modified, and deployed with their new version as appropriate. In fact, there is no best practice requirement to even store these files in your source control management system; you can retain the historical versions in the repository if it is backed up (in the future, the Maven Repository Manager will allow POM updates from a web interface).

...

Code Block

title	Using GLAST parent POM

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <!-- every project POM must include GLAST parent POM -->
  <parent>
      <groupId>glast</groupId>
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  <artifactId>maven-parent</artifactId>
      <version>1.0</version>
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>glast</groupId>
  <artifactId>sample-maven-webapp</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Sample Maven Webapp</name>
  <url>http://glast-ground.slac.stanford.edu</url>
  <dependencies>
      <!-- everyenter project POM must include GLAST parent specific POM -->
  <parent></dependencies>
      <groupId>glast</groupId><build>
      <artifactId>maven-parent</artifactId><finalName>sampleMavenWebapp</finalName>
      <version>1.0</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>glast</groupId>
  <artifactId>sample-maven-webapp</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Sample Maven Webapp</name>
  <url>http</build>
</project>

Deploying your project in GLAST Maven 2 repository:

If you can deploy to cvs server and deploy to Maven 1, you are already set for deploying to Maven 2.

If not, make sure that you can ssh and scp to glast-java.slac.stanford.edu

Using ssh at SLAC is nicely described in: http://glast-ground.slac.stanford.

...

edu/workbook/^{Image Added} (Under Getting Conntected, Secure Shell).

To learn about ssh and different authentication strategies http://www.linux.com/articles/34958?tid=78&tid=82^{Image Added}

Basic requirement is that you need to be able to do scp without password authentication.

Using archetypes to create specific type of projects.

Often, you would like to use a default Maven 2 sceleton project for particular type of project, that are not already part of NetBeans or your IDE. In that case you need to locate your favorable 'archetype' on the web, and use it to build a sceleton project. For example, if there were many projects that are going to use Struts2 framework, one would download Struts2 starter project archetype, called struts2-archetype-starter.

To generate the starter project, select the working directory, and issue the following command:

Code Block

title	Creating a prototype project


mvn archetype:create
-DgroupId=org.glast.struts2
-DartifactId=app
-DarchetypeGroupId=org.apache.struts
-DarchetypeArtifactId=struts2-archetype-starter
-DarchetypeVersion=2.0.9-SNAPSHOT
-DremoteRepositories=http://people.apache.org/maven-snapshot-repository

This command will create a Struts2 application prototype, in the 'app' directdory. From there you can use the files in directory 'app' as a starting point for your new Struts2 application project

Deploying your project in GLAST Maven 2 repository:

If you can deploy to cvs server and deploy to Maven 1, you are already set for deploying to Maven 2.

If not, make sure that you can ssh and scp to glast-java.slac.stanford.edu

Using ssh at SLAC is nicely described in: http://glast-ground.slac.stanford.edu/workbook/^{Image Removed} (Under Getting Conntected, Secure Shell).

To learn about ssh and different authentication strategies http://www.linux.com/articles/34958?tid=78&tid=82^{Image Removed}

Basic requirement is that you need to be able to do scp without password authentication.

Web application deployments on tomcat servers

...

Child pages

Versions Compared

Old Version 13

New Version 14

Key

Deploying your project in GLAST Maven 2 repository:

Using archetypes to create specific type of projects.

Deploying your project in GLAST Maven 2 repository:

Web application deployments on tomcat servers