[news.eclipse.tools.jdt] Public versus internal interfaces

[Thomas Hallgren <thhal@xxxxxxxxxxxxxx>]

When switching to Eclipse 3.1RC1 I noticed that a new concept "Access 
Rules" has been added so that if one plugin will access an internal 
package of another, a warning is issued. I like and approve very much of 
this concept but it raises a couple of questions.

First an example:
The project I'm working on (Buckminster, an Eclipse Technology 
subproject) sometimes needs to peek into the manifest data of plugins 
that it considers candidates for download in order to determine the 
dependency structure. We don't want to invent the wheel again so we try 
to reuse as much of the existing logic as possible. In particular, we 
don't want to write new manifest parsers for the MANIFEST.MF, 
plugin.xml, feature.xml, etc.

In order to reuse existing logic we use interfaces like the

   org.eclipse.pde.internal.core.ifeature.IFeature

and that, of course, yields a warning since access of this interface is 
"discouraged". Fair enough, but what should we do now? AFAICS I can:

1. Create a new set of parsers that does the exact same thing that the 
existing ones do and then maintain them forever.
2. Try and convince the PDE team that my plugin should be allowed to 
access the internal classes/interfaces. I'm not sure how this works. I 
guess it's controlled by the x-friend construct in the MANIFEST.MF? Is 
there some procedure in place for such requests?
3. Create a fragment project for the PDE-project that I violate that 
modifies the manifest or wraps the internal interfaces in public wrapper 
classes.
4. Simply turn of the warnings. I really don't want to do that.
5. Something else that I've missed altogether?

What would be the recommended course of action? I'm sure this doesn't 
apply just to our project. Many other tools will face the same problem.

Kind regards,
Thomas Hallgren