ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: IvyDE Source Attachments?
Date Sun, 15 Nov 2009 13:49:06 GMT

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


Mime
View raw message