Community
Participate
Working Groups
Per IClasspathContainer JavaDoc: "... a classpath container can neither reference further classpath containers or classpath variables." What's the reasoning behind this? It's not clear what are the limitations in case of variables. B/c variables are not allowed it's hard to reuse classpath container's entries in the sharable fasion.
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.
