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.
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.
- Stephen
--
View this message in context:
http://old.nabble.com/IvyDE-Source-Attachments--tp26129568p26203374.html
Sent from the ivy-user mailing list archive at Nabble.com.
