ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Clewley <ross.clew...@oracle.com>
Subject Re: NPE whilst resolving transitive configurations.
Date Wed, 15 Aug 2007 19:01:13 GMT
Hi Xavier

Thanks for taking a look. I've logged IVY-590.

thanks

Ross

Xavier Hanin wrote:
> 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
>>>
>>>
>>>       
>>     
>
>
>   


Mime
View raw message