ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Coene <>
Subject Re: extends & buildlist on 2.3.0-rc1 ... it gets worse
Date Fri, 22 Jun 2012 21:20:00 GMT
Hi Mitch,

please open a JIRA ticket for this.

There is another blocking issue related to the extends feature (IVY-1347) that must be fixed
before the 2.3.0 final release.
This is exactly why we create RC versions and ask people if they could test it.


 From: Mitch Gitman <>
Sent: Friday, June 22, 2012 7:21 PM
Subject: Re: extends & buildlist on 2.3.0-rc1 ... it gets worse
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 <> 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 <> 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 the
>> interaction between buildlist and extends?
>> And how should I proceed regarding these problems? Should I file a bug or
>> bugs or JIRA? Does anyone know of any existing bugs on JIRA?
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message