Maven 2.x Ant Tasks

scp:// urls not recognised, even when wagon-ssh is installed.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.0.6
  • Fix Version/s: 2.0.7
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    3

Description

I have got the <install> task working to pull in the various deployment wagons

<target name="m2-wagons" depends="m2-pom,ssh-init">
<m2:install-provider artifactId="wagon-ssh"
version="${wagon-ssh.version}"/>
<m2:install-provider artifactId="wagon-ssh-external"
version="${wagon-ssh-external.version}"/>
<m2:install-provider artifactId="wagon-file"
version="${wagon-file.version}"/>
<m2:install-provider artifactId="wagon-ftp"
version="${wagon-ftp.version}"/>
</target>

But when I run a deploy target and use the scp:// protocol , I get the unknown protocol error.

<target name="m2-ssh-deploy" depends="m2-pom,ssh-init,m2-wagons">

<property name="m2.upload.url"
value="scp://${ssh.host}/www/repository"/>
<m2:deploy file="${target.jar}">
<remoteRepository url="${m2.upload.url}">
<authentication username="${ssh.user}"
privateKey="${ssh.keyfile}"/>
</remoteRepository>
<pom refid="m2.pom"/>
</m2:deploy>
</target>

This is only for scp:, the others, scpexe, file: and ftp: do work. Is the url schema wrong? Is there any way to enum what protocols are currently supported?

I would recommend that the error message "unsupported protocol" is supplemented with a listing of what protocols are supported. That way its easier to differentiate spelling error from uninstalled wagon.

Attachments

  1. Text File
    ant-v-logfile.txt
    08/May/07 1:55 PM
    21 kB
    Mykel Alvis
  2. File
    MANTTASKS-15_site_update.diff
    26/May/07 9:21 AM
    0.5 kB
    Herve Boutemy
  3. File
    MANTTASKS-15.diff
    22/Apr/07 5:43 AM
    3 kB
    Herve Boutemy

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

can't see the error, but will make the error reporting improvements. It does work in the sample script.

Show
Brett Porter added a comment - can't see the error, but will make the error reporting improvements. It does work in the sample script.
Hide
Permalink
Herve Boutemy added a comment -

Here is a patch to get a complete list of supported protocols.
When Ant is run in verbose mode ("ant -v"), the list of supported protocols is displayed after the new provider has been installed.

Show
Herve Boutemy added a comment - Here is a patch to get a complete list of supported protocols. When Ant is run in verbose mode ("ant -v"), the list of supported protocols is displayed after the new provider has been installed.
Hide
Permalink
Mykel Alvis added a comment -

I get this with 2.0.4 of the ant tasks, as well.
Per the logfile I attached, the scp protocol should be available (I think).

I tried substituting the full string instead of the property I was using for the url, but to no avail (as expected).

Show
Mykel Alvis added a comment - I get this with 2.0.4 of the ant tasks, as well. Per the logfile I attached, the scp protocol should be available (I think). I tried substituting the full string instead of the property I was using for the url, but to no avail (as expected).
Hide
Permalink
Mykel Alvis added a comment -

Ant -v run for my build...

Show
Mykel Alvis added a comment - Ant -v run for my build...
Hide
Permalink
Mykel Alvis added a comment -

I managed to work around this particular issue.

I WAS doing the following:

<target name="deploy-release" depends="install" description="Deploy released jars to the remote m2 repo">
<property name="repo.url" value="${remote.release.url}" />
<antcall target="deploy-subordinate" >
<param name="repo.url" value="${ remote.release.url}" />
</antcall>
</target>

<target name="deploy-subordinate" description="Sub task to perfom deploys based on a property">
<echo message="Deploying to ${ repo.url}" />
<echo message="using ${repository.username} and ${repository.privatekey}" />
<artifact:deploy file="${target.dist}/${artifactOne}">
<remoteRepository url="${ repo.url}">
<authentication username="${repository.username}" password="${repository.password}" />

{blahblahblah}

