On 8/30/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > Should we close IVY-379 as well? I think we should because they are > probably a duplicate. > Xavier: I'll let you decide since that issue is assigned to you ;-)
I'm not sure it's really a duplicate, since I think IVY-590 only affects Ivy 2.x, while IVY-379 only affects Ivy 1.4.x and seems to have already been fixed in 2.x when I made the refactorings (and introduced IVY-590 bug :-)). What could be interesting is to see if your new unit test for IVY-590 fails in 1.4.x, and if it does see if it reproduces IVY-379 NPE. In this case we could be sure IVY-379 is fixed in 2.x. Otherwise we could also mark IVY-379 as resolved because the refactoring is very likely to have fixed this bug (as I suggested in my first comment on the issue), but with still some lack of confidence. Xavier Maarten > > ----- Original Message ---- > From: Maarten Coene (JIRA) <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 10:24:30 PM > Subject: [jira] Resolved: (IVY-590) NullPointerException whilst resolving > transitive dependencies. > > > [ > https://issues.apache.org/jira/browse/IVY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Maarten Coene resolved IVY-590. > ------------------------------- > > Resolution: Fixed > Fix Version/s: 2.0.0-beta-1 > > Added junit test and fixed the NPE by removing the for-loop from > IvyNodeEviction. > > > NullPointerException whilst resolving transitive dependencies. > > -------------------------------------------------------------- > > > > Key: IVY-590 > > URL: https://issues.apache.org/jira/browse/IVY-590 > > Project: Ivy > > Issue Type: Bug > > Affects Versions: 2.0.0-alpha-2 > > Reporter: Ross Clewley > > Assignee: Maarten Coene > > Fix For: 2.0.0-beta-1 > > > > Attachments: ivy-jira-IVY-590.patch.diff > > > > > > During a resolve of a transitive configuration we see > > 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) > > It's difficult to provide a simple testcase for this as I've only seen > it in our large modular build system and it's sensitive to things like the > order of the dependencies. > > The modules use 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" transitive="true"/> > > The error occurs when resolving the transitive test conf. > > Another factor that may or not be relevant is that none of our resolvers > have a version in the pattern. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > > > > > > > ____________________________________________________________________________________ > Be a better Heartthrob. Get better relationship answers from someone who > knows. Yahoo! Answers - Check it out. > http://answers.yahoo.com/dir/?link=list&sid=396545433 > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
