Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The best practice is to define GLAST wide parent POM file, which will define defines GLAST specific repositories, settings, etc, which all the GLAST Java projects will use. Untils than I will assume that settings and properties in profile.xml will slowly migrate up the hieararchy to project POM files, up to its parent GLAST POM file. 3.

Maven 2 repositories

...

...

GLAST Maven 2 repository location

Glast Maven 2 repositories are located on the NFS file system

/nfs/slac/g/glast/ground/maven2 (releases)
/nfs/slac/g/glast/ground/maven2/SNAPSHOTS (snapshots)

They can be viewed through the web interface http://glast-ground.slac.stanford.edu/maven2/Image Added

GLAST parent POM

Currently Maven 2 supports several methods of deployment, including simple file-based deployment, SSH2 deployment, SFTP deployment, FTP deployment, and external SSH deployment. In order to deploy, you need to correctly configure your distributionManagement element in your POM, which would typically be your top-level POM, so that all child POMs can inherit this information. In our case, we have decided to create a GLAST wide POM, which all Maven 2 Java modules will inherit from.

GLAST parent POM defines distributionManagement for all children POMs, so developers do not need to bother with distribution management, and also allows centeral management of global GLAST development resources.

In order to deploy to the GLAST Maven 2 repository, we use ssh2 protocol, and the following distributionManagement elements

Code Block
titleGLAST 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.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.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>
        <!-- use the following if you're not using a snapshot version. -->
        <repository>
            <id>glast-maven2</id>
            <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 if you ARE using a snapshot version. -->
        <snapshotRepository>
            <id>glast-maven2-snapshots</id>
            <name>GLAST Maven2 centreal SNAPSHOTS repository</name>
            <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>
    </distributionManagement>
</project>

The Maven GLAST POM declares the elements that are common to all of its sub-projects - the snapshot repository and the release repository deployment locations. I feel that it is best practice to follow open source releases which also separates SNAPSHOTS directory from release directory.

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

Using GLAST parent POM.

All what is necessary is to include parent in each of the project POM files. This is done as in the following example:

Code Block
titleUsing GLAST parent POM

<?xml version="1.0" encoding="UTF-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>
      <artifactId>maven-parent</artifactId>
      <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://glast-ground.slac.stanford.edu</url>
  <dependencies>
      <!-- enter project specific POM -->
  </dependencies>
  <build>
    <finalName>sampleMavenWebapp</finalName>
  </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=82Image Added

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

Web application deployments on tomcat servers

Todo

Appendix A

Here we give Maven 1.x files  for reference:

...