Bug 15810

Summary: ClasspathContainer question
Product: [Eclipse Project] JDT Reporter: Martin Aeschlimann <martinae>
Component: CoreAssignee: Philipe Mulet <philippe_mulet>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: darin.eclipse, erich_gamma
Version: 2.0   
Target Milestone: 2.0 M6   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Martin Aeschlimann CLA 2002-05-11 12:32:48 EDT
20020510

First steps with ClasspathContainers.
create .classpath
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path=""/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="var" path="JRE_LIB" rootpath="JRE_SRCROOT" 
sourcepath="JRE_SRC"/>
    <classpathentry kind="output" path=""/>
</classpath>

In the build path wizard, want to know if the container can resolve (exists) 
and want to get the container description.

getClasspathContainer(classPathEntry, currProject)

-> JME
It might be because JRE_LIB is on the classpath too. But as I just wanted to 
get the description, this exeption is too much.

STACK Java Model Exception: Core Exception [code 977] Name collision.
	at org.eclipse.jdt.core.JavaCore.getClasspathContainer
(JavaCore.java:402)
	at 
org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.getExistingEntrie
s(BuildPathsBlock.java:339)
	at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.init
(BuildPathsBlock.java:293)
	at 
org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage.createWithJava
(BuildPathsPropertyPage.java:75)
	at 
org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage.createContents
(BuildPathsPropertyPage.java:65)
	at org.eclipse.jface.preference.PreferencePage.createControl
(PreferencePage.java:201)
	at org.eclipse.jface.preference.PreferenceDialog.showPage
(PreferenceDialog.java:906)
	at org.eclipse.jface.preference.PreferenceDialog.selectSavedItem
(PreferenceDialog.java:596)
	at org.eclipse.jface.preference.PreferenceDialog.createContents
(PreferenceDialog.java:262)
	at org.eclipse.jface.window.Window.create(Window.java:275)
	at org.eclipse.ui.dialogs.PropertyDialogAction.run
(PropertyDialogAction.java:156)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:590)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection
(ActionContributionItem.java:407)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent
(ActionContributionItem.java:361)
	at org.eclipse.jface.action.ActionContributionItem.access$0
(ActionContributionItem.java:352)
	at 
org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent
(ActionContributionItem.java:47)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:75)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:637)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1432)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1221)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1062)
	at org.eclipse.ui.internal.Workbench.run(Workbench.java:1045)
	at org.eclipse.core.internal.boot.InternalBootLoader.run
(InternalBootLoader.java:739)
	at org.eclipse.core.boot.BootLoader.run(BootLoader.java:420)
	at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:16)
Comment 1 Philipe Mulet CLA 2002-05-13 05:32:30 EDT
This exception was originally thrown in the code of the registered container 
initializer. 

I think we should have the container initialization directly throw a 
JavaModelException (API change) instead of a CoreException, thus the stack 
trace would read much better.
Comment 2 Philipe Mulet CLA 2002-05-13 05:53:25 EDT
The exception is indeed raised due to the fact that some project have a 
duplicate reference to rt.jar.

I agree that the exception is too harsh in this scenario. We have had the same 
problem with cp variables for a year, and nobody has complained so far.

We might want to revisit this scenario post 2.0 ? Or maybe the #veriy code when 
setting new CP should not validate the CP if only performing an update (reusing 
similar classpath).
Comment 3 Philipe Mulet CLA 2002-05-13 05:53:48 EDT
Fixed
Comment 4 Martin Aeschlimann CLA 2002-05-13 06:34:18 EDT
To give more info on the reason of this bug report:

I was thinking about how container entries should be rendered in the UI? First 
thought that the description of IClasspathContainer should be used. The 
problems with that are the bug report below and also the fact that this can 
force a plugin load (however, the plugin would be loaded soon anyway).

A alternative solution would be to have a description string at the initializer 
config element. Advantage is that this prevents plugin load. Drawback is that 
it can only be a general description about the container. I can imaging that a 
precise string like (JRE - 1.4) would be helpful.

I don't know how the fix that you just released looks like. But if there are 
still possible validation exceptions on getClasspathContainer, I would suggest 
to add a getClasspathContainerDescription to JavaCore that would not care about 
duplications ect.