The thing I was failing to recognize is the nature of antcall'd tasks. Declaring the artifact:provider in one task makes it accessible in another task, but not if I do an "antcall" to a subtask in an effort to consolidate certain behaviors.. Dunno why I thought it would work. When I inheritRefs, the pom reference I have in the artifact:deploy (not shown) has a reference conflict.

So you can't do an antcall to call a task to do a deploy without re-decalaring the provider. I have a provider call setup as part of the "init" call that's a "depends" above, but the provider isn't available after the antcall.

It appears that wagon-ssh:1.0-alpha-7 is a valid scp provider, but 1.0-beta-2 gives an error:
java.lang.NoSuchMethodError: org.apache.maven.wagon.CommandExecutor.executeCommand (Ljava/lang/String;Z)Lorg/apache/maven/wagon/Streams;

Show
Mykel Alvis added a comment - I managed to work around this particular issue. I WAS doing the following: <target name="deploy-release" depends="install" description="Deploy released jars to the remote m2 repo"> <property name="repo.url" value="${remote.release.url}" /> <antcall target="deploy-subordinate" > <param name="repo.url" value="${ remote.release.url}" /> </antcall> </target> <target name="deploy-subordinate" description="Sub task to perfom deploys based on a property"> <echo message="Deploying to ${ repo.url}" /> <echo message="using ${repository.username} and ${repository.privatekey}" /> <artifact:deploy file="${target.dist}/${artifactOne}"> <remoteRepository url="${ repo.url}"> <authentication username="${repository.username}" password="${repository.password}" /> {blahblahblah} The thing I was failing to recognize is the nature of antcall'd tasks. Declaring the artifact:provider in one task makes it accessible in another task, but not if I do an "antcall" to a subtask in an effort to consolidate certain behaviors.. Dunno why I thought it would work. When I inheritRefs, the pom reference I have in the artifact:deploy (not shown) has a reference conflict. So you can't do an antcall to call a task to do a deploy without re-decalaring the provider. I have a provider call setup as part of the "init" call that's a "depends" above, but the provider isn't available after the antcall. It appears that wagon-ssh:1.0-alpha-7 is a valid scp provider, but 1.0-beta-2 gives an error: java.lang.NoSuchMethodError: org.apache.maven.wagon.CommandExecutor.executeCommand (Ljava/lang/String;Z)Lorg/apache/maven/wagon/Streams;
Hide
Permalink
Herve Boutemy added a comment -

Mykel,

Did you try <antcall inheritRefs="true" ...>? This should preserve "org.codehaus.plexus.PlexusContainer" reference, which contains the providers installed.
Can you try it and confirm, please? Then I'll update the documentation.

For your problem with wagon-ssh:1.0-beta-2, it seems you're using Maven Ant Tasks 2.0.4: this 1.0-beta-2 version is for 2.0.6, not 2.0.4. You should not have any problem when using Maven Ant Tasks 2.0.6

Show
Herve Boutemy added a comment - Mykel, Did you try <antcall inheritRefs="true" ...>? This should preserve "org.codehaus.plexus.PlexusContainer" reference, which contains the providers installed. Can you try it and confirm, please? Then I'll update the documentation. For your problem with wagon-ssh:1.0-beta-2, it seems you're using Maven Ant Tasks 2.0.4: this 1.0-beta-2 version is for 2.0.6, not 2.0.4. You should not have any problem when using Maven Ant Tasks 2.0.6
Hide
Permalink
Herve Boutemy added a comment -

ok, I tried inheritRefs but it doesn't work: there is a ClassCastException when using PlexusContainer reference...
I don't think we can do much about it, since it is related to Ant classloading mechanisms.

To me, the only thing to do is to add a note in the documentation: this is the patch I'm attaching.

Show
Herve Boutemy added a comment - ok, I tried inheritRefs but it doesn't work: there is a ClassCastException when using PlexusContainer reference... I don't think we can do much about it, since it is related to Ant classloading mechanisms. To me, the only thing to do is to add a note in the documentation: this is the patch I'm attaching.
Hide
Permalink
Jason van Zyl added a comment -

Patches applied.

Show
Jason van Zyl added a comment - Patches applied.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.