ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: <ivy:retrieve/> task in Eclipse w/ IvyDE
Date Thu, 28 Aug 2008 21:53:25 GMT

Le 28 août 08 à 18:51, Xavier Hanin a écrit :

> On Tue, Aug 26, 2008 at 7:30 PM, Nicolas Lalevée <
>> wrote:
>> Le 26 août 08 à 07:50, akpraha a écrit :
>>> Hi,
>>> I'm pretty much fed up with Maven and wanted to give Ivy a try.   
>>> I've
>>> installed IvyDE/Ivy into Eclipse 3.4, and after a bit of  
>>> configuration
>>> have
>>> got it using my local maven repo instead of the public - so far,  
>>> so good.
>>> However, when I try to run my ant build from within Eclipse, I get  
>>> the
>>> following error that the jar file containing the task cannot be  
>>> found. I
>>> would expect that Ivy's osgi bundle should be able to contribute a  
>>> task to
>>> Eclipse's built-in ant, however it does not appear to do so.  I've  
>>> seen
>>> various bits of advice to copy ivy.jar to the ant plugin's lib  
>>> directory,
>>> or
>>> to add it to the Ant classpath in eclipse preferences -- BUT, I  
>>> really
>>> don't
>>> want to manually maintain the version of Ivy used, esp. when it's  
>>> already
>>> being installed automatically by the IvyDE plugin.
>>> Any thoughts on this?
>> This is an interesting idea.
>> The ant classpath contribution was done via the IvyDE plugin when  
>> it was
>> packaged with Ivy included. Since Ivy was packaged as a standalone  
>> OSGi
>> bundle, it was not possible anymore for the IvyDE plugin to  
>> contribute to
>> the ant classpath. So to avoid classpath issues, the solution was  
>> taken to
>> remove that contribution and let the user handle manually.
>> Now that you are raising your troubles, I think there can be a  
>> solution:
>> make the ivy bundle itself contribute to the ant classpath of  
>> Eclipse.
>> Basically it is just about a plugin.xml and an optional dependency on
>> org.eclipse.ant.core. There is actually one blocker issue: the ivy  
>> packaging
>> have to change to be a jar in a jar.
>> I don't know what would be the impact of a such change. This might  
>> deserve
>> a jira entry if you are willing to.
> I don't think having Ivy itself provide a plugin.xml requires to  
> have it a
> jar in a jar, I think an eclipse plugin can provide its classes in the
> plugin jar, it's not required to be a jar in a jar.

To contribute to the ant classpath, it does. the eclipse ant extension  
point needs a reference to jar included in the bundle that contributes  
it, so there should be a jar in a bundle/jar.

> That being said, this
> contribution was painful due to classloading issues, which required  
> to make
> sure that contributed Ant classes were not part of the plugin  
> contributing
> the Ant classpath entry. Hence we needed to have to distribution of  
> Ivy:
> ivy-core.jar, containing everything but ant related classes, and  
> ivy.jar
> with everything included.

I have done some little tests, it seems to work, but I ran it in a  
very special environment: in debug, with an opened Ivy project  
containing an ivy.jar. And looking at the extension point description,  
effectively something weird is going on with the class loaders:

Description: Allows plug-ins to define arbitrary JARs for use by the  
Ant infrastructure. These JARs are put into the Ant classpath at  
runtime. Besides the JAR, the plug-in classloader of the plug-in  
providing the JAR is also added to the classpath.

> I'm not in favor of reverting to this state just
> to let eclipse users avoid configuring their eclipse Ant classpath  
> manually.

I am not either. And I am not a fan either of changing the packaging  
of Ivy into a jar of a jar.

> But if eclipse improve the classpath contribution issues, I'd be ok  
> to add a
> plugin.xml in Ivy itself.

maybe another solution is to have a third plugin, a plugin dedicated  
to the ant classpath contribution which would only contain an ivy.jar  
and a plugin.xml.

I will take some further look to that class loader things.


> Xavier
>> Nicolas
>>> -Andy
>>> /home/andy/projects/www/TournamentWeb/build/build.xml:19: Problem:  
>>> failed
>>> to
>>> create task or type antlib:org.apache.ivy.ant:retrieve
>>> Cause: The name is undefined.
>>> Action: Check the spelling.
>>> Action: Check that any custom tasks/types have been declared.
>>> Action: Check that any <presetdef>/<macrodef> declarations have 

>>> taken
>>> place.
>>> This appears to be an antlib declaration.
>>> Action: Check that the implementing library exists in one of:
>>> -/opt/eclipse/eclipse-3.4/plugins/ 
>>> org.apache.ant_1.7.0.v200803061910/lib
>>>      -/home/andy/.ant/lib
>>>      -a directory added on the command line with the -lib argument
>>> --
>>> View this message in context:
>>> Sent from the ivy-user mailing list archive at
> -- 
> Xavier Hanin - Independent Java Consultant

View raw message