GMaven

Ant Dependency fails to resolve

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    linux (ubuntu), maven 2 v2.0.9, jdk 1.5.0_12, gmaven v 1.0-rc-2
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

I am trying to use the optional Ant FTP task in a groovy script using the gmaven plugin but I continue to get a ClassNotFoundException. I did get the commons-lang example working that uses the SystemUtils class though, so I am not sure what the difference is.

I have attached my POM.

Here is the error:

[INFO] [groovy:execute {execution: default}]
[INFO] Entering in ftp script
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] : Problem: failed to create task or type ftp
Cause: the class org.apache.tools.ant.taskdefs.optional.net.FTP was not found.
This looks like one of Ant's optional components.
Action: Check that the appropriate optional JAR exists in
-ANT_HOME/lib
-the IDE Ant configuration dialogs

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem
--------------------------------------------

Now I know I could probably fix this issue by dropping the jar file in ANT_HOME, but I don't want to do that because I have several machines I would have to update including all the developers on the team having to do the same. Besides it should work by specifying a classpath element.

Issue Links

This issue relates to:
GMAVEN-31 Access Maven Classpaths for Ant Tasks Critical Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason Dillon added a comment -

I think the commons-lang doc is a bug, since commons-lang is already in the classpath from transitive deps. Will have a look at what is wrong shortly.

Show
Jason Dillon added a comment - I think the commons-lang doc is a bug, since commons-lang is already in the classpath from transitive deps. Will have a look at what is wrong shortly.
Hide
Permalink
Jason Dillon added a comment -

Well, I think I understand why this is problematic now, due to the provider classloader having the ant bits, which is the parent of the classloader which contains the project+user bits, thus antbuilder (and ant) can't see it.

Though you can actually import the class and use it directly:

import org.apache.tools.ant.taskdefs.optional.net.FTP
println FTP

I'm going to ponder how to fix this more. Not sure it will make it into rc-3 though, as I think the change is rather large.

Show
Jason Dillon added a comment - Well, I think I understand why this is problematic now, due to the provider classloader having the ant bits, which is the parent of the classloader which contains the project+user bits, thus antbuilder (and ant) can't see it. Though you can actually import the class and use it directly: 
import org.apache.tools.ant.taskdefs.optional.net.FTP
println FTP
I'm going to ponder how to fix this more. Not sure it will make it into rc-3 though, as I think the change is rather large.
Hide
Permalink
James Lorenzen added a comment -

I can't believe I didn't actually try importing the class explicity.
I think that is a sufficient work around. Ideally it would be nice if it just used the dependencies.

Show
James Lorenzen added a comment - I can't believe I didn't actually try importing the class explicity. I think that is a sufficient work around. Ideally it would be nice if it just used the dependencies.
Hide
Permalink
Jason Dillon added a comment -

I've looked into this a lot more over the past few days, and I think I can make this work, at the cost of creating new classloaders for each execution... might not be too expensive to get the class scoping correct/as expected. Won't change this until after 1.0 is out though.

Show
Jason Dillon added a comment - I've looked into this a lot more over the past few days, and I think I can make this work, at the cost of creating new classloaders for each execution... might not be too expensive to get the class scoping correct/as expected. Won't change this until after 1.0 is out though.

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
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.