Maven - deploy dependencies to remote repository

Question

I have a few projects with LOTS of maven dependencies. When I invoke the command mvn deploy (or some variation of it), I would like to not only have the project itself depl

Answer 1

I propose the following solution which looks a lot less like trial and error for resolving dependencies compared to the existing answers.

What you can do is to call mvn -Dmdep.copyPom=true dependency:copy-dependencies after deploying the main project. This will copy transitively all dependencies of your project to target/dependency including their respective pom files.

You can then iterate through all of the dependencies and deploy them to the repository using deploy:deploy-file, e.g. with such a bash loop:

for pom in target/dependency/*.pom; do mvn deploy:deploy-file -Durl=http://your/repo -Dfile="${pom%%.pom}.jar" -DgeneratePom=false -DpomFile="$pom"

Answer 2

Here's how it works in a nutshell, assuming your remote repository (Nexus, or Artifactory, or the like) and settings.xml are configured correctly.

Let's say you have a project with one dependency on commons-logging. When Maven resolves your project's dependencies as part of a build, it does these steps:

1. Checks local repo for commons-logging.
2. If found, done. Continue with build.
3. If not found: checks for commons-logging in the remote repo.
4. If found, download artifact to local repo. Done; continue with build.
5. If not found in remote repo: remote repo contacts central to download commons-logging. Then it's available for Maven to download to local repo. Done; continue with build.

At the end of these steps, commons-logging should be in both your local and remote repos with nothing further to do. If this is not the case, then either your settings.xml is not configured to connect to the remote repo when searching for dependencies (is it contacting central directly?) or Nexus isn't configured correctly.

---- Edit ----

Here's a snippet of my settings.xml that works. @Raghuram gave you a good tip when he suggested you enable both profiles; if you somehow enabled only the public-snapshots profile your builds would continue to hit maven central directly.

....
<mirrors>
    <!-- redirects all traffic to internal Nexus repo instead of Maven central -->
    <mirror>
        <id>maven2</id>
        <mirrorOf>*</mirrorOf>
        <url>http://repository.someCompany.com/maven2RepoOrGroupInNexus</url>
    </mirror>
</mirrors>
....
<profiles>
    <profile>
        <id>repo-profile</id>
        <repositories>
            <repository>
                <id>central</id>
                <url>http://gotoNexus</url>  <!-- URL is unimportant here -->
                <snapshots>
                    <enabled>true</enabled>
                    <updatePolicy>daily</updatePolicy>
                </snapshots>
                <releases>
                    <enabled>true</enabled>
                    <updatePolicy>daily</updatePolicy>
                </releases>
            </repository>
        </repositories>
    </profile>
</profiles>
<activeProfiles>
    <activeProfile>repo-profile</activeProfile>  <!-- important -->
</activeProfiles>

Note the activeProfiles element at the bottom; that's how to ensure you'll use Nexus instead of Maven central with every mvn command.

You still need to make sure Nexus is configured so that the URL defined in the <mirror> includes content from Maven central, but how to configure Nexus would be a separate question.

Reference: Nexus docs for Maven configuration

Answer 3

You could start with a clean local repository, attempt to build your application and for any dependency failure, deploy that application to your corporate repository. This would ensure that all the dependencies that your application needs resides in the corporate repository prior to your application getting built and deployed.

Prior to this, you would configure your local repository to mirror central and other well-known repositories, so that open source third-party libraries automatically get into your remote repository instead of having to be manually uploaded.

It may turn out that you may not have too many third-party libraries which you would need to manually deploy.