IvyDE
  1. IvyDE
  2. IVYDE-237

Multiple eclipse projects with similar ivy library definitions results in launch config source path collisions

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0.final
    • Fix Version/s: 2.2.0.beta1
    • Component/s: launch configuration
    • Labels:
      None
    • Environment:

      Ubuntu 8.10, Eclipse 3.5.2, IvyDE 2.0.0.final

      Description

      I have multiple eclipse projects with very similar project structures.

      Each eclipse project has an one ivy library pointing to an ivy.xml file at the root of each the project. (i.e. one ivy.xml file per project)

      The projects have various dependencies on each other, going three or four deep. (e.g. A depends on B, B depends on C, C depends on D, etc). The ivy library is exported from each project.

      I have "resolve dependencies in workspace" turned on. It works great, the build time project dependencies are resolved properly. Love this! But, I think the same thing applies if I have this turned off.

      The problem happens when creating a launch configuration. I noticed this when debugging. I created a launch configuration pointing at project A. When stepping through a debug session, eclipse could not find the sources for project D. After some further investigation, this is what I found...

      Using the default source lookup path does not include the project D. More on that later.

      So, I decided to manually configure the source path. Here's the process I followed:

      1. I started by adding project A.
      2. Upon adding A, I noticed that two entries appeared in the source lookup path

      • the project A itself
      • the ivy library of the project
        3. Now I add project B
        4. Upon adding B, I noticed that only one additional entry appeared in the source lookup path
      • the project B itself
        The ivy library of project B did not appear (even though it is exported)

      Similarly, if I add all the projects in one step, only one ivy library appears.

      So, I believe that since each of the ivy libraries are configured the same way (Essentially pointing to an identically named file in each project), that eclipse or IvyDE is getting confused and only adding one of them to the source lookup path.

      I believe the same is true if I use the default source lookup path (rather than adding projects manually). When looking at the default source lookup path, I can only see a subset of the depend-on projects. Usually, they only include the dependencies of one project, and nothing transitive.

      I tried to test this theory by renaming the ivy.xml files to ivy-$

      {projectname}.xml. This makes all of the ivy libraries unique, since the ivy xml file name is included as part of the library definition. However, now if I add multiple projects to the source lookup path, multiple ivy libraries get added, BUT if you try to expand them, you get an error message saying that the ivy-${projectname}

      .xml file doesn't exist (because it is looking for that xml file in the root of the launch config project, rather than the project from which the library is coming from.

      I can easily reproduce this behavior, so let me know if you need further information

      1. ivyde_source_lookup_5.png
        75 kB
        Phil Clay
      2. ivyde_source_lookup_4.png
        85 kB
        Phil Clay
      3. ivyde_source_lookup_3.png
        99 kB
        Phil Clay
      4. ivyde_source_lookup_2.png
        73 kB
        Phil Clay
      5. ivyde_source_lookup_1.png
        101 kB
        Phil Clay

        Activity

        Hide
        Phil Clay added a comment -

        ivyde_source_lookup_1.png is showing that I selected one project to add.
        ivyde_source_lookup_2.png is the result of adding one project.

        Notice the project was added, and the ivy library. However, the ivy library references ivy.xml, and that is resolved using the launch configuration path (dfm-server), rather than the project from which the library came (dfm-api)

        Show
        Phil Clay added a comment - ivyde_source_lookup_1.png is showing that I selected one project to add. ivyde_source_lookup_2.png is the result of adding one project. Notice the project was added, and the ivy library. However, the ivy library references ivy.xml, and that is resolved using the launch configuration path (dfm-server), rather than the project from which the library came (dfm-api)
        Hide
        Phil Clay added a comment -

        ivyde_source_lookup_3.png show the selection of multiple projects.
        ivyde_source_lookup_4.png shows the result of the selection.

        Notice that only one ivy library was added, even though every project has an exported ivy library.

        Show
        Phil Clay added a comment - ivyde_source_lookup_3.png show the selection of multiple projects. ivyde_source_lookup_4.png shows the result of the selection. Notice that only one ivy library was added, even though every project has an exported ivy library.
        Hide
        Phil Clay added a comment -

        ivyde_source_lookup_5.png shows the result of adding a project to the source lookup path after changing the ivy file names (in every project) to ivy-$

        {projectname}

        .xml.

        dfm-server is the target project for the eclipse launch configuration.

        dfm-apiserver is the project that I added to the source lookup path.

        Notice that eclipse/ivyde is incorrectly trying to resolve ivy-dfm-apiserver.xml relative to dfm-server (instead of dfm-apiserver)

        Show
        Phil Clay added a comment - ivyde_source_lookup_5.png shows the result of adding a project to the source lookup path after changing the ivy file names (in every project) to ivy-$ {projectname} .xml. dfm-server is the target project for the eclipse launch configuration. dfm-apiserver is the project that I added to the source lookup path. Notice that eclipse/ivyde is incorrectly trying to resolve ivy-dfm-apiserver.xml relative to dfm-server (instead of dfm-apiserver)
        Hide
        Nicolas Lalevée added a comment -

        Thank you for your detailed report Phil.
        I had some trouble with the launch configuration and IvyDE too. I think I have resolved most of the issues I have encountered.
        I think there some jira issue I could point you too, but I cannot find them...

        Here is the documentation about the launch configuration and IVYDE trunk:
        http://ant.apache.org/ivy/ivyde/history/trunk/cpc/launch.html

        I would be great if you could try the trunk version of IvyDE (http://ant.apache.org/ivy/ivyde/download.cgi#hudson) and see if it fixes your issues.

        Show
        Nicolas Lalevée added a comment - Thank you for your detailed report Phil. I had some trouble with the launch configuration and IvyDE too. I think I have resolved most of the issues I have encountered. I think there some jira issue I could point you too, but I cannot find them... Here is the documentation about the launch configuration and IVYDE trunk: http://ant.apache.org/ivy/ivyde/history/trunk/cpc/launch.html I would be great if you could try the trunk version of IvyDE ( http://ant.apache.org/ivy/ivyde/download.cgi#hudson ) and see if it fixes your issues.
        Hide
        Phil Clay added a comment -

        Hi Nicolas,

        I tried the latest IvyDE from trunk. 2.1.0.201003291630-hudson-102

        The default source lookup path looks better.

        However I'm still seeing weird behavior when trying to configure the source lookup path manually. I believe it is the same as I saw before.

        I believe this will reproduce it...

        1) create two projects, each with their own ivy.xml and ivy library in eclipse
        2) make sure the ivy library is exported in both projects (Project | Properties | Java Build Path | Order and Export)
        3) Create a new launch config
        4) Project = projectA (this doesn't really matter, just select one)
        On the source tab, remove the default
        Add | Java Project | select both projects (ensure "Add exported entries of selected projects" is checked)
        Click ok

        You will now see 2 projects in the source lookup path, but only one ivy library. You should see 2 projects and 2 ivy libraries.

        Let me know if you need more help reproducing it.

        Show
        Phil Clay added a comment - Hi Nicolas, I tried the latest IvyDE from trunk. 2.1.0.201003291630-hudson-102 The default source lookup path looks better. However I'm still seeing weird behavior when trying to configure the source lookup path manually. I believe it is the same as I saw before. I believe this will reproduce it... 1) create two projects, each with their own ivy.xml and ivy library in eclipse 2) make sure the ivy library is exported in both projects (Project | Properties | Java Build Path | Order and Export) 3) Create a new launch config 4) Project = projectA (this doesn't really matter, just select one) On the source tab, remove the default Add | Java Project | select both projects (ensure "Add exported entries of selected projects" is checked) Click ok You will now see 2 projects in the source lookup path, but only one ivy library. You should see 2 projects and 2 ivy libraries. Let me know if you need more help reproducing it.
        Hide
        Eric Sirianni added a comment -

        Nicolas - any progress on this? I'm having the same problem as Phil.

        Basically, this bug makes IvyDE unusable when using a launch configuration that includes more than one java project. Decomposing a java application project into multiple java project modules is one of the main best practices that led to the popularity of Ivy in the first place, so it is unfortunate that this use case does not work with IvyDE.

        Do you need any more information on this? If you need any help, care to point me to a location in the IvyDE code?

        Show
        Eric Sirianni added a comment - Nicolas - any progress on this? I'm having the same problem as Phil. Basically, this bug makes IvyDE unusable when using a launch configuration that includes more than one java project. Decomposing a java application project into multiple java project modules is one of the main best practices that led to the popularity of Ivy in the first place, so it is unfortunate that this use case does not work with IvyDE. Do you need any more information on this? If you need any help, care to point me to a location in the IvyDE code?
        Hide
        Nicolas Lalevée added a comment -

        I haven't had time look at it.
        Our source code is available from several places, you will probably be interested in checking our from subversion: http://ant.apache.org/ivy/ivyde/download.cgi#svn
        There is also some basic documentation on how to build it: http://ant.apache.org/ivy/ivyde/history/trunk/dev/build.html

        Show
        Nicolas Lalevée added a comment - I haven't had time look at it. Our source code is available from several places, you will probably be interested in checking our from subversion: http://ant.apache.org/ivy/ivyde/download.cgi#svn There is also some basic documentation on how to build it: http://ant.apache.org/ivy/ivyde/history/trunk/dev/build.html
        Hide
        Nicolas Lalevée added a comment -

        I looked today into trying to reproduce the issue, following the last scenario presented by Phil. And I see two java projects and two IvyDE library containers. Sorry to reask, but could you try with the latest build from hudson ?

        And one thing I don't understand. Ivy is taking care of resolving the dependencies transitively, so why would you want to edit the source path lookup. Normally, having project A depending via IvyDE on project B, debugging a launch configuration on A, you should be able to see the source of B. I use it every day without any worry. I don't even have to "export" the IvyDE classpath container.
        Could you try with a simpler setup ?

        Show
        Nicolas Lalevée added a comment - I looked today into trying to reproduce the issue, following the last scenario presented by Phil. And I see two java projects and two IvyDE library containers. Sorry to reask, but could you try with the latest build from hudson ? And one thing I don't understand. Ivy is taking care of resolving the dependencies transitively, so why would you want to edit the source path lookup. Normally, having project A depending via IvyDE on project B, debugging a launch configuration on A, you should be able to see the source of B. I use it every day without any worry. I don't even have to "export" the IvyDE classpath container. Could you try with a simpler setup ?
        Hide
        Eric Sirianni added a comment - - edited

        Nicolas - thanks for digging a little deeper on this.

        To answer your second question regarding the use case...
        You are correct in that normally this would not be an issue – since Ivy transitively resolves the dependencies of project A any source JAR dependencies from project B (and the source of project B itself) should automatically be available to the eclipse debugger.

        Our use case is more nuanced. We are developing a web application using an embedded Jetty server. Project A is the "container" and includes the jetty JARs and some other dependencies (apache-commons, slf4j, etc., etc.). Project B is a "webapp" and includes dependencies like hibernate, spring, etc.

        To debug this application I want a launch configuration that has the following source path:

        • Project A deps (jetty, apache-commons, slf4j, etc.)
        • Project B deps (hibernate, spring, etc.)

        This is a case where the source path is different from the classpath. Specifically, the classpath for Project A should not have hibernate on it, etc. as this needs to live "inside" the webapp (WEB-INF/libs) for Project B. So Project A does not depend on Project B from an ivy perspective. However, I'd like the "source" configurations of both Project A's ivy.xml and Project B's ivy.xml on the eclipse launch config. This is where we're hitting this bug.

        Make sense?

        Show
        Eric Sirianni added a comment - - edited Nicolas - thanks for digging a little deeper on this. To answer your second question regarding the use case... You are correct in that normally this would not be an issue – since Ivy transitively resolves the dependencies of project A any source JAR dependencies from project B (and the source of project B itself) should automatically be available to the eclipse debugger. Our use case is more nuanced. We are developing a web application using an embedded Jetty server. Project A is the "container" and includes the jetty JARs and some other dependencies (apache-commons, slf4j, etc., etc.). Project B is a "webapp" and includes dependencies like hibernate, spring, etc. To debug this application I want a launch configuration that has the following source path: Project A deps (jetty, apache-commons, slf4j, etc.) Project B deps (hibernate, spring, etc.) This is a case where the source path is different from the classpath. Specifically, the classpath for Project A should not have hibernate on it, etc. as this needs to live "inside" the webapp (WEB-INF/libs) for Project B. So Project A does not depend on Project B from an ivy perspective. However, I'd like the "source" configurations of both Project A's ivy.xml and Project B's ivy.xml on the eclipse launch config. This is where we're hitting this bug. Make sense?
        Hide
        Nicolas Lalevée added a comment -

        It makes totally sense. And I was not testing that kind of use case. I may be able to reproduce a similar scenario.

        Show
        Nicolas Lalevée added a comment - It makes totally sense. And I was not testing that kind of use case. I may be able to reproduce a similar scenario.
        Hide
        Nicolas Lalevée added a comment -

        I have setup a similar fake project:
        http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/jetty/
        http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/jetty-webapp/

        And I have been able to reproduce the issue.

        I am not sure when it happened, but I noticed some NPE in the logs, might be related. Could you check your logs to see if there is some ivyde stack trace too ?

        the stack trace I have found:

        java.lang.NullPointerException
        at org.apache.ivyde.eclipse.IvyDERuntimeClasspathEntryResolver.computeDefaultContainerEntries(IvyDERuntimeClasspathEntryResolver.java:91)
        at org.apache.ivyde.eclipse.IvyDERuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(IvyDERuntimeClasspathEntryResolver.java:77)
        at org.eclipse.jdt.internal.launching.RuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(RuntimeClasspathEntryResolver.java:44)
        at org.eclipse.jdt.launching.JavaRuntime.resolveRuntimeClasspathEntry(JavaRuntime.java:919)
        at org.eclipse.jdt.launching.StandardSourcePathProvider.resolveClasspath(StandardSourcePathProvider.java:89)
        at org.eclipse.jdt.launching.JavaRuntime.resolveSourceLookupPath(JavaRuntime.java:815)
        at org.eclipse.jdt.launching.sourcelookup.containers.ClasspathContainerSourceContainer.createSourceContainers(ClasspathContainerSourceContainer.java:84)
        at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.getSourceContainers(CompositeSourceContainer.java:129)
        at org.eclipse.debug.internal.ui.sourcelookup.SourceContainerViewer$ContentProvider.getChildren(SourceContainerViewer.java:77)
        at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1354)
        at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:391)
        at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:896)
        at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:601)
        at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:801)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
        at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:778)
        at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:644)
        at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:749)
        at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1444)
        at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:952)
        at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1455)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:132)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3776)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1367)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1390)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
        at org.eclipse.swt.widgets.TreeItem.sendExpand(TreeItem.java:1024)
        at org.eclipse.swt.widgets.Tree.expandItem_expandChildren(Tree.java:1186)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:5183)
        at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
        at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
        at org.eclipse.swt.widgets.Widget.mouseDownSuper(Widget.java:1025)
        at org.eclipse.swt.widgets.Tree.mouseDownSuper(Tree.java:1974)
        at org.eclipse.swt.widgets.Widget.mouseDown(Widget.java:1021)
        at org.eclipse.swt.widgets.Control.mouseDown(Control.java:2258)
        at org.eclipse.swt.widgets.Tree.mouseDown(Tree.java:1942)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
        at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
        at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220)
        at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:1943)
        at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2025)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:5040)
        at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
        at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4582)
        at org.eclipse.swt.widgets.Display.applicationProc(Display.java:4659)
        at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
        at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:115)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3274)
        at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
        at org.eclipse.jface.window.Window.open(Window.java:801)
        at org.eclipse.debug.ui.sourcelookup.CommonSourceNotFoundEditor.editSourceLookupPath(CommonSourceNotFoundEditor.java:192)
        at org.eclipse.debug.ui.sourcelookup.CommonSourceNotFoundEditor$1.widgetSelected(CommonSourceNotFoundEditor.java:154)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3776)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1367)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1390)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
        at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1187)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3622)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3277)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
        at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
        at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
        at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
        
        Show
        Nicolas Lalevée added a comment - I have setup a similar fake project: http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/jetty/ http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/jetty-webapp/ And I have been able to reproduce the issue. I am not sure when it happened, but I noticed some NPE in the logs, might be related. Could you check your logs to see if there is some ivyde stack trace too ? the stack trace I have found: java.lang.NullPointerException at org.apache.ivyde.eclipse.IvyDERuntimeClasspathEntryResolver.computeDefaultContainerEntries(IvyDERuntimeClasspathEntryResolver.java:91) at org.apache.ivyde.eclipse.IvyDERuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(IvyDERuntimeClasspathEntryResolver.java:77) at org.eclipse.jdt.internal.launching.RuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(RuntimeClasspathEntryResolver.java:44) at org.eclipse.jdt.launching.JavaRuntime.resolveRuntimeClasspathEntry(JavaRuntime.java:919) at org.eclipse.jdt.launching.StandardSourcePathProvider.resolveClasspath(StandardSourcePathProvider.java:89) at org.eclipse.jdt.launching.JavaRuntime.resolveSourceLookupPath(JavaRuntime.java:815) at org.eclipse.jdt.launching.sourcelookup.containers.ClasspathContainerSourceContainer.createSourceContainers(ClasspathContainerSourceContainer.java:84) at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.getSourceContainers(CompositeSourceContainer.java:129) at org.eclipse.debug.internal.ui.sourcelookup.SourceContainerViewer$ContentProvider.getChildren(SourceContainerViewer.java:77) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1354) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:391) at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:896) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:601) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:801) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:778) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:644) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:749) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1444) at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:952) at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1455) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:132) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3776) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1367) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1390) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375) at org.eclipse.swt.widgets.TreeItem.sendExpand(TreeItem.java:1024) at org.eclipse.swt.widgets.Tree.expandItem_expandChildren(Tree.java:1186) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5183) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220) at org.eclipse.swt.widgets.Widget.mouseDownSuper(Widget.java:1025) at org.eclipse.swt.widgets.Tree.mouseDownSuper(Tree.java:1974) at org.eclipse.swt.widgets.Widget.mouseDown(Widget.java:1021) at org.eclipse.swt.widgets.Control.mouseDown(Control.java:2258) at org.eclipse.swt.widgets.Tree.mouseDown(Tree.java:1942) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220) at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:1943) at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2025) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5040) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4582) at org.eclipse.swt.widgets.Display.applicationProc(Display.java:4659) at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method) at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:115) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3274) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.debug.ui.sourcelookup.CommonSourceNotFoundEditor.editSourceLookupPath(CommonSourceNotFoundEditor.java:192) at org.eclipse.debug.ui.sourcelookup.CommonSourceNotFoundEditor$1.widgetSelected(CommonSourceNotFoundEditor.java:154) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3776) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1367) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1390) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1187) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3622) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3277) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
        Hide
        Phil Clay added a comment -

        Hi Nicolas,

        I'm still using trunk. 2.1.0.201003291630-hudson-102.

        I did not see any IvyDE stacktraces in my eclipse log (workspace/.metadata/.*log). I tried setting up a new launch config, expanding various things, changing the default source path as I mentioned when I filed the bug, etc etc. Still no stacktraces.

        Show
        Phil Clay added a comment - Hi Nicolas, I'm still using trunk. 2.1.0.201003291630-hudson-102. I did not see any IvyDE stacktraces in my eclipse log (workspace/.metadata/.*log). I tried setting up a new launch config, expanding various things, changing the default source path as I mentioned when I filed the bug, etc etc. Still no stacktraces.
        Hide
        Nicolas Lalevée added a comment -

        thanks for the feed back Phil.
        Actually it was a bug on my part which I recently introduced in trunk, which I just fixed, probably fixed in the hudson build you tested with.

        Now someone needs to look deeper in the JDT to understand what is going on. I may not have time soon to do such debugging.

        Show
        Nicolas Lalevée added a comment - thanks for the feed back Phil. Actually it was a bug on my part which I recently introduced in trunk, which I just fixed, probably fixed in the hudson build you tested with. Now someone needs to look deeper in the JDT to understand what is going on. I may not have time soon to do such debugging.
        Hide
        Nicolas Lalevée added a comment -

        I think I finally understand what the launch configuration expects from IvyDE and I have implemented it. It seems to work a lot better now. I'll appreciate some feedback on the fix.

        Show
        Nicolas Lalevée added a comment - I think I finally understand what the launch configuration expects from IvyDE and I have implemented it. It seems to work a lot better now. I'll appreciate some feedback on the fix.
        Hide
        Phil Clay added a comment -

        Hi Nicolas,

        Many thanks for looking into this.

        I tried out IvyDE 2.2.0.201104030801-hudson-179. I can report that it's very close, but not quite completely fixed.

        The behavior that I'm seeing now is that the default source lookup path includes the root project (the project that the launch configuration references) and all leaf projects. But it does NOT include the intermediary projects between the root and leaves.

        For example...

        Say I have projects A, B, and C. A depends on B, B depends on C. If I setup a launch configuration for project A, then the default source lookup path includes projects A and C, but does not include project B.

        Show
        Phil Clay added a comment - Hi Nicolas, Many thanks for looking into this. I tried out IvyDE 2.2.0.201104030801-hudson-179. I can report that it's very close, but not quite completely fixed. The behavior that I'm seeing now is that the default source lookup path includes the root project (the project that the launch configuration references) and all leaf projects. But it does NOT include the intermediary projects between the root and leaves. For example... Say I have projects A, B, and C. A depends on B, B depends on C. If I setup a launch configuration for project A, then the default source lookup path includes projects A and C, but does not include project B.
        Hide
        Nicolas Lalevée added a comment -

        All these dependencies are managed by IvyDE, right ?

        In the launch configuration, what do you see under the "Classpath" and "Source" tabs ?
        Under the "User Entries" of the "Classpath" I would expect to see the project "A (default classpath)". Under that there would be a "A" again and an IvyDE container.
        In the "Source" tab I would expect "Default" folder in which there will be the jre jars, and somehow mixed the third party jars and your 3 projects A, B and C.

        What do you have exactly ?

        Show
        Nicolas Lalevée added a comment - All these dependencies are managed by IvyDE, right ? In the launch configuration, what do you see under the "Classpath" and "Source" tabs ? Under the "User Entries" of the "Classpath" I would expect to see the project "A (default classpath)". Under that there would be a "A" again and an IvyDE container. In the "Source" tab I would expect "Default" folder in which there will be the jre jars, and somehow mixed the third party jars and your 3 projects A, B and C. What do you have exactly ?
        Hide
        Nicolas Lalevée added a comment -

        Maybe you're hitting IVYDE-277. I have tried a fix, you're welcomed to test the next build from jenkins/hudson.

        Show
        Nicolas Lalevée added a comment - Maybe you're hitting IVYDE-277 . I have tried a fix, you're welcomed to test the next build from jenkins/hudson.
        Hide
        Phil Clay added a comment -

        Yes, all dependencies are managed by IvyDE.

        Under "User Entries" of "Classpath", I see exactly what you describe... "Project a (default classpath)", then under there is A again and an IvyDE container.

        On the Source tab, under Default, I see:

        • jre jars
        • project A
        • the output folder of B (i.e. the folder into which the .class files are generated)
        • project C
        • 3rd party jars resolved via IvyDE

        I have not tried your latest change, as build 180 looks like it timed out.

        Show
        Phil Clay added a comment - Yes, all dependencies are managed by IvyDE. Under "User Entries" of "Classpath", I see exactly what you describe... "Project a (default classpath)", then under there is A again and an IvyDE container. On the Source tab, under Default, I see: jre jars project A the output folder of B (i.e. the folder into which the .class files are generated) project C 3rd party jars resolved via IvyDE I have not tried your latest change, as build 180 looks like it timed out.
        Hide
        Nicolas Lalevée added a comment -

        There is now a successful build #181.

        Show
        Nicolas Lalevée added a comment - There is now a successful build #181.
        Hide
        Phil Clay added a comment -

        Tried using build 181, and everything appears to be working well.

        Thanks Nicolas!! This is awesome.

        Show
        Phil Clay added a comment - Tried using build 181, and everything appears to be working well. Thanks Nicolas!! This is awesome.
        Hide
        Nicolas Lalevée added a comment -

        thank you for the good news.

        We'll see if this will be the final fix depending on the feedback from the JDT team: http://www.eclipse.org/forums/index.php?t=msg&th=207309&start=0&S=0a98b93c713ed526b72201ebed2d38a7

        Show
        Nicolas Lalevée added a comment - thank you for the good news. We'll see if this will be the final fix depending on the feedback from the JDT team: http://www.eclipse.org/forums/index.php?t=msg&th=207309&start=0&S=0a98b93c713ed526b72201ebed2d38a7

          People

          • Assignee:
            Nicolas Lalevée
            Reporter:
            Phil Clay
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development