Community
Participate
Working Groups
This is an API request and something I think was just over looked. The current org.eclipse.wst.common.uriresolver.resolverExtensions is an API extension point for adding Custom Resolvers to help resolve grammars and xml files, however, the implementing interface that adopters are to implement is currently resides in an Internal package. The URIResolverExtension should be made API. Yes this will break many current Adopters, but it should be done to follow eclipse API guidelines.
This would be best done in a new release, with the internal version being deprecated. Targetting to WTP 3.3 M6 since that is the API cutoff, and assigning to Keith Chong for the initial investigation.
The current extension is in the internal provisional package.
Which means the *only* way to use the framework at all is to make use of internals.
Correct, and I'd rather have true API instead of provisional, and it's been Provisional for years. I think it is time to graduate it our get rid of it.
See also bug 88014.
Bug 172412 is also interesting in that it discusses URI classes. The URI resolver plug-in has its own URI class and various URI utilities.
I've been looking through the code recently and I've jotted down some potential improvements that could/should be done while cleaning this plug-in up for API: - URI resolver extension schema could spell out the allowed values for the stage attribute using restrictions - projectNature, value is a string, should perhaps be made an IDREF pointing to the nature ID. - there some strangeness in org.eclipse.wst.common.uriresolver.internal.ExtensibleURIResolver.computeFile(String) in using getFileForLocation() I'm sure there's more to be done to clean-up this code. Hope this helps.
Have to defer this out. It is possible that supporting EFS may require these provisional APIs to change.....or there may be new APIs added.
