Bug 294360

Summary: Duplicate entries in Classpath Resolution when importing dependencies from parent project
Product: [Eclipse Project] JDT Reporter: Andre Doherty <andre.doherty>
Component: CoreAssignee: Jay Arthanareeswaran <jarthana>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: Olivier_Thomann, satyam.kandula
Version: 3.6Flags: Olivier_Thomann: review+
Target Milestone: 3.6 M6   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch with test jarthana: review?

Description Andre Doherty CLA 2009-11-05 13:07:53 EST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729)
Build Identifier: 20090920-1017

This bug doesn't occur in eclipse 3.4.2.

Dependencies shouldn't be duplicated in the classpath.
Those dependencies are computed in the JavaProject>>resolveClasspath(**) and added to the "resolvedEntries" in JavaProject>>addToResult(**).

The statement resolvedEntries.add(resolvedEntry) should be conditionned to testing against a previous entry.

Therefore the function becomes : 
if (result.rawReverseMap.get(resolvedPath = resolvedEntry.getPath()) == null) {
            result.rawReverseMap.put(resolvedPath, rawEntry);
            result.rootPathToResolvedEntries.put(resolvedPath, resolvedEntry);
            resolvedEntries.add(resolvedEntry);
}

This bug leads to a wrong JavaModelManager.PerProjectInfo per project, leading for instance to a wrong publishing of that project. 
In case of using m2eclipse, this leads to classloading issues when you want to develop an entreprise application, using webapplication, ejb and utility modules shared between those. 








Reproducible: Always

Steps to Reproduce:
1.create an EAR application having one webapplication module
2.use m2eclipse to deal with dependencies
3.add one dependency to ear and war, tag it "optional" in the latest. 
4.publish the project

The dependency is duplicated between ear and war/WEB-INF/lib
Comment 1 Olivier Thomann CLA 2009-11-05 13:14:23 EST
Jay, please investigate.
Comment 2 Jay Arthanareeswaran CLA 2010-02-01 09:34:10 EST
The fix for this will be provided along with bug 252431.
Comment 3 Jay Arthanareeswaran CLA 2010-02-17 12:45:19 EST
Created attachment 159347 [details]
Patch with test

Decoupled the fix for this bug from patch with bug 252431 comment 25. 
Olivier, could you review please?
Comment 4 Jay Arthanareeswaran CLA 2010-02-19 10:22:55 EST
An additional note about the patch - earlier we would allow multiple library entries with same path depending on their other attributes, such as optional, source attachment path etc. But with this patch, when there are entries with the same path, we add only the first entry to the resolved classpath.
Comment 5 Olivier Thomann CLA 2010-02-19 10:25:46 EST
That sounds ok to me. If this is the same library, why would the user set different source or javadoc attachments?
I'll review the patch today.
Comment 6 Olivier Thomann CLA 2010-02-19 10:52:33 EST
Patch looks ok.
Comment 7 Jay Arthanareeswaran CLA 2010-02-22 02:52:39 EST
Released in HEAD for 3.6M6.
Comment 8 Satyam Kandula CLA 2010-03-09 08:21:51 EST
Verified for 3.6M6 using build I20100305-101
Comment 9 Olivier Thomann CLA 2010-03-09 09:30:43 EST
Verified.