[jdt-core-dev] compiler: "duplicate" package-info in presence of nested

[Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx>]

Hi,

I am trying to use the Eclipse compiler from Maven through the
plexus-compiler-eclipse, but have run into some problems when
compiling some of our components. The error I get is

 path/to/some/package/package-info/java.java:[1,0] The type
package-info is already defined

(I didn't notice the strange file name until now and I'm not sure if
it is composed by eclipse or maven, so it may not be relevant to the
problem.)

I am not sure if the problem is with the eclipse compiler or the maven
plugin, but after spending some hours debugging both of them, I'm
leaning towards the compiler. I seem to be getting this error only
where I have inner classes along with a package-info. It seems to be
related to the issue described on [1].

Stepping through the code, it seems like isViewedAsDeprecated() is
only called for member types and local types. I'm assuming normal
types can also be deprecated by deprecating the package, so why is
isViewedAsDeprecated() not called (at the same point in the code) not
for normal types? Sorry if this is a stupid question from someone who
has never worked on a compiler.

Assuming that the call is correct, why does it cause the compilation
failure? The maven plugin, when asked to findType(), answers with an
ICompilationUnit. This seems intuitively correct to me, but Jay seems
to suggest on [1] that it should return null. Should the
INameEnvironment always return null if the requested type was in the
list of compilation units? Would it be feasible for LookupEnvironment
or some other compiler-internal class to take care of that so not each
implementation of INameEnvironment would have to?

I am using Eclipse JDT core as of 2011-08-08.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=322789#c17

Thanks,
Martin