Community
Participate
Working Groups
Is "Build path contains duplicate entry" really necessary? When two container resolvers add the same jar or dependent project to the target project - the "Build path contains duplicate entry" error is generated. Is this error really necessary? Here're the reasons why this error seems to be superflous: 1) First of all it's a rather superficial check. Currently JDT does nothing (and it probably shouldn't) to point out a jar and a source dependent project (with the same classes), two versions of the same jar or event the same jar in two different locations on the project's build path. These situations pose real problems. 2) Having the same jar or the same project on the project's build path is harmless. I don't think anything bad can come out of this. 3) It'd rather difficult and error-prone for classpath containers to verify that jar/project is already in the build path, especially given that order of classpath container resolution is not known. Based on this, it seems it could be benefitial to relax this restriction and allow several classpath containers to resolve the same jar or project. JDT can simply leave only unique artifacts in the final build path. If this seems like a too dramatic change, this could be configured in the "Preferences > Java > Compiler > Building", something like "Duplicate artifact in the build path" with options of "Error", "Warning" and "Ignore". I ran into several conflicts of this sort with the combination of the following tools: - Maven2 - WTP - PDE Related bug reports: - https://bugs.eclipse.org/bugs/show_bug.cgi?id=154251 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=139241 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=175226 Related bug reports elsewhere: - http://jira.codehaus.org/browse/MNGECLIPSE-106
Why is the severity set to "blocker" ?
I set it to "blocker" b/c it blocked a number of classpath-resolver plugins: Maven2, WTP, etc. Please change to whatever you see appropriate.
Changing severity to enhancement has a new option is needed to control this build path validation.
Re: comment 0 >3) It'd rather difficult and error-prone for classpath containers to verify > that jar/project is already in the build path, especially given that order of > classpath container resolution is not known. The order is the order of the classpath entries on the classpath. Maybe the doc should say it. Feels to me that we could introduce a new preference for duplicate entries on the buildpath, and set it to warning by default (some projects may even turn it off). It is generally a bad practice, and could be ignored. The only consequence is that subsequent lookups are going to perform slower. Interesting cases arise when the 2 entries have the same path but not the same access rules/source attachments etc... maybe in duplication cases, we should only retain the first, and document as such in the resolvedClasspath. Anyhow, this feels advanced changes (3.4 at best).
Re: comment 4 >> The order is the order of the classpath entries on the classpath. >> Maybe the doc should say it. This is correct and this is what I resorted to doing (I had to recompile Maven2 classpath container to move on). Yet, this seems a bit unflexible, b/c if I'd need to have Maven2 container to resolve first for other reasons, I can't modify PDE container to do the same. >> and set it to warning by default (some projects may even turn it Absoluteley agree. Currently Preferences > Java > Compiler > Building has similar options, such as "Incomplete build path" with options "Error", "Warning" and "Ignore" which can also be setup on the project's level. The new option can go here with the "Warning" default. >> The only consequence is that subsequent lookups are going to perform slower. I didn't quite understand this. Why? >> 2 entries have the same path but not the same access rules/source >> attachments etc... maybe in duplication cases, we should only Perhaps it'd be actually better to combine the access pathes. This could be an actual use case, when several resolvers can contribute different parts of the same artifact. It seems to be overkill at first though...
*** This bug has been marked as a duplicate of bug 175226 ***
Verified for 3.5M3 using I20081026-2000
