Description Curtis Windatt 2011-08-11 17:11:35 EDT

+++ This bug was initially created as a clone of Bug #348035 +++

Cloned for releasing to 3.7.1

There is a regression in the recent fix for Bug 147831 which causes false classpath problem markers... 
"Archive for required library: 'C:/indigo/devWorkspace/.metadata/.plugins/org.eclipse.pde.core/.external_libraries/oracle.eclipse.tools.common.templating_4.1.0.201105211528/build/xmlbeans' in project 'oracle.eclipse.tools.weblogic' cannot be read or is not a valid ZIP file."


To reproduce, import a plugin which has a dependency on another plugin that has a bundle classpath that includes a directory name as well as the bundle itself, '.'. The marker requires that the classpath error is fixed before you can compile the 

The ExternalLibraryCache for the ExternalModelManager creates an external library classpath entry to an empty file in PDE's metadata location for a directory listed in a bundle's classPath.

A Bundle classpath can contain the name of a directory, a resource or the bundle itself. The routine ExternalLibraryCache.getExtractedLibraries() checks for the "." entry for the bundle itself, then tries to extract a jar for the other entries on the bundle's classpath. For a jar file, that works fine (Bug 147831). However, if the entry is a directory, there is still a call to extractJar() which ends up creating an empty file in the PDE metadata location AND adds the empty file as an extracted lib.

When ClasspathValidation.validate() is executed in JDT, the entry for this empty file causes a failure. JavaModelManager.getZipFile() cannot read the empty file, throwing an IOException which eventually causes JDT to record a marker for a classpath problem.

Seems like ExternalLibraryCache.getExtractedLibraries() should check if the ZipEntry is not a directory (at least until there's support for directory entries in the bundle classpath).