views:

996

answers:

1

I'm trying to use Subversion as Maven repo utilizing Maven wagon. If I declare snapshot location using http as protocol I get 409 error back from server when trying to deploy (mvn clean deploy)

<snapshotRepository>
        <uniqueVersion>false</uniqueVersion>
        <id>engtools_snapshots</id>
        <name>EngTools Maven Repository</name>
        <url>http://continuum.td.com/svn_repos/maven/snapshots&lt;/url&gt;
</snapshotRepository>

When I change protocol to scm:svn:http things are getting even more weird - I get several errors seemingly related to realm

<snapshotRepository>
        <uniqueVersion>false</uniqueVersion>
        <id>engtools_snapshots</id>
        <name>EngTools Maven Repository</name>
        <url>scm:svn:http://continuum.td.com/svn_repos/maven/snapshots&lt;/url&gt;
</snapshotRepository>

SCM configuration

        <extensions>
        <extension>
            <groupId>org.apache.maven.wagon</groupId>
            <artifactId>wagon-scm</artifactId>
            <version>1.0-beta-6</version>
        </extension>
        <extension>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-manager-plexus</artifactId>
            <version>1.3-SNAPSHOT</version>
        </extension>
        <extension>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-provider-svnexe</artifactId>
            <version>1.3-SNAPSHOT</version>
        </extension>
    </extensions>

Partial stacktrace resulting from (mvn deploy)

[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from engtools_snapshots
[FATAL ERROR] org.apache.maven.plugin.deploy.DeployMojo#execute() caused a 
linkage error (java.lang.AbstractMethodError) and may be out-of-date. Check 
the realms:
[FATAL ERROR] Plugin realm = 
app0.child-container[org.apache.maven.plugins:maven-deploy-plugin:2.4]
urls[0] = file:/C:/Documents and Settings/boo/.m2/repository/org/apache/
maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.jar
urls[1] = file:/C:/Documents and Settings/boo/.m2/repository/org/codehaus/
plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/C:/java/apache-maven-2.2.0/bin/../lib/maven-2.2.0-uber.jar
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.
executeCheckOutCommand(Lorg/apache/maven/scm/provider/ScmProviderRepository;
Lorg/apache/maven/scm/ScmFileSet;Lorg/apache/maven/scm/ScmVersion;)
Lorg/apache/maven/scm/command/checkout/CheckOutScmResult;
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.AbstractMethodError: org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.
executeCheckOutCommand(Lorg/apache/maven/scm/provider/ScmProviderRepository;
Lorg/apache/maven/scm/ScmFileSet;Lorg/apache/maven/scm/ScmVersion;)Lorg/apache/maven/scm/command/checkout/CheckOutScmResult;
 at org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.executeCommand(
AbstractCheckOutCommand.java:49)
 at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
+1  A: 

If you look at wagon-scm's POM you'll see it has dependencies on the 1.0 versions of the maven-scm-provider-* artifacts. In your extensions section you've referenced the 1.3-SNAPSHOT versions.

From version 1.2 onwards, the AbstractCheckOutCommand's executeCheckOutCommand() method is no longer abstract, instead it delegates to another abstract method with an additional recursive parameter. Because of this change you get the linkage error.

The simplest way to remedy this is to change the versions of the maven-scm-provider-* extensions to be consistent with those required by wagon-scm, i.e. change the 1.3-SNAPSHOT versions for 1.0 or 1.1 versions.

It's worth pointing out I think that using an SCM system to host your Maven repository is not really a good idea, particularly for SNAPSHOT artifacts. Instead I'd recommend using a repository manager, they provide lots of useful features on top of hosting the artifacts.

Rich Seller
Hi Rich,Thanks for pointing this out, I will check it tomorrow and if works - will mark this as an accepted answer. I did look at the Artifactory as an option but that means yet another app server to maintain so I'll see how SCM solution will work
DroidIn.net
Yep - problem solved, thanks Rich!
DroidIn.net
Glad to help, but I really would consider using a repository manager, you can even run Nexus or Artifactory standalone (they both use bundled Jetty) so no app server to manage
Rich Seller