Le 4 nov. 2009 à 20:44, Stephen Haberman a écrit : > > > > Craig Setera-3 wrote: >> >> So, I've no idea why this wouldn't work. It certainly *seems* like it >> should work. Any other pointers would be greatly appreciated. >> > > I just had some fun--so, I had a jar that wasn't having its source attached, > couldn't figure it out. Checked out the IvyDE source, the > IvyContainerClasspathMapper code looked very sensible. Of course, trunk is > different than the release version I was running, so I decide to try trunk. > Build the feature dev zip, installed it. > > Still didn't work. Using the IvyDE Eclipse project, I did Debug As Eclipse, > open up my project in its workspace, and it works. Wtf. Technically I was > using a PDK Eclipse install for the IvyDE project, and a plain Java Eclipse > install for my project, but that shouldn't matter. > > After some adventures, I got it to work in my plain Java Eclipse install by > just deleting and recreating my workspace. Then it worked the first time. No > idea what cruft was in my old workspace keeping it from working. I > downgraded to the release version and it is continuing to work just fine.
I happens to me some times, I find it really annoying too... I suspect some Ivy cache that are not managed correctly in IvyDE but I never been able to find a reproducible use case. > > Before getting it to work, I had cleared the resolution cache and > re-downloaded the artifacts from the repo. That didn't fix it. Admittedly, I > did not try the "clean cache > all" button, nor the individual "every > repository" cache or "default-cache"--no real idea what those are anyway (an > explanation would be nice). > > For what its worth, while running trunk, I ran into a few stacktraces. > > The first seemed to be because I was use a workspace-level ivy settings > file: > > java.lang.NullPointerException > at > org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:137) > at > org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:86) > at > org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:580) > at > org.apache.ivyde.eclipse.cpcontainer.IvySettingsSetup.getResolvedIvySettingsPath(IvySettingsSetup.java:62) > at > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:212) > at > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.doGetIvy(IvyClasspathContainerState.java:183) > at > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:135) > at > org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:69) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > > The setting was originally an absolute file (since that is all the released > version supports). I tried a workspace file and got this stack trace: > > Java Model Exception: Java Model Status [common-build does not exist] > at > org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492) > at > org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:2062) > at > org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1820) > at > org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1842) > at > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathUtil.getIvyClasspathContainers(IvyClasspathUtil.java:122) > at > org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.resourceChanged(IvyFileResourceListener.java:70) > at > org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.visit(IvyFileResourceListener.java:52) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79) > at > org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48) > at > org.apache.ivyde.common.ivyfile.IvyFileResourceListener.resourceChanged(IvyFileResourceListener.java:89) > at > org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) > at > org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) > at > org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) > at > org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:297) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:136) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > > Even though I did have our "common-build" project open in the workspace. > > After I removed the workspace-level ivy settings file and used a > project-level ivy settings file, these stack traces seemed to go away. > > These may be known issues with trunk, but I just thought I'd pass along my > experience. Thanks for sharing, you might have discover a bug in trunk regrading the eclipse variable handling I recently introduced. Could you open a bug please ? Nicolas
