Dependency on the external-dependency

[Daniel]

Hi all,

I have a little problem with the workflow of the plugin.
I define my external dependencies just like the example pom.
But I also need these dependencies for compile, so I define them as
the pom dependency.

The problem is when running maven it first tries to resolve the
dependencies before the external resolving goal is executed.
This also happens with the sample pom.

The only thing I changed is the pluginRepositories and repositories
definition (to redirect to our internal nexus repository).

I am also using maven 2.2.1.

Any help would be appreciated.

Daniel

[Daniel]

As a follow up I moved the dependency resolving to a parent pom.
It now resolves and installs but it first try to find the artifact in
the repositories that were defined in the pom and at the end downloads
it from the the <downloadUrl>.
Seems a bit strange as it won't find it in the other repositories and
will get a 404.

[Robert Savage]

Hi Daniel,

I don't think I fully understand the problem you are having.  

The test project does include a dependency artifact that is required for (java) compile time of the project.  If you look at App.java in the test project, you will see that there are some references to Google Translate classes that are provided by artifact: 

<!-- PROJECT DEPENDENCIES -->

<dependencies>

<dependency>

<groupId>com.google.code</groupId>

<artifactId>google-api-translate-java</artifactId>

<version>0.92</version>

</dependency>

<dependency>

<groupId>org.papervision3d</groupId>

<artifactId>Papervision3D</artifactId>

<version>2.1.932</version>

<type>swc</type>

</dependency>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>3.8.1</version>

<scope>test</scope>

</dependency>

</dependencies>

This artifact is not hosted publicly in a maven repository by this groupId and artifactId, so maven is not able to automatically resolve it.  So, I include a reference to it in the configuration for the external dependency plugin.   

<!-- THIS JAR IS HOSTED ON GOOGLE CODE, BUT IS NOT AVAILABLE IN A MAVEN 

REPO -->

<artifactItem>

<groupId>com.google.code</groupId>

<artifactId>google-api-translate-java</artifactId>

<version>0.92</version>

<packaging>jar</packaging>

<downloadUrl>

http://google-api-translate-java.googlecode.com/files/{artifactId}-{version}.jar

        </downloadUrl>

</artifactItem>

The timing of when this plugin executes to resolve the external dependency is manually defined by the "process-resources</phase>" line.  

On this phase, this plugin resolves and installs the external artifacts.  You can modify this configuration and bind it to an earlier phase in the maven lifecycle to get it to run at an earlier time if needed.  

However, "process-resources</phase>" should occur before project compile time.  

<executions>

<execution>

<id>clean-external-dependencies</id>

<phase>clean</phase>

<goals>

<goal>clean-external</goal>

</goals>

</execution>

<execution>

<id>resolve-install-external-dependencies</id>

<phase>process-resources</phase>

<goals>

<goal>resolve-external</goal>

<goal>install-external</goal>

</goals>

</execution>

<execution>

<id>deploy-external-dependencies</id>

<phase>deploy</phase>

<goals>

<goal>deploy-external</goal>

</goals>

</execution>

As for the resolving workflow, yes, by default Maven will attempt to resolve these dependencies via existing defined repositories in your POM.  

Since they cannot be found in any of the defined pom repositories, they will result in 404 NOT FOUND messages.  

Next, if the dependencies are not found using the conventional Maven repository resolution (which it will not, unless already installed to local M2 repo or team/company repo), the external maven dependency plugin will step in and attempt to download these artifacts using the specified URL paths and install them into your local M2 repository.   

Since the compile time dependencies are defined normally in the pom file, I did not find a way to circumvent the conventional Maven repository resolution process.  Any actually, I think we do not want to circumvent the normal Maven resolution process.  

If these external dependencies have already been downloaded and installed locally to the local M2 repo, then you probably don't want to try to re-download them from the Internet on every maven build cycle.

Additionally, you can opt to deploy (http://www.savage7.com/maven/plugin/maven-external-dependency-plugin/deploy-external-mojo.html) these external dependencies to a team or company hosted M2 repository, then if that team or company hosted M2 repository, is defined as a repository in the POM file , then the maven build can resolve it from the team/company repo first and avoid the step of having to download from the Internet.   Of course you don't have to deploy these external artifacts to a team repo, then each team member maven build will simply download it and installed it to their local M2 repos.

I can see why attempting to resolve these defined external dependency artifacts in POM defined repositories would seem strange, but the use case of the team/company shared M2 repository and potentially rare cases where the artifact eventually does get hosted in a public repository I think the default maven dependency resolution is necessary.  There may be one possibility (I have not tried this) to optimize this for your use case by defining the resolve-external and install-external goals to an earlier phase in the maven lifecycle, this may cause the manual external download to occur first, then the default maven dependency resolution may not attempt to look up the artifacts since they are already in the local M2 repository.  

 

PS, I am also using maven 2.2.1.

Thanks, Robert

[Daniel]

Hey Robert,

I tried the sample project now, at home where I don't have access to
my nexsus repository and it works great. I will try it more when I am
back at work(on sunday) to test it.

But I did find the real cause why it's not working for my project.
In the company parent pom we have the enforce plugin definition.
This causes maven to ignore the external plugin resolving.

When I remove the enforce definition or the reference to the parent
pom it works!
You can try it on the Sample Project, just add:
<build>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>enforce-plugin-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requirePluginVersions>
<message>ERROR: Please always define plugin
versions.</message>
<banLatest>true</banLatest>
<banRelease>true</banRelease>
<banSnapshots>false</banSnapshots>
<banTimestamps>false</banTimestamps>
<phases>clean,deploy,install</phases>
<unCheckedPlugins>
<unCheckedPlugin>org.apache.maven.plugins:maven-
idea-plugin</unCheckedPlugin>
<unCheckedPlugin>org.apache.maven.plugins:maven-
eclipse-plugin</unCheckedPlugin>
<unCheckedPlugin>org.apache.maven.plugins:maven-
archetype-plugin</unCheckedPlugin>
<unCheckedPlugin>org.codehaus.mojo:sonar-maven-
plugin</unCheckedPlugin>
</unCheckedPlugins>
<unCheckedPluginList>${global.unCheckedPlugins}</
unCheckedPluginList>
</requirePluginVersions>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</build>

This is the definition we have.

> Additionally, you can opt to deploy (http://www.savage7.com/maven/plugin/maven-external-dependency-plugin/...) these external dependencies to a team or company hosted M2 repository, then if that team or company hosted M2 repository, is defined as a repository in the POM file , then the maven build can resolve it from the team/company repo first and avoid the step of having to download from the Internet.   Of course you don't have to deploy these external artifacts to a team repo, then each team member maven build will simply download it and installed it to their local M2 repos.

[Robert Savage]

One thing to note ...

The sample project POM includes a "deploy-external" goal in the "deploy"
phase, if you have a deployment repository setup and you deploy your project
to a team/company maven repository, the plugin will deploy these external
artifacts to that repo as well. If you don’t want that behavior, comment
out or remove the deployment goal in the executions configuration.

-Robert

[Daniel]

Thanks for the reply Robert.

I did remove it as I don't want to put it in the company
repository,these artifact will be there eventually, as they are other
company projects which will migrate to maven in the future.
Still the enforce problem is strange, I think there should be at least
some mentioning of it in the wiki :)

> ...
>
> read more »