Bug 151316

Summary:

Eclipse is identifying package errors while the actual useage is correct (it compiles).

Product:

[Eclipse Project] JDT

Reporter:

David Seever <dlseever>

Component:

Core

Assignee:

JDT-Core-Inbox <jdt-core-inbox>

Status:

RESOLVED WORKSFORME

QA Contact:

Severity:

normal

Priority:

Version:

3.1.2

Target Milestone:

3.3

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Simple test to show that it can compile	none

Description David Seever

2006-07-20 15:35:47 EDT

This is similiar to the bug #6494 from 2001.  The roll over text states "The declared package does not match..".

This happens when the directory is x\y\z\w but the file in directory 'w' has the package x.y.z.

The error indications propogate based off the one package error.  Compile still works.

Comment 1 Frederic Fusier

2006-08-01 11:30:16 EDT

Not sure to understand what is the problem here, if you have following test case:
x/y/z/w/Test.java:
  package x.y.z;
  public class Test {}

Then using 3.1.2, there's a compile error which correctly states "The declared package does not match the expected package x.y.z" and quick-fix correctly proposes either to move the CU to x.y.z package or change package declaration to x.y.z.w.

I surely miss something, can you provide more details on your offending test case?

Comment 2 Olivier Thomann

2006-08-15 14:36:20 EDT

From what directory are you compiling your file?

Comment 3 David Seever

2006-08-17 18:15:29 EDT

Created attachment 48144 [details]
Simple test to show that it can compile

Compiling using JDK 1.4.2_12 from the cmd line on WinXP

Make directory c:\a\b\c\d
in directory "d" make a java file named Test.java

inside the file

pacakage a.b.c.d;

class Test {

    public static void main(String [] argv){
          //do not need to put anything, but maybe System.out
    }
}//class Test end

Comment 4 Kent Johnson

2007-06-19 11:18:14 EDT

When searching for source files, the directory must match the expected package or the type cannot be found.

We generate an error so the user can correct this problem.

We do not consider this to be a bug, but a case where we differ from javac.