ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: <ivy:retrieve/> task in Eclipse w/ IvyDE
Date Fri, 29 Aug 2008 07:14:44 GMT
On Thu, Aug 28, 2008 at 11:53 PM, Nicolas Lalevée <
nicolas.lalevee@hibnet.org> wrote:

>
> Le 28 août 08 à 18:51, Xavier Hanin a écrit :
>
>
>  On Tue, Aug 26, 2008 at 7:30 PM, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org
>>
>>> 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.

Indeed, I see.

>
>
>  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 remember I tried to investigate this point before choosing to remove the
ant classpath contribution in IvyDE, and after an eclipse code review and
debug session, I realized that the classloader problem was tied to how this
classpath contribution is written.


>
>  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.

Neither do I.


>
>
>
>> 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.

Indeed, this may be a solution. In this case the plugin doesn't need any
access to Ivy classes, so it can just contribute it to the Ant classpath.
Being isolated from IvyDE main plugin, it shouldn't conflict with it. That
sounds like a possibly good solution.

Xavier


>
> I will take some further look to that class loader things.
>
> Nicolas
>
>
>
>
>>
>> Xavier
>>
>>
>>
>>> Nicolas
>>>
>>>
>>>
>>>
>>>
>>>> -Andy
>>>>
>>>>
>>>> BUILD FAILED
>>>> /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:
>>>>
>>>> http://www.nabble.com/%3Civy%3Aretrieve-%3E-task-in-Eclipse-w--IvyDE-tp19156149p19156149.html
>>>> Sent from the ivy-user mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Xavier Hanin - Independent Java Consultant
>> http://xhab.blogspot.com/
>> http://ant.apache.org/ivy/
>> http://www.xoocode.org/
>>
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message