Bug 65693 - Package Explorer shows .class files instead of .java
Summary: Package Explorer shows .class files instead of .java
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 RC2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-04 06:38 EDT by Paul Gardner CLA
Modified: 2004-06-11 10:20 EDT (History)
0 users

See Also:


Attachments
Proposed patch (1.10 KB, patch)
2004-06-07 07:03 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression test (2.44 KB, patch)
2004-06-07 09:53 EDT, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Gardner CLA 2004-06-04 06:38:05 EDT
I have two projects A and B in the same workspace. I use the "Add Class 
Folder" option on "Java Build Path"/"Libraries" to add project B's root to A. 
I then add an external jar to A. At this point project B's .java files in the 
project explorer magically change into .class files and the project becomes 
somewhat unusable.
Comment 1 Dirk Baeumer CLA 2004-06-06 12:58:31 EDT
If you want to reference project B form project A simply check it on the 
projects page of the Java build path. Don't put the root onto A's build path.

However, we have to understand why B gets inconsistent. But not critical for 
3.0 since the recommended project ref setup is different.
Comment 2 Dirk Baeumer CLA 2004-06-06 13:08:43 EDT
I tested the following setup

- project A with A.java in default package
- project B with B.java in default package
- B's root on A's build path as a class folder
- put an external Jar on A's build path

Expanding the default package in B reports the default package as

<default> [in <project root> [in A]]  <== strange is that it belongs to A
  B.class (not open)

The kind of the package is !IPackageFragmentRoot.K_SOURCE, that's why the 
package explorer shows class files.

May be we shouldn't support this setup.

Moving to JDT/Core.
Comment 3 Paul Gardner CLA 2004-06-06 13:45:36 EDT
hmm, just noticed that I missed out the point that project B already depends 
on project A (as added via the suggested "add projects" approach). I therefore 
can't add B to A as we get a cyclic dependency.

The reason I'm doing this is as follows:

A is the main application. It supports plugins. B is such a plugin (and hence 
relies on A as a "project" as it uses the plugin interface defined by A). I 
want to test plugin B when running A, hence A needs B's classes available 
(hence the "add class folder" approach).
Comment 4 Jerome Lanneluc CLA 2004-06-07 05:34:36 EDT
Problem is in PackageFragmentRoot.equals(Object) that doesn't check for the 
parent's equality. Note we had this problem in 2.1 as well. But in 2.1, UI 
would not allow this scenario.
Comment 5 Philipe Mulet CLA 2004-06-07 05:56:47 EDT
Isn't this #equals implementation allowing to share infos for external JARs ? 
Comment 6 Philipe Mulet CLA 2004-06-07 06:03:50 EDT
Actually, JarPackageFragmentRoot redefines its own #equals() to do the right 
thing, so we are safe.

This isn't a regression, just a scenario which wasn't visible in 2.1 when 
using buildpath UI. Manual editing of .classpath was allowing it; or sharing a 
project designed by Eclipse 3.0 could expose this as well in 2.1 client.

Approved for RC2.
Comment 7 Jerome Lanneluc CLA 2004-06-07 07:03:40 EDT
Created attachment 11646 [details]
Proposed patch
Comment 8 Jerome Lanneluc CLA 2004-06-07 09:53:14 EDT
Created attachment 11656 [details]
Regression test

Added regression test JavaProjectTests#testRootGetPackageFragments3()
Comment 9 Jerome Lanneluc CLA 2004-06-07 13:27:01 EDT
Fix and test released.
Comment 10 Olivier Thomann CLA 2004-06-11 10:20:14 EDT
Verified in 200406110010