Worked. Thanks, Maarten! I owe you a beer. P.S. Disregard the potential workaround I'd just mentioned.
On Thu, Jan 22, 2009 at 8:32 AM, Maarten Coene <[email protected]>wrote: > You could try to use the same loaderRef attribute on the taskdefs where you > load the Ivy tasks and your own tasks: > > <!-- load ivy tasks --> > <taskdef resource="org/apache/ivy/ant/antlib.xml" > uri="antlib:org.apache.ivy.ant" loaderRef="ivy.loader" > classPathRef="ivy.classpath" /> > <!-- load own tasks --> > <taskdef ... loaderRef="ivy.loader" classPathRef="yourtask.classpath" /> > > This way, you can more or less choose where you put the jars I think... > > Maarten > > > > > ----- Original Message ---- > From: Mitch Gitman <[email protected]> > To: [email protected] > Sent: Thursday, January 22, 2009 5:12:06 PM > Subject: Re: classpath issues: trying to consume Ivy API in an Ant task > > Actually, let me try restating this query as a simpler question. Has anyone > tried writing their own Ant task that consumes the Ivy API? If so, what > decisions did you make as to the classpath location of the Ivy JAR and your > task's JAR so that it would work? Thanks. > > On Wed, Jan 21, 2009 at 9:51 PM, Mitch Gitman <[email protected]> wrote: > > > I have a very, very simple Ant task that consumes the Ivy API. That is, > in > > the Java code for my Ant task, I'm using Ivy classes. One class I had > been > > trying to use was IvyAntSettings. Well, look what happened when I tried > to > > cast a reference I found in the Ant project to an actual IvyAntSettings > > object. It's the telltale sign of ClassLoader issues: you can't cast a > class > > to itself: > > BUILD FAILED > > java.lang.ClassCastException: org.apache.ivy.ant.IvyAntSettings cannot be > > cast to org.apache.ivy.ant.IvyAntSettings > > at org.myorg.ivy.IvyConsumerTask.execute(IvyConsumerTask.java:45) > > > > It just so happened I realized I didn't need an IvyAntSettings instance, > > but when I got rid of the IvyAntSettings cast, that just uncovered > another > > variation on the same ClassLoader problem: > > BUILD FAILED > > C:\...\build.xml:23: ivy.instance has been defined in a different > > classloader. Please use the same loader when defining your task, or > > redeclare your ivy:settings in this classloader > > at org.apache.ivy.ant.IvyTask.getIvyInstance(IvyTask.java:82) > > at org.apache.ivy.ant.IvyTask.prepareTask(IvyTask.java:256) > > > > Now, I can tell you what makes this problem go away, although it's a > > measure I would just as soon NOT resort to. Put ivy.jar and the JAR for > my > > Ant task in one of Ant's primordial classloading directories: > > > > - ANT_HOME/lib > > - USER_HOME/.ant/lib > > > > Here's a minimal Ant target where I'm able to reproduce my problem. In > this > > target, the Ivy JAR and my tasks JAR are in the directory templib: > > <target name="try-this"> > > <property name="ivy.settings.url" value=" > > http://localhost/ivy/myorg/ivysettings.xml"; /> > > <property name="ivy.file" location="ivy.xml" /> > > <path id="temp.myorg.tasks.classpath"> > > <fileset dir="templib" includes="*.jar" /> > > </path> > > <taskdef uri="antlib:org.apache.ivy.ant" > > resource="org/apache/ivy/ant/antlib.xml" > > classpathref="temp.myorg.tasks.classpath" /> > > <ivy:settings id="ivy.instance" url="${ivy.settings.url}" /> > > <taskdef uri="antlib:org.myorg.tasks" > > resource="org/myorg/tasks/tasks.properties" > > classpathref="temp.myorg.tasks.classpath" /> > > <mynamespace:ivyconsumer > > conf="default" > > classpathid="some.classpath" /> > > </target> > > > > I suppose I could define the Ivy settings programmatically within my Ant > > task, but I shudder at the implications of that. I'm afraid that, > suddenly, > > all use of Ivy has to go indirectly through my own Ant task, or > additional > > tasks. My question is, is there any way, short of the extreme measures > I've > > already described, to get my custom Ant task to use the same classloader > as > > was used by?: > > <ivy:settings id="ivy.instance" url="${ivy.settings.url}" /> > > > > > > > > >
