Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current ·  View Page History
<< Previous Version 4 Next >>

Overview

In a corporate environment it makes sense to have some control over the setup of Maven.
For example:

  • restricting dependencies to approved versions of artifacts
  • reducing network bandwidth by having a maven repository proxied
  • sharing corporate assets by deploying them centrally

These scenarios can be realized by using internal Maven repositoriesand a Maven proxy. Be very careful not to confuse these two concepts as both services are often located on the same physical machine and it is easy to get them mixed up.

This guide will recommend installing both the Maven internal repositories and the Maven proxy on a single machine and to make this guide a bit more readable this machine will be called NUCLEUS.

To get an overview of repositories please read http://maven.apache.org/guides/introduction/introduction-to-repositories.html

For another example of repository setup with diagrams showing this configuration see http://cvs.peopleware.be/training/maven/maven2/repositories.html

Definitions of Repositories

A repository holds Maven artifacts in a well defined directory structure.

The purpose of the repository influences the types of resources that are stored in that repository.

The following list attempts to define the different terms used when discussing different repository types.

local repository

The directory structure on your local machine which stores all the artifacts required by all the projects on your system.

It is a cache of artifacts from remote repositories for any mvn command you have run.

remote repository

A remote repository is where the user may get artifacts from. A remote repository can be located anywhere and accessed by any protocol supported by Wagon (ftp/scp/http/file/...)

intranet repository

A remote repository inside your firewall, i.e. a repository not on your machine but in the confines of your organization.

You might have internal release/snapshot repositories as well.

private repository

Same as #internal repository.

central repository

A special remote repository which is situated at http://www.ibiblio.org/maven2/.

This remote repository is where most open source software artifacts are located.

release repository

A release repository is a remote repository specifically for housing released code.

No snapshots should be stored in this repository.

snapshot repository

A snapshot repository is a remote repository specifically for housing non-release code as snapshots should not be stored with released artifacts.

Using Maven in a corporate environment

Prerequisites

A web server already running and configured on NUCLEUS.

A web server is needed so that the internal repositories can be accessed from the local desktops.

scp access to NUCLEUS

It is out of scope for this guide to walk through setting scp up on the server.

The local desktop will need a SSH client which are available for Unix at http://www.openssh.com/ and Windows at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Shell access to NUCLEUS

Shell access is needed to exectute commands and to configure the initial repository layout. This may be done in conjunction with a sysadmin if you do not have the required privileges.

Write access to a web server visible directory.

In this guide the Maven repositories will be installed into a location that has been configured for access by your web server.

This guide will use the location WEB_ROOT/maven2.

Configuration

