Summary: | [model][classpath] Classpath containers and variable entries | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dimitry E Voytenko <dvoytenko> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dev, ekuleshov, jerome_lanneluc, martinae |
Version: | 3.2 | Keywords: | api |
Target Milestone: | 3.3 M5 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Dimitry E Voytenko
2006-05-16 23:01:06 EDT
This was a design decision from the time we introduced classpath containers; to make them simple, and avoid complex nesting situations (eg. cycles...). Nowadays, we are seeing more and more opportunities where we could improve by removing this limitation. This is why we are considering removing the limitation in next release (3.3). I see. This makes sense. Thanks for the prompt response. How about allowing these containers to have source folder entries? Bug 100508 Martin, if we added the support for nesting containers inside container, would the Package Explorer be affected ? I.e. would you want to show the nested containers as children of the parent container ? Yes, at least the build path dialog and in the package explorer would be affected. Presenting the containers in their nested relationship definitly makes sense. Is there are any chance to support source entries inside container? Can anyone please comment on this? Actually, thinking more about it this would be a breaking change. From the existing API, clients can rightly assume that the only entry kinds returned by IClasspathContainer#getClasspathEntries() are CPE_LIBRARY and CPE_PROJECT. If we add other kinds, the code of this clients will surely break. We are not allowed to break existing clients, so we will not change the existing API and implementation. Jerome, please reconsider. To keep API compatibility you can add another method to container that would allow to return entries other then CPE_LIBRARY and CPE_PROJECT. So, new clients would use that method instead of the old one. Since existing clients implement IClasspathContainer, it is not possible to add a new method to this interface as this would break the binary compatibility. (In reply to comment #9) > Since existing clients implement IClasspathContainer, it is not possible to add > a new method to this interface as this would break the binary compatibility. Jerome, Eclipse already have strategy for dealing with that. One of the popular options is to put new method into new IClasspathContainer2 interface. Verified for 3.3M5 using I20070205-0009. What is verified? Have you actually implemented it? Nobody commented on suggestion to use additional interface... Since it was fixed as WONTFIX, I verified that status is reflected in this build. Jérôme, could you please comment on the comment 10? Eugene, feel free to reopen this bug and provide a patch if this is important for you. |