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