Bug 25520 - Possible problem in JavaProject#findPackageFragmentRoots(IClasspathEntry)
Summary: Possible problem in JavaProject#findPackageFragmentRoots(IClasspathEntry)
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: 2.1 M3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-29 18:39 EST by Luc Bourlier CLA
Modified: 2002-11-15 03:48 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luc Bourlier CLA 2002-10-29 18:39:03 EST
Build 20021029

In org.eclipse.jdt.debug.test.core, we have two tests which used to work fine
(SourceLocationTests#testPositiveSystemLibrarySourceLocation() and
SourceLocationTests#testNegativeSystemLibrarySourceLocation()) but fail in the
latest integration build.

The point is that before, when
JavaProject#getPackageFragmentRoots(IClasspathEntry) was called,
getResolvedClasspath(..) was call on the IClasspathEntry, and the variables were
resolved. In the new code, getResolvedClasspath(..) is no more called.

If I change the code of computePackageFragmentRoots(IClasspathEntry) with the
following code, I get the tests to work:

public IPackageFragmentRoot[] computePackageFragmentRoots(IClasspathEntry entry) {
  try {
    return computePackageFragmentRoots(getResolvedClasspath(new
IClasspathEntry[]{entry}, true, false), false);
  } catch (JavaModelException e) {
    return new IPackageFragmentRoot[] {};
  }
}

Is it a problem in your code, when you change/create the method you forgot to
add this method call ? or is it us which use the method in a wrong way ?
Comment 1 Philipe Mulet CLA 2002-10-30 05:12:57 EST
No this would be a bug in our code, as a consequence from a fix for bug 25433.
Need to fix asap.
Comment 2 Philipe Mulet CLA 2002-10-30 06:07:00 EST
Fix proposal is the right one.

Fixed.
Comment 3 Philipe Mulet CLA 2002-10-30 07:31:11 EST
Actually, moved resolution to #findPackageFragmentRoots, since other internal 
clients shouldn't be penalized when already passing resolved path in.
Comment 4 Darin Swanson CLA 2002-10-30 12:15:48 EST
We have commented out the two tests that are failing for the Oct 30 integration 
build.
Comment 5 David Audel CLA 2002-11-15 03:48:24 EST
Verified.