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: NPE whilst resolving transitive configurations.
Date Wed, 15 Aug 2007 16:04:51 GMT
On 8/15/07, Ross Clewley <ross.clewley@oracle.com> wrote:
>
> Hi
>
> I should also say that this is with 1.4.1. I've tried with 2.0-alpha2
> and I still get the NPE.


I can't easily browse the 1.4.1 source right now, so I've just given a
glance at the trunk, and you've found a pretty big issue:  in
ResolveEngine.java:523 we call mark evicted with a null collection of
selected module revisions, which is passed down to the EvictionData
constructor which causes the NPE. This is pretty easy to solve though
(adding a check for nullity in the constructor). Could you open an issue for
that?

Besides finding the problem in 2.x, this may also help to narrow down the
problem in 1.4. Indeed we have no unit test testing the case handled by
ResolveEngine.java:523, so it may be a cause of the NPE in 1.4 too.

Xavier

The stack this time is
>
> java.lang.NullPointerException
>         at
> org.apache.ivy.core.resolve.IvyNodeEviction$EvictionData.<init>(
> IvyNodeEviction.java:48)
>         at
> org.apache.ivy.core.resolve.IvyNodeEviction.markEvicted(
> IvyNodeEviction.java:266)
>         at
> org.apache.ivy.core.resolve.IvyNode.markEvicted(IvyNode.java:1101)
>         at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(
> ResolveEngine.java:523)
>         at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:236)
>         at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:194)
>         at org.apache.ivy.Ivy.resolve(Ivy.java:256)
>         at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:207)
>         at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:281)
>         at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java
> :105)
>         at org.apache.tools.ant.Task.perform(Task.java:348)
>         at org.apache.tools.ant.Target.execute(Target.java:357)
>         at org.apache.tools.ant.Target.performTasks(Target.java:385)
>         at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
>         at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
>         at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> DefaultExecutor.java:41)
>         at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
>         at org.apache.tools.ant.Main.runBuild(Main.java:698)
>         at org.apache.tools.ant.Main.startAnt(Main.java:199)
>         at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
>         at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
>
> However, there is a slight difference in the behaviour. With 2.0-alpha2,
> if I do the resolve a second time without cleaning the cache it works.
> If I clean the cache again and do the resolve I get the NPE again. With
> 1.4.1 I get it every time, regardless of whether the cache is clean or
> not.
>
> regards
>
> Ross
>
> Ross Clewley wrote:
> > Hi
> >
> > I need some help sorting out a NullPointerException that I'm getting
> > during resolution. The stack looks like this.
> >
> > java.lang.NullPointerException
> >        at fr.jayasoft.ivy.IvyNode.isEvicted(IvyNode.java:367)
> >        at fr.jayasoft.ivy.IvyNode.loadData(IvyNode.java:590)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1417)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1443)
> >        at fr.jayasoft.ivy.Ivy.doFetchDependencies(Ivy.java:1492)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1424)
> >        at fr.jayasoft.ivy.Ivy.doFetchDependencies(Ivy.java:1492)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1424)
> >        at fr.jayasoft.ivy.Ivy.doFetchDependencies(Ivy.java:1492)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1433)
> >        at fr.jayasoft.ivy.Ivy.doFetchDependencies(Ivy.java:1476)
> >        at fr.jayasoft.ivy.Ivy.fetchDependencies(Ivy.java:1424)
> >        at fr.jayasoft.ivy.Ivy.getDependencies(Ivy.java:1343)
> >        at fr.jayasoft.ivy.Ivy.resolve(Ivy.java:1136)
> >        at fr.jayasoft.ivy.Ivy.resolve(Ivy.java:1093)
> >        at fr.jayasoft.ivy.ant.IvyResolve.execute(IvyResolve.java:167)
> >
> > I'd like to be able to figure out a minimal testcase to reproduce this
> > so I can log a Jira issue and also hopefully work around it. The
> > trouble is I'm having problems figuring out what that minimal testcase
> > is. The problem occurs with certain sets of dependencies and can go
> > away again when those dependencies are changed, or even when the
> > dependencies are re-ordered. I'm hoping someone may be able to give me
> > some pointers about what to look at to help nail this down a bit more
> > firmly.
> >
> > The problem occurs whilst resolving transitive configurations. We have
> > a build systems comprising 170 or so modules, each of which have the
> > following configurations
> >
> >    <conf name="default"   extends="package" transitive="true"/>
> >    <conf name="compile"   extends="default" visibility="private"
> > transitive="false"/>
> >    <conf name="runtime"   extends="default" visibility="public"
> > transitive="true"/>
> >    <conf name="test"      extends="runtime"/>
> >
> > These modules declare dependencies amongst themselves or third party
> > dependencies in their own filesystem repository with Ivy files that
> > just have the default conf. Incase it's relevant the
> > defaultconfmapping used throughout is "compile->default(*);*->@(*)".
> >
> > It's when resolving the transitive runtime of test configurations that
> > the NPE occurs.
> >
> > It's difficult for me to give you a selection of the modules and their
> > dependencies that cause the problem as there would be too many. That
> > is why I want to try to understand the issue better and produce that
> > minimal testcase. Any ideas?
> >
> > thanks
> >
> > Ross
> >
> >
>
>


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

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