Dependency resolver and proxy

[mmatloka]

Our Hudson environment uses proxy. Unfortunately maven dependency resolver seams not to work properly. During arquillian tests on hudson we receive the following error:

WARNING: Failed downloading org/jboss/spec/jboss-javaee-6.0/3.0.1.Final/jboss-javaee-6.0-3.0.1.Final.pom from http://repo1.maven.org/maven2/, reason: org.apache.maven.wagon.TransferFailedException: Error transferring file: Connection refused

Sep 24, 2012 1:13:36 PM org.jboss.shrinkwrap.resolver.impl.maven.LogTransferListerer transferFailed

WARNING: Failed downloading org/jboss/arquillian/arquillian-bom/1.0.2.Final/arquillian-bom-1.0.2.Final.pom from http://repo1.maven.org/maven2/, reason: org.apache.maven.wagon.TransferFailedException: Error transferring file: Connection refused

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.191 sec <<< FAILURE!

Why is it trying to download it again althoug these dependencies exists in local repo? Is there any possible way to run this properly?

[alrubinger]

Can I see the code you're using to trigger this?

[mmatloka]

I've used the following resolver:

private static final MavenDependencyResolver RESOLVER = DependencyResolvers.use(

        MavenDependencyResolver.class ).loadMetadataFromPom( "pom.xml" );

Deployment

return ShrinkWrap.create( WebArchive.class )

            .addAsLibraries( RESOLVER.artifacts( MY_SOME_OTHER_SHARED_ARTIFACT, FEST_ARTIFACT ).resolveAsFiles() )

            .addAsWebInfResource( EmptyAsset.INSTANCE, BEANS_XML );

With this resolver, I'm resolving only 2 artifacts - FEST (which however according to fest documentation may be simply added as package "org.fest" ) and other module (MY_SOME_OTHER_SHARED_ARTIFACT) of project I'm trying to test using arquillian (multimodule maven project).

All arquillian and shrinkwrap components versions are from arquillian bom 1.0.2.Final.

[alrubinger]

Karel, could you look into this?  Reference: SHRINKWRAP-294

[kpiwko]

I did some debugging on current codebase. I'm convinced that this has nothing to do with SHRINKWRAP-294.

However, there are two facts I have discovered that comes to play:

1/ Offline propagation flag was not done correctly

2/ Since Maven 3, artifacts are being tracked for repositories where they come from (https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository ).

As we are using EnhancedLocalRepositoryManager, Shrinkres behaves the same as Maven 3.

I have fixed 1/ in SHRINKRES-104. As for 2/, the solution is difficult. You can either remove all _maven.repositories from your local repository (https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/integration/LocalRepositoryTestCase.java#L65) or, if you are sure that all artifact are available in local repository, you can switch to offline mode (https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/integration/LocalRepositoryTestCase.java#L89). Otherwise, there is a high chance it will fail

(https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/integration/LocalRepositoryTestCase.java#L108). I don't want the implementation to behave differently than Maven 3 by default, so I was thinking of ignoreArtifactTracking(boolean) method that user could use to programmatically ignore tracking repos as third solution.

Your thoughs?

Karel