Maven 2.x Ant Tasks

Dependencies ignoring user defined repo location and reverting to central

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1.0
  • Fix Version/s: None
  • Component/s: dependencies task
  • Labels:
    None
  • Environment:
    Windows XP
  • Number of attachments :
    1

Description

I have a very simple dependencies declaration:

<artifact:dependencies filesetId="dependency.fileset" settingsFile="${app.mavenSettings}">
    <dependency groupId="com.mycompany.infrastructure" artifactId="artifact" version="2.0.0"/>
</artifact:dependencies>

I have 2 mirrors set up:

<mirrors>
	<mirror>
		<id>all_mirror</id>
		<name>Nexus All</name>
		<url>http://maven-proxy.mycompany.com/content/groups/all</url>
		<mirrorOf>*,!central</mirrorOf>
	</mirror>
	<mirror>
		<id>central_mirror</id>
		<name>Nexus Releases</name>
		<url>http://maven-proxy.mycompany.com/content/groups/public</url>
		<mirrorOf>central</mirrorOf>
	</mirror>
</mirrors>

When I instruct Maven to retreive the dependency it gets the pom file correctly, which contains a 2nd dependency, which is retrieved. These are both retrieved from the correct repo. But the 2nd pom then defines another dependency. But this 3rd dependency is searched for at central, where it doesnt exist (all artifacts are internal libraries).

Downloading: com/mycompany/myartifact1/version1/artifact1-version1.pom from repository central_mirror at http://mycompany.com/content/groups/public
Transferring 4K from central_mirror
Downloading: com/mycompany/myartifact2/version2/artifact2-version2.pom from repository central_mirror at http://mycompany.com/content/groups/public
Transferring 24K from central_mirror
Downloading: com/mycompany/myartifact3/version3/artifact3-version3.pom from repository central at http://repo1.maven.org/maven2
Error transferring file: Connection timed out: connect

So the first 2 are resolved and d/loaded fine, but the 3rd suddenly reverts to looking in central, when it is present and correct in the central_mirror repo.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MANTTASKS-191 No explanation of how to use multiple Maven repositories to resolve dependencies

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Edward Thorne added a comment -

I think this is caused by by the way the mirrors are being handled in the ant tasks. There's a todo in AbstractArtifactTask.updateRepositoryWithSettings (line 423) to initialize the wagon manager to be more like m2. I'm attaching a patch file created from 2.1.3 that I'm using to keep the ant tasks from searching outside the defined mirror.

What I'm pretty certain is happening is that the current code is changing known repositories to the mirror id and path, but any repo discovered in the POM file (including the super pom) through transitive dependency management is being picked up. Since the wagon manager is unaware of the mirrors, it goes directly to the remote repo, bypassing the mirror. This isn't desired in our case because we only want to use assets mirrored on our repository.

I've tested this as far as mirrors are concerned. I have not tested it with regards to proxies or authentication but I believe the code should work.

Show
Edward Thorne added a comment - I think this is caused by by the way the mirrors are being handled in the ant tasks. There's a todo in AbstractArtifactTask.updateRepositoryWithSettings (line 423) to initialize the wagon manager to be more like m2. I'm attaching a patch file created from 2.1.3 that I'm using to keep the ant tasks from searching outside the defined mirror. What I'm pretty certain is happening is that the current code is changing known repositories to the mirror id and path, but any repo discovered in the POM file (including the super pom) through transitive dependency management is being picked up. Since the wagon manager is unaware of the mirrors, it goes directly to the remote repo, bypassing the mirror. This isn't desired in our case because we only want to use assets mirrored on our repository. I've tested this as far as mirrors are concerned. I have not tested it with regards to proxies or authentication but I believe the code should work.
Hide
Permalink
Edward Thorne added a comment -

Reworking to use settings to initialize the WagonManager with mirror, proxy, and authentication information.

Show
Edward Thorne added a comment - Reworking to use settings to initialize the WagonManager with mirror, proxy, and authentication information.
Hide
Permalink
Alexander Lehmann added a comment -

I noticed a similar problem when using the maven-ant task for jbehave-distribution, this fails to resolve artifacts on alternate repositories.

It turns out that it works if the pom task loads the settings, but it doesn't if the dependencies task loads the settings.

(the same pom.xml works when using maven however).

Show
Alexander Lehmann added a comment - I noticed a similar problem when using the maven-ant task for jbehave-distribution, this fails to resolve artifacts on alternate repositories. It turns out that it works if the pom task loads the settings, but it doesn't if the dependencies task loads the settings. (the same pom.xml works when using maven however).

People

  • Assignee:
    Unassigned
    Reporter:
    Paul WIlliams
Vote (2)
Watch (3)

Dates

  • Created:
    Updated: