Summary: | Removing "Build path contains duplicate entry" | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dimitry E Voytenko <dvoytenko> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED DUPLICATE | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | mysak, Olivier_Thomann |
Version: | 3.2 | ||
Target Milestone: | 3.5 M3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Dimitry E Voytenko
2007-04-19 19:05:46 EDT
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 |