The following artifacts are ones stored in a corporate environment:

  • inhouse
  • external non free - Oracle JDBC, J2EE stuff
  • external free - free but annoying download license restrictions so they
    can not be housed on ibiblio and any other projects not yet on ibiblio
    (in which case file a request to get it loaded into ibiblio by following
    http://maven.apache.org/guides/mini/guide-ibiblio-upload.html)

Note: these categories are paraphrased from the Proximity web site https://is-micro.myip.hu/projects/ismicro-commons/proximity/configuration.html

The corporate environment should only contain artifacts as categorised above, any other artifacts should be obtained from the proper repository and not be duplicated in the corporate repository.
However these remote non-corporate environment repositories may be proxied. See #Creating a Maven proxy.  Remember a proxy and a repository are different concepts.

Separate repositories are created to physically separate the logically different artifacts from each other. There is nothing stopping you from storing all the artifacts within the one repository.

Create the repositories

In the WEB_ROOT/maven2 directory (which your sysadmin has already created) create three new directories:

  • inhouse
  • external_free
  • external_non_free

If you are on a Unix machine ensure that the WEB_ROOT/maven2 directory has g+ws permission (the s bit ensures that files and directories created will have the same group access control).

Configure settings.xml

Now that the repositories have been created, each deployer's settings.xml file will need to specify these repositories in the server section:

Note: There appears to be some bugs with permissions not being set. You may need to manually set the permissions after deployment.
TODO: Link to JIRA bug if there is one, and/or create it.

<server>
      <id>inhouse</id>
      <username>DEVELOPERS_USERNAME</username>
      <privateKey>PATH/TO/SSH.key</privateKey>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

    <server>
      <id>external_free</id>
      <username>DEVELOPERS_USERNAME</username>
      <privateKey>PATH/TO/SSH.key</privateKey>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

    <server>
      <id>external_non_free</id>
      <username>DEVELOPERS_USERNAME</username>
      <privateKey>PATH/TO/SSH.key</privateKey>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

 

Deploy artifacts into a repository

Deploying inhouse artifacts

Inhouse artifacts should have the correct sections of the pom completed so that the deploy goal will work without having to specify any extra arguments.

...
    <distributionManagement>
        <repository>
            <id>internal</id>
            <name>Internal Corporate Repository</name>
            <url>
                scp://NUCLEUS/PATH/TO/WEB_ROOT/maven2/internal</url>
        </repository>
    </distributionManagement>

 

Deploying external free or external non free artifacts

External free (ones not available from ibiblio because of annoying license restrictions) and External non free artifacts can be deployed to their respective repository.

Since these are normally well versioned jar files there is no need for any snapshots in these repositories.

For further documentation on the deploy goal see
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html.

For example the weblogic 8.1sp5 jar is an external non free jar and therefore needs to be deployed into the external_non_free repository.
Assuming that the weblogic.jar is in the current directory then use the following command:

Note: The trailing slashes are used to represent the command continues onto the next line. This works fine on Unix but not on Windows. You will need to ensure that this command is all on one line with the trailing slashes removed.

mvn deploy:deploy-file -DgroupId=weblogic -DartifactId=weblogic -Dversion=8.1.5 \
  -DgeneratePom=true \
  -Dpackaging=jar \
  -Dfile=weblogic.jar \
  -DrepositoryId=external_non_free \
  -Durl=scp://NUCLEUS/PATH/TO/WEB_ROOT/maven2/external_non_free

 

Defining repositories in settings.xml

By defining these repositories in the settings.xml they will automatically get checked for artifacts.

Note that these repositories do not contain any Maven plugins and if plugins are needed then the pluginRepositories section will need to be completed with appropriate details.

Inhouse Corporate plugins are likely to be the only ones needing a repository definition.

...
    <profiles>
        <profile>
            <id>repositoryDefinitions</id>
            <repositories>
                <repository>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>daily</updatePolicy>
                        <checksumPolicy>warn</checksumPolicy>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                        <checksumPolicy>warn</checksumPolicy>
                    </snapshots>
                    <id>inhouse</id>
                    <name>Inhouse Repository</name>
                    <url>http://NUCLEUS/maven2/inhouse</url>
                    <layout>default</layout>
                </repository>
                <repository>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>daily</updatePolicy>
                        <checksumPolicy>warn</checksumPolicy>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>external_free</id>
                    <name>External Free Repository</name>
                    <url>http://NUCLEUS/maven2/external_free</url>
                    <layout>default</layout>
                </repository>
                <repository>
                    <releases>
                        <enabled>true</enabled>
                        <updatePolicy>daily</updatePolicy>
                        <checksumPolicy>warn</checksumPolicy>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>external_nonfree</id>
                    <name>External Non-Free Repository</name>
                    <url>http://NUCLEUS/maven2/external_non_free</url>
                    <layout>default</layout>
                </repository>
            </repositories>
        </profile>
        ...
    </profiles>
  ...
  <activeProfiles>
    <activeProfile>repositoryDefinitions</activeProfile>
  </activeProfiles>

 

Creating a Maven proxy

(STILL TO BE COMPLETED, and in apt format...)

A Maven proxy can be thought of as a Maven mirror that aggregates Maven
repositories.

This document will walk through the setup of maven-proxy
http://maven-proxy.codehaus.org/. At least one other alternative exists
called Proximity
https://is-micro.myip.hu/projects/ismicro-commons/proximity/projects-overview.html
however I found the documentation to be sparse or non existant as of
2006-01-13.

  • Prerequisites

You will need the following before you can start setting up maven-proxy.

  • A Web Server already running and configured on NUCLEUS.
  • shell access to NUCLEUS
  • write access to a Web Server visibile directory
  • maven1 (the build scripts for maven-proxy are not yet using maven2)
  • latest maven-proxy from CVS
  • maven-proxy.properties configuration file.
    The configuration properties file can be found at
    {{http://maven-proxy.codehaus.org/Configuration}}and select the SNAPSHOT
    property file
    http://cvs.maven-proxy.codehaus.org/*checkout*/maven-proxy/core/src/test/resources/org/apache/maven/proxy/config/PropertyLoaderTest1.properties?rev=HEAD
    and will need to be saved into a new file "maven-proxy.properties"
  • Build maven-proxy

There is a "build.sh" file in the root of maven-proxy that will build the
sytem. If you are on a windows machine then you will need to manually run
the steps from the script.
In each directory core and standalone run:

maven clean build:snapshot

 

This guide will walk through the use of the standalone server which when
built will be in "standalone\target\maven-proxy-standalone-SNAPSHOT-app.jar"

  • Upload maven-proxy to NUCLEUS

If you are building maven-proxy on a local workstation then upload the
maven-proxy-standalone-SNAPSHOT-app.jar and maven-proxy.project to NUCLEUS.

Labels
  • None