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

Create the repositories

The following artifacts are ones stored in a corporate environment:

  • inhouse released
  • inhouse snapshot
  • external non free - Oracle JDBC, J2EE stuff
  • external free - free but with annoying license restrictions so they can not be housed on ibiblio. Or any other projects not yet on ibiblio (in which case file a request to get it loaded into ibiblio see 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.

In this guide the logically different artifacts are stored in physicall separate repositories. There is no physical reason why you could not store them within the one repository but to make it obvious were artifacts have come from they are separated.

In the WEB_ROOT/maven2_repositories directory (which your sysadmin has already created) create these directories:

  • inhouse
  • inhouse_snapshot
  • external_free
  • external_non_free

If you are on a Unix machine ensure that the WEB_ROOT/maven2_repositories 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 running deployment commands.
TODO: Link to JIRA bug if there is one, and/or create it.

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

        <server>
            <id>inhouse_snapshot</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>
    ....
    </servers>

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>inhouse</id>
            <name>Inhouse Internal Release Repository</name>
            <url>
                scp://NUCLEUS/PATH/TO/WEB_ROOT/maven2_repositories/inhouse</url>
        </repository>
        <snapshotRepository>
            <id>inhouse_snapshot</id>
            <name>Inhouse Internal Snapshot Repository</name>
            <url>
                scp://NUCLEUS/PATH/TO/WEB_ROOT/maven2_repositories/inhouse_snapshot</url>
            <uniqueVersion>true</uniqueVersion>
        </snapshotRepository>
    </distributionManagement>
...

The "uniqueVersion" setting defaults to true and will mean that the uploaded snapshot will look like:

<artifactId>-<version>-<yyyyMMdd.HHmmss>-<buildNumber>

instead of just

<artifactId>-<version>

To deploy the artifact run: (Note: use -N if you don't want maven to run in recursive mode)

mvn deploy

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.

Additional documentation on the deploy goal is available at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html.

Consider the example of deploying the WebLogic jars. The WebLogic jar is an external non free jar and therefore needs to be deployed into the external_non_free repository.
Assume that the version of WebLogic is 8.1sp5 and 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_repositories/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.

The profile "repositoryDefinitions" is made active, but "inhouseSnapshot" is de-active by default.
If you want your project to be built against snapshot versions then activate the profile on the mvn command line via "-PinhouseSnapshot".

...
    <profiles>
        <profile>
            <id>repositoryDefinitions</id>
            <repositories>
                <repository>
                    <id>inhouse</id>
                    <name>Inhouse Repository</name>
                    <url>http://NUCLEUS/maven2_repositories/inhouse</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
                <repository>
                    <id>external_free</id>
                    <name>External Free Repository</name>
                    <url>http://NUCLEUS/maven2_repositories/external_free</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
                <repository>
                    <id>external_nonfree</id>
                    <name>External Non-Free Repository</name>
                    <url>http://NUCLEUS/maven2_repositories/external_non_free</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
            </repositories>
        </profile>
        <profile>
            <id>inhouseSnapshot</id>
            <repositories>
                <repository>
                    <id>inhouse_snaphot</id>
                    <name>Inhouse Snapshot Repository</name>
                    <url>http://NUCLEUS/maven2_repositories/inhouse_snapshot</url>
                    <releases>
                        <enabled>false</enabled>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                        <updatePolicy>always</updatePolicy>
                    </snapshots>
                </repository>
            </repositories>
        </profile>
        ...
    </profiles>
  ...
  <activeProfiles>
    <activeProfile>repositoryDefinitions</activeProfile>
  </activeProfiles>

Conclusion

After following this guide you should have four internal repositories configured for your corporate environment:

  • inhouse
  • inhouse_snapshot
  • external_free
  • external_non_free

You can deploy your snapshot artifacts to the inhouse_snapshot repository, your released artifacts to the inhouse repository and populate the external_free and external_non_free repositories with jar files as needed.

The settings.xml file has a lot of verbose information in it now. It would be nice if this could be cleaned up somehow.
The server section can't be changed as this will be needed whenever you deploy to one of the defined servers. However the repositoryDefinitions profile section can be made simpler by using a proxy infront of the internal repositories.

Creating a Maven proxy (in progress)

A Maven proxy can be thought of as a Maven mirror that aggregates one or more 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 parse or non existant as of 2006-01-13.

Prerequisites

Shell access to NUCLEUS

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

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