Community
Participate
Working Groups
The logic that is used to manage IClasspathEntry objects (configuration within the UI, persistence and evaluation at runtime) is very useful outside of the JDT context (e.g. for other builders) and ideally should be moved from an internal package into the public API so that it can be more easily leveraged by other plugins (might make sense to explore taking the more generalized elements, i.e. support for something like Ant filesets, and moving it into platform).
Wanted to check if folks have any thoughts re: if/when this logic might get moved into a public API? thanks, Rob
These are cross JDT component issues: Core, UI and Launching. What exactly are you interested in ? Most Core aspects are already API, except for persistence which is planned (see bug 110171). Assuming UI aspects are the ones you want, will move it to UI.
I had misread the request for externalizing classpath entries outside JDT. What actual usecase do you have in mind ?
I'm currently leveraging the internal JDT code that configures/evaluates IClasspathEntry objects to support a set of src paths (w/ includes/excludes) for a custom builder. WTP also has some specific use cases, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981
hey Philippe/JDT folks, what's your current thinking in this area? As we start to ramp up for WTP 2.0 there may be an opportunity for WTP to leverage some non-internal JDT functionality in this area (as I indicated in the initial comment, generalized support in this area makes sense at some point at the platform level so that should also be considered...)
Rob - could you provide a patch for previewing what you have in mind for this API to look like ? Classpath entry semantics are widespread between various components.
