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 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" > >
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" 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 > > To: Ant Developers List > > 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 > > 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
Re: Fwd: extends & buildlist on 2.3.0-rc1 ... it gets worse
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" 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
> To: Ant Developers List
> 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
> 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 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:
> >>
> >>
> >> >> revision="${version}"
> >>
> >> location="../bootstrap-parent/ivy.xml" />
> >>
> >>
> >>
> >>
> >>
> >> 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 exte
Re: Fwd: extends & buildlist on 2.3.0-rc1 ... it gets worse
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
To: Ant Developers List
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
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 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:
>>
>>
>> > revision="${version}"
>>
>> location="../bootstrap-parent/ivy.xml" />
>>
>>
>>
>>
>>
>> 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 ju
