IvyDE
  1. IvyDE
  2. IVYDE-200

The gui wizard crash when adding a IvyDE Managed Dependencies library to a .launch file's classpath

    Details

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

      Windows XP sp3, Springsource Tool Suite 2.1 (Eclipse 3.5), IvyDE 2.0.0 Final, Ivy 2.1 RC1

      Description

      When adding an IvyDE library to the build path for a Java project, everything goes fine. I receive the gui wizard which locates the ivy.xml file and let's me pick which confs I want to use.

      However, when I try to do the same thing for a .launch file (i.e. setting up the launch for a JUnit Test case), once I choose Add Library and select IvyDE Managed Dependencies and hit Next, the wizard should proceed to the next screen, but instead it stays on the 'Select library type to add' screen. It acts as if it's proceeding though the flow, however. It does pop up a error "balloon" which says 'Ivy file not found' even though it's still on the 'Select library screen'. The ivy.xml is in the correct place, as I can add an Ivy library to the project's build path just fine. I can then click the Next button again, which takes me to a screen which says "Choose ivy file and its configurations", but the screen is completely blank (no labels, form fields, etc.) and I still have the error "balloon" mentioned earlier. From here I can click Finish, and the library is added to the .launch's classpath, but something about it causes the JUnit to not load any dependencies contained in the ivy.xml file.

      In my particular case it was obvious as I would get the exception below when running the JUnit:

      java.lang.NoClassDefFoundError: org/junit/runner/notification/RunListener

      Here's the classpath entry which was added from the above steps.

      <listEntry value="<?xml version="1.0" encoding="UTF-8"?> <runtimeClasspathEntry containerPath="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;confs=*" path="3" type="4"/> "/>

      Instead of adding the library individually like outline above, if I choose to add the project to the .launch's classpath accepting all of it's exported entries and required projects, I get the entry below. Note the difference - confs=default instead of confs=* from the first entry.

      <listEntry value="<?xml version="1.0" encoding="UTF-8"?> <runtimeClasspathEntry containerPath="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;confs=default" path="3" type="4"/> "/>

      If I change the first entry to match the second in regards to confs=default, then the dependencies contained in the ivy.xml are loaded properly.

        Activity

        Hide
        Nicolas Lalevée added a comment -

        Actually the gui was crashing due to some NPE raised by the IvyDE plugin. It has been fixed in trunk.

        Note thought that IvyDE correctly indicate that it cannot find the ivy.xml file. In the launch configuration panels, there is no "project" scope, the IvyDE container is not attached to any Eclipse project (due to Eclipse JDT API, not IvyDE itself). So you will have to specify the absolute path of the ivy.xml.

        Show
        Nicolas Lalevée added a comment - Actually the gui was crashing due to some NPE raised by the IvyDE plugin. It has been fixed in trunk. Note thought that IvyDE correctly indicate that it cannot find the ivy.xml file. In the launch configuration panels, there is no "project" scope, the IvyDE container is not attached to any Eclipse project (due to Eclipse JDT API, not IvyDE itself). So you will have to specify the absolute path of the ivy.xml.
        Hide
        Jason Dilley added a comment -

        Thanks for the quick response, but after starting with a fresh STS install and adding the IvyDE plugin from the trunk, I still experience the same behavior as originally reported. I do see a NPE in the workspace .log file (pasted below).

        As for your suggestion to add the explicit path to the ivy.xml file, how does one go about doing that for a .launch? I tried adding the folder and that didn't change the behavior (I still received the 'Ivy file not found' balloon. I then tried adding the ivy.xml as a jar, with the same result.

        !ENTRY org.eclipse.ui 4 0 2009-09-14 12:33:36.137
        !MESSAGE Unhandled event loop exception
        !STACK 0
        java.lang.NullPointerException
        at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathUtil.getIvyClasspathContainers(IvyClasspathUtil.java:109)
        at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.checkCompleted(IvydeContainerPage.java:125)
        at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.checkIvyXmlPath(IvydeContainerPage.java:171)
        at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage$5.ivyXmlPathUpdated(IvydeContainerPage.java:345)
        at org.apache.ivyde.eclipse.ui.IvyFilePathText.ivyXmlPathUpdated(IvyFilePathText.java:139)
        at org.apache.ivyde.eclipse.ui.IvyFilePathText$3.modifyText(IvyFilePathText.java:106)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:167)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1027)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1008)
        at org.eclipse.swt.widgets.Text.wmCommandChild(Text.java:2526)
        at org.eclipse.swt.widgets.Control.WM_COMMAND(Control.java:4082)
        at org.eclipse.swt.widgets.Control.windowProc(Control.java:3949)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:4589)
        at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
        at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2312)
        at org.eclipse.swt.widgets.Text.callWindowProc(Text.java:255)
        at org.eclipse.swt.widgets.Control.windowProc(Control.java:4036)
        at org.eclipse.swt.widgets.Text.windowProc(Text.java:2170)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:4589)
        at org.eclipse.swt.internal.win32.OS.SetWindowTextW(Native Method)
        at org.eclipse.swt.internal.win32.OS.SetWindowText(OS.java:3263)
        at org.eclipse.swt.widgets.Text.setText(Text.java:1961)
        at org.apache.ivyde.eclipse.ui.IvyFilePathText.init(IvyFilePathText.java:219)
        at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.loadFromConf(IvydeContainerPage.java:500)
        at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.createControl(IvydeContainerPage.java:280)
        at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1157)
        at org.eclipse.jface.wizard.WizardDialog.access$2(WizardDialog.java:1149)
        at org.eclipse.jface.wizard.WizardDialog$5.run(WizardDialog.java:1138)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
        at org.eclipse.jface.wizard.WizardDialog.showPage(WizardDialog.java:1136)
        at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:830)
        at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:369)
        at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
        at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
        at org.eclipse.jface.window.Window.open(Window.java:801)
        at org.eclipse.jdt.internal.ui.wizards.buildpaths.ClasspathContainerWizard.openWizard(ClasspathContainerWizard.java:225)
        at org.eclipse.jdt.ui.wizards.BuildPathDialogAccess.chooseContainerEntries(BuildPathDialogAccess.java:276)
        at org.eclipse.jdt.internal.debug.ui.actions.AddLibraryAction.run(AddLibraryAction.java:39)
        at org.eclipse.jdt.internal.debug.ui.launcher.RuntimeClasspathAdvancedDialog.okPressed(RuntimeClasspathAdvancedDialog.java:156)
        at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472)
        at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
        at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
        at org.eclipse.jface.window.Window.open(Window.java:801)
        at org.eclipse.jdt.internal.debug.ui.actions.AddAdvancedAction.run(AddAdvancedAction.java:39)
        at org.eclipse.jdt.internal.debug.ui.actions.RuntimeClasspathAction$1.widgetSelected(RuntimeClasspathAction.java:137)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
        at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
        at org.eclipse.jface.window.Window.open(Window.java:801)
        at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.open(LaunchConfigurationsDialog.java:1064)
        at org.eclipse.debug.ui.DebugUITools$1.run(DebugUITools.java:398)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
        at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:406)
        at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:340)
        at org.eclipse.debug.ui.actions.OpenLaunchDialogAction.run(OpenLaunchDialogAction.java:81)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
        at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
        at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
        at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
        at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
        at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
        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:368)
        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:585)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1287)

        Show
        Jason Dilley added a comment - Thanks for the quick response, but after starting with a fresh STS install and adding the IvyDE plugin from the trunk, I still experience the same behavior as originally reported. I do see a NPE in the workspace .log file (pasted below). As for your suggestion to add the explicit path to the ivy.xml file, how does one go about doing that for a .launch? I tried adding the folder and that didn't change the behavior (I still received the 'Ivy file not found' balloon. I then tried adding the ivy.xml as a jar, with the same result. !ENTRY org.eclipse.ui 4 0 2009-09-14 12:33:36.137 !MESSAGE Unhandled event loop exception !STACK 0 java.lang.NullPointerException at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathUtil.getIvyClasspathContainers(IvyClasspathUtil.java:109) at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.checkCompleted(IvydeContainerPage.java:125) at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.checkIvyXmlPath(IvydeContainerPage.java:171) at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage$5.ivyXmlPathUpdated(IvydeContainerPage.java:345) at org.apache.ivyde.eclipse.ui.IvyFilePathText.ivyXmlPathUpdated(IvyFilePathText.java:139) at org.apache.ivyde.eclipse.ui.IvyFilePathText$3.modifyText(IvyFilePathText.java:106) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:167) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1027) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1008) at org.eclipse.swt.widgets.Text.wmCommandChild(Text.java:2526) at org.eclipse.swt.widgets.Control.WM_COMMAND(Control.java:4082) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3949) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4589) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2312) at org.eclipse.swt.widgets.Text.callWindowProc(Text.java:255) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4036) at org.eclipse.swt.widgets.Text.windowProc(Text.java:2170) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4589) at org.eclipse.swt.internal.win32.OS.SetWindowTextW(Native Method) at org.eclipse.swt.internal.win32.OS.SetWindowText(OS.java:3263) at org.eclipse.swt.widgets.Text.setText(Text.java:1961) at org.apache.ivyde.eclipse.ui.IvyFilePathText.init(IvyFilePathText.java:219) at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.loadFromConf(IvydeContainerPage.java:500) at org.apache.ivyde.eclipse.cpcontainer.IvydeContainerPage.createControl(IvydeContainerPage.java:280) at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1157) at org.eclipse.jface.wizard.WizardDialog.access$2(WizardDialog.java:1149) at org.eclipse.jface.wizard.WizardDialog$5.run(WizardDialog.java:1138) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.wizard.WizardDialog.showPage(WizardDialog.java:1136) at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:830) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:369) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.jdt.internal.ui.wizards.buildpaths.ClasspathContainerWizard.openWizard(ClasspathContainerWizard.java:225) at org.eclipse.jdt.ui.wizards.BuildPathDialogAccess.chooseContainerEntries(BuildPathDialogAccess.java:276) at org.eclipse.jdt.internal.debug.ui.actions.AddLibraryAction.run(AddLibraryAction.java:39) at org.eclipse.jdt.internal.debug.ui.launcher.RuntimeClasspathAdvancedDialog.okPressed(RuntimeClasspathAdvancedDialog.java:156) at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.jdt.internal.debug.ui.actions.AddAdvancedAction.run(AddAdvancedAction.java:39) at org.eclipse.jdt.internal.debug.ui.actions.RuntimeClasspathAction$1.widgetSelected(RuntimeClasspathAction.java:137) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.open(LaunchConfigurationsDialog.java:1064) at org.eclipse.debug.ui.DebugUITools$1.run(DebugUITools.java:398) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:406) at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:340) at org.eclipse.debug.ui.actions.OpenLaunchDialogAction.run(OpenLaunchDialogAction.java:81) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) 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:368) 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:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
        Hide
        Jason Dilley added a comment -

        I checked out the source, made a change to check javaProject for null, and did a build locally, and that seemed to fix the issue. So, it appears that the source on the trunk doesn't have the change referred to earlier.

        Show
        Jason Dilley added a comment - I checked out the source, made a change to check javaProject for null, and did a build locally, and that seemed to fix the issue. So, it appears that the source on the trunk doesn't have the change referred to earlier.
        Hide
        Nicolas Lalevée added a comment -

        When you say you are running with the trunk and it was still crashing, are you using Hudson's builds ? Because the last builds failed, so the last successful is quite old by now. At least the stack trace you show me there isn't corresponding to the current line numbers of the trunk.

        But then as I was redoing some test to check it was actually working on the trunk, I got other kind of issues, like the some strange unresolved dependencies. And then the support of classpath container in the java launcher is very poor... there no way to edit the IvyDE configuration, need to create one each time. So then no way the launch a resolve...

        Show
        Nicolas Lalevée added a comment - When you say you are running with the trunk and it was still crashing, are you using Hudson's builds ? Because the last builds failed, so the last successful is quite old by now. At least the stack trace you show me there isn't corresponding to the current line numbers of the trunk. But then as I was redoing some test to check it was actually working on the trunk, I got other kind of issues, like the some strange unresolved dependencies. And then the support of classpath container in the java launcher is very poor... there no way to edit the IvyDE configuration, need to create one each time. So then no way the launch a resolve...
        Hide
        Nicolas Lalevée added a comment -

        Finally the resolve issues I was just talking about are gone with the cleanup I just did on the trunk.
        And the possibility of edition of the container configuration, I think it is possible: see IVYDE-201

        Show
        Nicolas Lalevée added a comment - Finally the resolve issues I was just talking about are gone with the cleanup I just did on the trunk. And the possibility of edition of the container configuration, I think it is possible: see IVYDE-201
        Hide
        Jason Dilley added a comment -

        Yes, when I mentioned that I had done an install from the trunk I was using the Hudson builds as referenced on the IvyDE download page (It refers us to use http://hudson.zones.apache.org/hudson/view/Ant/job/IvyDE-updatesite/lastSuccessfulBuild/artifact/trunk/build)

        I hadn't paid attention to the build date in the Hudson builds. I did a manual build from the svn trunk source just now, and the gui now displays properly when adding the Ivy library to a launch classpath.

        One issue, though, regarding the Resolve issue you were mentioning. You had previously said that a launch wasn't tied to a project, so we'd need to provide an explicit file path. We never did, as it appeared that the launches were properly tied to a project. I assumed that at least for JUnit's where you have to specify a project and a class that would always be the case. Whatever the reason, all of our JUnit launches did properly find and use the right ivy.xml without providing anything on the path other than 'ivy.xml'.

        With the latest trunk changes, though, it's now requiring an explicit file path. This would seem to not be desired, as an explicit path includes evidence of my OS and the location of my workspace i.e. c:/appWorkspaces/workspace1/project1/ivy.xml whereas another developer's path for the same file may be /home/developer1/workspaceA/project1/ivy.xml (We often pull the same code into multiple workspaces for parallel development efforts). In these cases, developers can't share .launches, which is a significant issue as we have dozens of JUnit's with corresponding launches, all checked into CVS to allow reuse.

        Is it possible to either change it back to recognize the project as it was before, or if we need to supply a path to the ivy file have that path be relative to the workspace root, and not the file system root? For my example above, this would be: '/project1/ivy.xml'

        Show
        Jason Dilley added a comment - Yes, when I mentioned that I had done an install from the trunk I was using the Hudson builds as referenced on the IvyDE download page (It refers us to use http://hudson.zones.apache.org/hudson/view/Ant/job/IvyDE-updatesite/lastSuccessfulBuild/artifact/trunk/build ) I hadn't paid attention to the build date in the Hudson builds. I did a manual build from the svn trunk source just now, and the gui now displays properly when adding the Ivy library to a launch classpath. One issue, though, regarding the Resolve issue you were mentioning. You had previously said that a launch wasn't tied to a project, so we'd need to provide an explicit file path. We never did, as it appeared that the launches were properly tied to a project. I assumed that at least for JUnit's where you have to specify a project and a class that would always be the case. Whatever the reason, all of our JUnit launches did properly find and use the right ivy.xml without providing anything on the path other than 'ivy.xml'. With the latest trunk changes, though, it's now requiring an explicit file path. This would seem to not be desired, as an explicit path includes evidence of my OS and the location of my workspace i.e. c:/appWorkspaces/workspace1/project1/ivy.xml whereas another developer's path for the same file may be /home/developer1/workspaceA/project1/ivy.xml (We often pull the same code into multiple workspaces for parallel development efforts). In these cases, developers can't share .launches, which is a significant issue as we have dozens of JUnit's with corresponding launches, all checked into CVS to allow reuse. Is it possible to either change it back to recognize the project as it was before, or if we need to supply a path to the ivy file have that path be relative to the workspace root, and not the file system root? For my example above, this would be: '/project1/ivy.xml'
        Hide
        Nicolas Lalevée added a comment -

        Actually it seems we have no choice here. As far as I understand the Eclipse API (I mean the java interfaces, not the UI), the classpath of a launch configuration is not tied to any particular project. The Eclipse API doesn't provide any project reference to IvyDE when a classpath is build for a launch configuration. So absolute path seems to be necessary.

        But I totally understand your use case, and whereas we will have to specify absolute paths, we could use eclipse variables support (IVYDE-152). So launch configuration can be shared between developpers.

        Show
        Nicolas Lalevée added a comment - Actually it seems we have no choice here. As far as I understand the Eclipse API (I mean the java interfaces, not the UI), the classpath of a launch configuration is not tied to any particular project. The Eclipse API doesn't provide any project reference to IvyDE when a classpath is build for a launch configuration. So absolute path seems to be necessary. But I totally understand your use case, and whereas we will have to specify absolute paths, we could use eclipse variables support ( IVYDE-152 ). So launch configuration can be shared between developpers.

          People

          • Assignee:
            Nicolas Lalevée
            Reporter:
            Jason Dilley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development