Re: controlling ClassLoader when programmatically invoking Ant
Right, what you describe falls under the #1 option I'd mentioned: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. Considering that the code in question consists of JUnit tests that I WANT to run from within an IDE and that I NEED to run from Ant, together with producing the customary reports, this could get complicated pretty fast. Right now, I'm pursuing my option #3, the complications for which are: * Creating a URLClassLoader that uses a scaled-down analog to the Launcher URLClassLoader. * Deploying a JAR containing nothing but the custom BuildListener and BuildLogger to Ant lib. * Accessing the Project and custom BuildListener and BuildLogger using strictly reflection in the Ant test runner code. On Sun, Jul 22, 2012 at 5:27 AM, Vimil Saju vimils...@yahoo.com wrote: So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I think to prevent class-cast issue, you should first create a class with just a static main method, then use the parentless class loader to create an instance of this class and invoke its main method through reflection. All the ant related code should be then written in then main method of the class that you created. The reason you are getting the class-cast exception is because you are creating the Project object using say classloaderA and then trying to access that object from a class that was loaded from another classloader. From: Mitch Gitman mgit...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Saturday, July 21, 2012 6:16 PM Subject: Re: controlling ClassLoader when programmatically invoking Ant Quick update for anyone who's curious. I'd forgotten that I'd asked much the same question on the ant-user list back on May 31. This was back when the contamination of the child classpath with the parent classpath was literally causing the tests to fail. And same as with this thread, Nicolas L. was kind enough to respond. See thread, example of correctly consuming an Ant project programmatically. What's funny (and sad in a way) is that today I went down much the same path I had laid in the earlier thread without even recollecting that thread. Here's what I wrote earlier: *** The one way I may have to tweak this ... is to do: new URLClassLoader(jars, null); Passing null for the extra ClassLoader argument obviates the possibility of the parent classloader creeping in. *** So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I also tried just calling Project.setCoreLoader() with this URLClassLoader, but that didn't change the way the Ivy JAR and such were being loaded. At this point, I can think of a few ways to address this problem: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. 2. Run the Launcher class with the sandboxed ClassLoader and have a build listener and build logger write the messages and out/err to the filesystem. Then to do the assertions, read the files after the fact. 3. Obtain an Object instance rather than a Project instance and use reflection to call the few methods I have to call on it. #1 scares me! #2 is defeating much of the purpose of doing all this programmatically. #3 ain't pretty, but so far it seems doable.
Re: controlling ClassLoader when programmatically invoking Ant
Nicolas, thanks. I was one class off. I was looking at Main and AntMain
when I should have been looking at Launcher. Seeing the type names and the
main method threw me off. And this corroborates my brief follow-up that I
could be doing something with URLClassLoader. Better for me to try to
leverage Launcher though than reinvent that wheel.
Let me see how far I get with that.
I do have to take issue with the one point you make: But If I were you, I
wouldn't bother trying to mimic Ant classloading in a unit test. The
important thing is to be sure that you run against the expected version of
Ant and Ivy.
First, this is not a unit test. It's an integration test or a functional
test, and if it doesn't emulate the real-life behavior in the wild, then
what use is it?
Even if we are treating this as a unit test, you can't really say that
inadvertently picking up everything in the parent ClassLoader is the
equivalent of mocking or stubbing services and components as one normally
does when creating pure unit tests. Consider that there could be a ton of
classes in the IDE's ClassLoader that have nothing whatsoever to do with
the Ant Project being executed.
And this brings me to my last concern. I have already encountered a problem
where some static functionality in some superfluous classes in the
IDE-inherited ClassLoader was causing the JUnit-invoked Project build to
fail.
Even so, to my mind, the uncontrolled success I'm seeing now is no less
troubling than the uncontrolled failure I was seeing then. If you're a
biologist conducting an experiment, you don't want to find out your
cultures were growing only because the Petri dish got contaminated.
On Sat, Jul 21, 2012 at 6:10 AM, Nicolas Lalevée nicolas.lale...@hibnet.org
wrote:
Hi Mitch,
Le 21 juil. 2012 à 07:37, Mitch Gitman a écrit :
Technically, this message is better suited for the ant-user list, but I'm
thinking I'm more apt to get an answer on this list. (I'm also thinking
this is the better place for me to cash in some chits for my having
submitted patches for three Ivy issues I mentioned recently on this list.
Subject: extends and buildlist on 2.3.0-rc1)
I am intended to give it a look very soon, I have seen all the activity
you have done, I don't want to waste it :)
Here's my problem. I'm trying to do a JUnit test of some Ivy
functionality
(actually, relating to the aforementioned Ivy bugs) by programmatically
creating and executing an Ant Project object. Everything runs just fine.
I'm able to execute targets and even tie in a BuildListener and a
BuildLogger to tap into output and error and check if the build failed.
The problem is, everything works a little too well. Take a look at the
following example build.xml:
project xmlns:ivy=antlib:org.apache.ivy.ant name=resolve-test
default=build
target name=build
ivy:settings file=ivysettings.xml /
ivy:resolve ... /
/target
/project
I've abbreviated the ivy:resolve call, but take it from me that
everything
works, including running the test directly from within an IDE. It
shouldn't. Nowhere am I specifying the classpath containing the JAR for
Ivy
itself. Nowhere am I even doing the taskdef for Ivy.
In fact, just by writing xmlns:ivy=antlib:org.apache.ivy.ant, Ant does a
lookup for the Ivy tasks. It will look for org/apache/ivy/ant/antlib.xml in
the classpath, derived from the uri definition of the xmlns.
So I guess that in your IDE, it works since you have Ivy in your classpath.
And in fact, if I run this build.xml straight from the command line, it
fails like you would expect:
Problem: failed to create task or type antlib:org.apache.ivy.ant:settings
...
This means that the Ivy jar is neither in the Ant classpath
($ANT_HOME/lib/), nor in your ant user lib directory ($HOME/.ant/lib).
I can only think that the key method I want to take advantage of is this
in
Project:
public void setCoreLoader(ClassLoader coreLoader) {
this.coreLoader = coreLoader;
}
What's interesting is that the command-line entry point for Ant in
org.apache.tools.ant.Main ends up passing null to setCoreLoader, in which
case the parent classloader should be used, according to the method's
Javadoc. At this point, I go take a look at the scripts that launch Ant
and
my eyes get blurry. But I believe what I want to do is manually
construct a
ClassLoader as if I were running java -cp ... with the contents of
Ant's
lib directory. (I'm showing my ignorance of ClassLoaders here, I
realize.)
Perhaps someone can point me to an elegant way to accomplish that.
On the command line, the jvm is given only the ant-launcher.jar, it will
be the content of the system classloader.
Then in org.apache.tools.ant.launch.Launcher.run(String[]), we can see the
ant Main class is loaded and launched with this classloader:
new URLClassLoader(jars, Launcher.class.getClassLoader());
The system is the parent, the jars
Re: controlling ClassLoader when programmatically invoking Ant
Quick update for anyone who's curious. I'd forgotten that I'd asked much the same question on the ant-user list back on May 31. This was back when the contamination of the child classpath with the parent classpath was literally causing the tests to fail. And same as with this thread, Nicolas L. was kind enough to respond. See thread, example of correctly consuming an Ant project programmatically. What's funny (and sad in a way) is that today I went down much the same path I had laid in the earlier thread without even recollecting that thread. Here's what I wrote earlier: *** The one way I may have to tweak this ... is to do: new URLClassLoader(jars, null); Passing null for the extra ClassLoader argument obviates the possibility of the parent classloader creeping in. *** So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I also tried just calling Project.setCoreLoader() with this URLClassLoader, but that didn't change the way the Ivy JAR and such were being loaded. At this point, I can think of a few ways to address this problem: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. 2. Run the Launcher class with the sandboxed ClassLoader and have a build listener and build logger write the messages and out/err to the filesystem. Then to do the assertions, read the files after the fact. 3. Obtain an Object instance rather than a Project instance and use reflection to call the few methods I have to call on it. #1 scares me! #2 is defeating much of the purpose of doing all this programmatically. #3 ain't pretty, but so far it seems doable. On Sat, Jul 21, 2012 at 9:33 AM, Mitch Gitman mgit...@gmail.com wrote: Nicolas, thanks. I was one class off. I was looking at Main and AntMain when I should have been looking at Launcher. Seeing the type names and the main method threw me off. And this corroborates my brief follow-up that I could be doing something with URLClassLoader. Better for me to try to leverage Launcher though than reinvent that wheel. Let me see how far I get with that. I do have to take issue with the one point you make: But If I were you, I wouldn't bother trying to mimic Ant classloading in a unit test. The important thing is to be sure that you run against the expected version of Ant and Ivy. First, this is not a unit test. It's an integration test or a functional test, and if it doesn't emulate the real-life behavior in the wild, then what use is it? Even if we are treating this as a unit test, you can't really say that inadvertently picking up everything in the parent ClassLoader is the equivalent of mocking or stubbing services and components as one normally does when creating pure unit tests. Consider that there could be a ton of classes in the IDE's ClassLoader that have nothing whatsoever to do with the Ant Project being executed. And this brings me to my last concern. I have already encountered a problem where some static functionality in some superfluous classes in the IDE-inherited ClassLoader was causing the JUnit-invoked Project build to fail. Even so, to my mind, the uncontrolled success I'm seeing now is no less troubling than the uncontrolled failure I was seeing then. If you're a biologist conducting an experiment, you don't want to find out your cultures were growing only because the Petri dish got contaminated. On Sat, Jul 21, 2012 at 6:10 AM, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: Hi Mitch, Le 21 juil. 2012 à 07:37, Mitch Gitman a écrit : Technically, this message is better suited for the ant-user list, but I'm thinking I'm more apt to get an answer on this list. (I'm also thinking this is the better place for me to cash in some chits for my having submitted patches for three Ivy issues I mentioned recently on this list. Subject: extends and buildlist on 2.3.0-rc1) I am intended to give it a look very soon, I have seen all the activity you have done, I don't want to waste it :) Here's my problem. I'm trying to do a JUnit test of some Ivy functionality (actually, relating to the aforementioned Ivy bugs) by programmatically creating and executing an Ant Project object. Everything runs just fine. I'm able to execute targets and even tie in a BuildListener and a BuildLogger to tap into output and error and check if the build failed. The problem is, everything works a little too well. Take a look at the following example build.xml: project xmlns:ivy=antlib:org.apache.ivy.ant name=resolve-test default=build target name=build ivy:settings file=ivysettings.xml / ivy:resolve ... / /target
controlling ClassLoader when programmatically invoking Ant
Technically, this message is better suited for the ant-user list, but I'm
thinking I'm more apt to get an answer on this list. (I'm also thinking
this is the better place for me to cash in some chits for my having
submitted patches for three Ivy issues I mentioned recently on this list.
Subject: extends and buildlist on 2.3.0-rc1)
Here's my problem. I'm trying to do a JUnit test of some Ivy functionality
(actually, relating to the aforementioned Ivy bugs) by programmatically
creating and executing an Ant Project object. Everything runs just fine.
I'm able to execute targets and even tie in a BuildListener and a
BuildLogger to tap into output and error and check if the build failed.
The problem is, everything works a little too well. Take a look at the
following example build.xml:
project xmlns:ivy=antlib:org.apache.ivy.ant name=resolve-test
default=build
target name=build
ivy:settings file=ivysettings.xml /
ivy:resolve ... /
/target
/project
I've abbreviated the ivy:resolve call, but take it from me that everything
works, including running the test directly from within an IDE. It
shouldn't. Nowhere am I specifying the classpath containing the JAR for Ivy
itself. Nowhere am I even doing the taskdef for Ivy.
And in fact, if I run this build.xml straight from the command line, it
fails like you would expect:
Problem: failed to create task or type antlib:org.apache.ivy.ant:settings
...
I can only think that the key method I want to take advantage of is this in
Project:
public void setCoreLoader(ClassLoader coreLoader) {
this.coreLoader = coreLoader;
}
What's interesting is that the command-line entry point for Ant in
org.apache.tools.ant.Main ends up passing null to setCoreLoader, in which
case the parent classloader should be used, according to the method's
Javadoc. At this point, I go take a look at the scripts that launch Ant and
my eyes get blurry. But I believe what I want to do is manually construct a
ClassLoader as if I were running java -cp ... with the contents of Ant's
lib directory. (I'm showing my ignorance of ClassLoaders here, I realize.)
Perhaps someone can point me to an elegant way to accomplish that.
If someone's going to say, Hey, check what antunit does, I'd appreciate
if you could pinpoint what it's doing.
P.S. Perhaps somebody has a rational explanation too for why the taskdef of
Ivy is creeping in.
Re: controlling ClassLoader when programmatically invoking Ant
P.S. I'm going to give URLClassLoader a shot with the JARs in Ant lib:
http://docs.oracle.com/javase/6/docs/api/java/net/URLClassLoader.html
Almost sounds a little too easy...
On Fri, Jul 20, 2012 at 10:37 PM, Mitch Gitman mgit...@gmail.com wrote:
Technically, this message is better suited for the ant-user list, but I'm
thinking I'm more apt to get an answer on this list. (I'm also thinking
this is the better place for me to cash in some chits for my having
submitted patches for three Ivy issues I mentioned recently on this list.
Subject: extends and buildlist on 2.3.0-rc1)
Here's my problem. I'm trying to do a JUnit test of some Ivy functionality
(actually, relating to the aforementioned Ivy bugs) by programmatically
creating and executing an Ant Project object. Everything runs just fine.
I'm able to execute targets and even tie in a BuildListener and a
BuildLogger to tap into output and error and check if the build failed.
The problem is, everything works a little too well. Take a look at the
following example build.xml:
project xmlns:ivy=antlib:org.apache.ivy.ant name=resolve-test
default=build
target name=build
ivy:settings file=ivysettings.xml /
ivy:resolve ... /
/target
/project
I've abbreviated the ivy:resolve call, but take it from me that everything
works, including running the test directly from within an IDE. It
shouldn't. Nowhere am I specifying the classpath containing the JAR for Ivy
itself. Nowhere am I even doing the taskdef for Ivy.
And in fact, if I run this build.xml straight from the command line, it
fails like you would expect:
Problem: failed to create task or type antlib:org.apache.ivy.ant:settings
...
I can only think that the key method I want to take advantage of is this
in Project:
public void setCoreLoader(ClassLoader coreLoader) {
this.coreLoader = coreLoader;
}
What's interesting is that the command-line entry point for Ant in
org.apache.tools.ant.Main ends up passing null to setCoreLoader, in which
case the parent classloader should be used, according to the method's
Javadoc. At this point, I go take a look at the scripts that launch Ant and
my eyes get blurry. But I believe what I want to do is manually construct a
ClassLoader as if I were running java -cp ... with the contents of Ant's
lib directory. (I'm showing my ignorance of ClassLoaders here, I realize.)
Perhaps someone can point me to an elegant way to accomplish that.
If someone's going to say, Hey, check what antunit does, I'd appreciate
if you could pinpoint what it's doing.
P.S. Perhaps somebody has a rational explanation too for why the taskdef
of Ivy is creeping in.
Re: Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse
I've created a JIRA issue with an attached test case for this buildlist with two parents problem: https://issues.apache.org/jira/browse/IVY-1363 title: ivy:buildlist task confused by extends feature using two parents It's going to be three weeks until I'd be able to try working on a patch myself for this. I'm hoping Jean-Louis or someone else might be interested in taking this on in the meantime. I'm also noticing a broader theme of instability surrounding the extends/parent feature. I mention here that earlier I'd started another ivy-user thread buildlist task chokes on absolute path to parent Ivy module concerning Ivy 2.2.0. It appeared that this problem went away in Ivy 2.3.0-rc1. However, after I cleared out my Ivy cache and ran ivy:buildlist, I found it inexplicably failing on an absolute path to a parent in a single Ivy module: java.text.ParseException: Problem occurred while parsing ivy file: null in file: … … Caused by: java.lang.NullPointerException at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parseOtherIvyFile(XmlModuleDescriptorParser.java:659) at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.extendsStarted(XmlModuleDescriptorParser.java:443) at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:327) ... 48 more And believe me, the file is there. And strangely, as I suggest above, this failure only shows up after clearing out the Ivy cache. I'm going to try narrowing down and isolating this problem. It's odd that I should have to convert only one ivy.xml's extends@location value to a relative path. Plus, it's worth noting that I came across another JIRA issue (reported by someone else) involving buildlist not working as expected with extends: https://issues.apache.org/jira/browse/IVY-1345 title: ivy:buildlist does not order properly modules that extend module with revision not matching dependencies And just with the extends/parent feature (without buildlist getting involved), I encountered another problem that I reported yesterday in JIRA: https://issues.apache.org/jira/browse/IVY-1359 ivy.xml extends feature complains about Windows filesystem path On Tue, Jun 26, 2012 at 2:00 PM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: I can try to spend some time on it but i need a reproducable use case. Opening a JIRA and attaching a test case could save hours. Le 22 juin 2012 23:24, Maarten Coene maarten_co...@yahoo.com a écrit : Hi Mitch, I've just replied on the ivy-user mailing list. I think this issue should get fixed before the 2.3.0 final release. Could you at least create a JIRA issue for this bug. Attaching a test case would be really helpfull. (attaching a patch that fixes the problem would be even more helpfull :-) ) I don't have time right now to look at it though. I hope to have a bit more time in july/august... Maarten From: Mitch Gitman mgit...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Friday, June 22, 2012 7:53 PM Subject: Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse I'm forwarding this thread I started on the ivy-user list. Can someone advise me how to handle this? Should I file a JIRA issue? Is someone aware if there's a JIRA issue already for this problem? For that matter, has anyone else noticed Ivy buildlist and extends not being able to coexist? Once we've established that there's a JIRA issue with a reproducible use case, what's the best way to ensure it gets addressed? Would someone like Maarten want to tackle this, or should I? My fear is that, if I tackle it, the fix is not going to find its way into the code base. Well, my bigger fear is that Ivy 2.3.0 is going to be released without this problem being addressed. -- Forwarded message -- From: Mitch Gitman mgit...@gmail.com Date: Fri, Jun 22, 2012 at 10:21 AM Subject: Re: extends buildlist on 2.3.0-rc1 ... it gets worse To: ivy-u...@ant.apache.org OK, I stripped away all use of the extends feature, and sure enough, buildlist produced a normal, expected, non-randomized project build order. This indicates that something that had been working in Ivy 2.2.0 is no longer working in Ivy 2.3.0-rc1. Considering that: A. The buildlist task is a prerequisite for being productive with Ivy.* B. The extends feature is a prerequisite for being productive with Ivy.* The apparent fact that these two features are now mutually exclusive with Ivy 2.3.0-rc1 (where they weren't with Ivy 2.2.0) represents a serious bug. I think my next step is to forward this thread to the ant-dev list and ask how to proceed. * For those who wish to say, Mitch, we've been able to get by just fine without (buildlist|extends), I'm perfectly happy to have that discussion, but my primary concern now
Re: Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse
I was readily able to reproduce the problem broached below where ivy:buildlist fails on an absolute path to the parent Ivy module. I created this JIRA issue: https://issues.apache.org/jira/browse/IVY-1364 title: buildlist task chokes on absolute path to parent Ivy module I've attached to the issue an isolated, simple test case, including a control group test case where a relative path works. As serious as the buildlist two parents problem is, I think this one presents a more prominent obstacle. On Wed, Jun 27, 2012 at 5:13 PM, Mitch Gitman mgit...@gmail.com wrote: I've created a JIRA issue with an attached test case for this buildlist with two parents problem: https://issues.apache.org/jira/browse/IVY-1363 title: ivy:buildlist task confused by extends feature using two parents It's going to be three weeks until I'd be able to try working on a patch myself for this. I'm hoping Jean-Louis or someone else might be interested in taking this on in the meantime. I'm also noticing a broader theme of instability surrounding the extends/parent feature. I mention here that earlier I'd started another ivy-user thread buildlist task chokes on absolute path to parent Ivy module concerning Ivy 2.2.0. It appeared that this problem went away in Ivy 2.3.0-rc1. However, after I cleared out my Ivy cache and ran ivy:buildlist, I found it inexplicably failing on an absolute path to a parent in a single Ivy module: java.text.ParseException: Problem occurred while parsing ivy file: null in file: … … Caused by: java.lang.NullPointerException at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parseOtherIvyFile(XmlModuleDescriptorParser.java:659) at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.extendsStarted(XmlModuleDescriptorParser.java:443) at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:327) ... 48 more And believe me, the file is there. And strangely, as I suggest above, this failure only shows up after clearing out the Ivy cache. I'm going to try narrowing down and isolating this problem. It's odd that I should have to convert only one ivy.xml's extends@location value to a relative path. Plus, it's worth noting that I came across another JIRA issue (reported by someone else) involving buildlist not working as expected with extends: https://issues.apache.org/jira/browse/IVY-1345 title: ivy:buildlist does not order properly modules that extend module with revision not matching dependencies And just with the extends/parent feature (without buildlist getting involved), I encountered another problem that I reported yesterday in JIRA: https://issues.apache.org/jira/browse/IVY-1359 ivy.xml extends feature complains about Windows filesystem path
Fwd: extends buildlist on 2.3.0-rc1 ... it gets worse
I'm forwarding this thread I started on the ivy-user list.
Can someone advise me how to handle this? Should I file a JIRA issue? Is
someone aware if there's a JIRA issue already for this problem? For that
matter, has anyone else noticed Ivy buildlist and extends not being able to
coexist?
Once we've established that there's a JIRA issue with a reproducible use
case, what's the best way to ensure it gets addressed? Would someone like
Maarten want to tackle this, or should I? My fear is that, if I tackle it,
the fix is not going to find its way into the code base.
Well, my bigger fear is that Ivy 2.3.0 is going to be released without this
problem being addressed.
-- Forwarded message --
From: Mitch Gitman mgit...@gmail.com
Date: Fri, Jun 22, 2012 at 10:21 AM
Subject: Re: extends buildlist on 2.3.0-rc1 ... it gets worse
To: ivy-u...@ant.apache.org
OK, I stripped away all use of the extends feature, and sure enough,
buildlist produced a normal, expected, non-randomized project build order.
This indicates that something that had been working in Ivy 2.2.0 is no
longer working in Ivy 2.3.0-rc1.
Considering that:
A. The buildlist task is a prerequisite for being productive with Ivy.*
B. The extends feature is a prerequisite for being productive with Ivy.*
The apparent fact that these two features are now mutually exclusive with
Ivy 2.3.0-rc1 (where they weren't with Ivy 2.2.0) represents a serious bug.
I think my next step is to forward this thread to the ant-dev list and ask
how to proceed.
* For those who wish to say, Mitch, we've been able to get by just fine
without (buildlist|extends), I'm perfectly happy to have that discussion,
but my primary concern now is facilitating a fix.
On Thu, Jun 21, 2012 at 10:12 PM, Mitch Gitman mgit...@gmail.com wrote:
One other data point. As long as my undesired simplification wasn't
helping things, I went back to both a bootstrap-parent and a master-parent.
I also tried setting haltOnError=false on ivy:buildlist. With that, the
task successfully got through everything. However, it continued to create a
seriously trashed build order.
Just as an experiment, I might try converting all the ivy.xml files to not
use the extends feature and then see what happens when running buildlist.
My hypothesis is, this will work. Not that this is a desired state of
affairs, but at least it isolates the problem to the interaction between
buildlist and extends.
On Thu, Jun 21, 2012 at 9:23 PM, Mitch Gitman mgit...@gmail.com wrote:
Over a week ago, I'd sent out a message to this list, buildlist task
chokes on absolute path to parent Ivy module. I'd found that the extends
feature worked fine with an absolute path to the parent ivy.xml if I was
building any single Ivy module, but the buildlist task would fail to find
the absolute path.
I'd noted that I'd been using Ivy 2.2.0. Now that I've upgraded to Ivy
2.3.0-rc1, my problems have only gotten worse. The first problem I
encountered had nothing to do with absolute paths to parents. I'm still
using relative paths to parents. Instead, it arose from my using two
different parent Ivy modules: bootstrap-parent and master-parent. Some
projects extended the former; others the latter. For example:
info organisation=foo module=homeowner revision=${version}
extends organisation=foo module=bootstrap-parent
revision=${version}
location=../bootstrap-parent/ivy.xml /
/info
But then when I pointed the ivy:buildlist Ant task at a project stack
that included a mix of both parents and their children, I saw this error:
impossible to parse ivy file for …/foo-client/homeowner/build.xml:
ivyfile=.../foo-client/homeowner/ivy.xml
exception=java.text.ParseException: Problem occurred while parsing ivy
file: inconsistent module descriptor file found in
'file:/.../master-parent/ivy.xml': bad module name:
expected='bootstrap-parent' found='master-parent'; in
file:/.../foo-client/homeowner/ivy.xml
What's happening is, the homeowner module extends bootstrap-parent, but
somehow the relative path to master-parent/ivy.xml is supplanting the
relative path to bootstrap-parent/ivy.xml. It appears buildlist doesn't
know how to deal with more than one parent, even though there's no
interaction between the two parents.
After this, even though I didn't really want to, I thought, Why not make
things simple for buildlist and use just one parent, master-parent?
Here's where things really got wild. With Ivy 2.2.0, buildlist worked
just fine, provided I gave it relative paths to the different parents. Now,
even with a relative path and even with a single parent, buildlist on
2.3.0-rc1 goes nuts. I go so far as to introduce a buildlist Ivy conf to
force project A to sort before project B. How does buildlist on 2.3.0-rc1
interpret this? It puts B before A. (And no, I can guarantee I have no
circular dependencies.)
Can someone say, are there any integration tests that test
Re: Getting Ivy dependency tree from Ant target
Serge: I think this is the sort of question you'd best ask on the ivy-user mailing list: ivy-u...@ant.apache.org My understanding is that this particular list is for internal Ant development. That said, let me give a quick answer to your question. Suppose you have some projects: acmewebapp depends on -- acmeapplication depends on -- acmedomain You want acmewebapp to use the latest changes in acmeapplication and acmedomain. The standard way to accomplish this is to publish your latest changes in the latter projects to an Ivy repository using the ivy:publish Ant task. Then depending on how you've configured the caching for Ivy, your build for acmewebapp--using the ivy:resolve task--will pick up those latest changes. There's also an ivy:buildlist Ant task which, with certain limitations, will figure out the correct dependency chain in a suite of projects and build an entire stack in order. But typically, instead of using buildlist, you'll be relying on your CI server to pick up changes and do publishes to a shared repository. Or if you're just working locally, you'll be publishing locally yourself or relying on the IDE, for example Eclipse with the IvyDE plugin. 2010/4/7 Serge K ffok...@gmail.com I’m trying to migrate from proprietary build system to Ant/Ivy. The application has over 600 modules to build and package. Most of the modules have dependencies on other modules i.e. build of one top level module should invoke build and packaging a tree of dependent modules. Question: Is there a way to retrieve dependencies declared in Ivy config files from Ant target during the build so that Ant can rebuild dependent modules? To my understanding Ivy just fetches prebuilt versions of modules and can not be used from Ant like target name=module.aaa depends=get_dependency.bbb,dependency.bbb_from_ivy_configs javac... /target I don’t want to have duplicate declarations of the same dependencies in Ivy for packaging and then in “depends” attribute of Ant targets for build. I went over Ivy API and source code. No help. It seems I’d need to code external component that parses Ivy modules, loads dependency tree and invokes Ant to build each dependent module. Then use Ivy to fetch prebuilt modules and package them. Any suggestions? Thank you. Serge K. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
redundant dependencies--executing targets from a task
I have a custom Ant task that is invoking Ant targets like so:
theProject.getExecutor().executeTargets(theProject, new String[] {
targetName });
I want the dependencies of the invoked target to be invoked themselves, so I
don't need to specially use an *Executor *like *IgnoreDependenciesExecutor*.
But, by the same token, I *don't *want the target's dependencies to be
invoked if they've already been invoked in the course of the build that
eventually ran that custom Ant task.
So how do I get this *Executor*'s *executeTargets *to know about, and avoid,
the targets that have already been invoked up to that point?
