Dependencies with invalid paths are not removed from library when resolving

google-code-export / ivyidea

Automatically exported from code.google.com/p/ivyidea

1 stars 0 forks source link

Dependencies with invalid paths are not removed from library when resolving #78

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. load a project which has been resolved by someone with a different Ivy cache 
location.  The IvyIDEA libraries contain entries for the dependencies pointing 
to non-existent paths.  The files and library will be marked red to show they 
are invalid.
2. resolve

What is the expected output? What do you see instead?
I expect the library to contain the dependencies with valid paths.  The library 
actually contains all the dependencies with valid paths (pointing to my cache) 
and duplicate entries for all dependencies pointing to the original (invalid) 
paths.  The library is still highlighted in red because it contains invalid 
paths.

What version of the product are you using? On what operating system?
0.9 beta4, Mac OS X

Please provide any additional information below.

Original issue reported on code.google.com by cjk...@gmail.com on 6 May 2011 at 10:23

GoogleCodeExporter commented 9 years ago

This patch removes any existing dependencies from the IvyIDEA libraries at the 
start of the resolution process.  I think this should also fix issue 75.

Original comment by cjk...@gmail.com on 9 Jun 2011 at 9:13

Attachments:

remove_all_dependencies.patch

GoogleCodeExporter commented 9 years ago

This should be fixed now in SVN, could you give it a try?

Original comment by maarten....@gmail.com on 28 Jul 2011 at 6:33

Changed state: Fixed

GoogleCodeExporter commented 9 years ago

Unfortunately the problem is still there.  To reproduce:

close a project in IDEA
edit the .iml file - change the path of a jar in the IvyIDEA library to point 
to a directory that doesn't exist
open the project in IDEA - the library and the jar in the library are marked red
resolve the module

After resolving the library is still red and the jar file in the non-existant 
location is still in the library.  A new entry has been added for the jar in 
its correct location but the old entry isn't removed.

Original comment by cjk...@gmail.com on 31 Jul 2011 at 7:32

GoogleCodeExporter commented 9 years ago

Thanks for the feedback, I have committed another change in SVN that should fix 
this issue. Could you please verify if this is also the case in your 
environment?

Original comment by maarten....@gmail.com on 2 Aug 2011 at 7:20

GoogleCodeExporter commented 9 years ago

I've tried to test it with the latest code from SVN and got an NPE:

java.lang.NullPointerException
    at org.clarent.ivyidea.intellij.ui.IvyIdeaProjectSettingsComponent.wireIvySettingsTextbox(IvyIdeaProjectSettingsComponent.java:107)
    at org.clarent.ivyidea.intellij.ui.IvyIdeaProjectSettingsComponent.<init>(IvyIdeaProjectSettingsComponent.java:93)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

Original comment by cjk...@gmail.com on 12 Aug 2011 at 1:11

GoogleCodeExporter commented 9 years ago

From the stacktrace, it looks like the corresponding .form file hadn't been 
processed when rebuilding the plugin. How did you compile the plugin?

Original comment by maarten....@gmail.com on 12 Aug 2011 at 4:03

GoogleCodeExporter commented 9 years ago

I was running it from IntelliJ.  I've just tried it on a different machine and 
it worked.  The bug is also fixed.  Brilliant.

Original comment by cjk...@gmail.com on 12 Aug 2011 at 6:17