Ok. I added a feature request for this:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=98252
It immediately got resolved to "LATER". Not sure what that means but it
doesn't look as I would get a resolution for my problem anytime soon.
I also added two others for related (platform) problems:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=98253
http://bugs.eclipse.org/bugs/show_bug.cgi?id=98255
Regards,
Thomas Hallgren
Jerome Lanneluc wrote:
Thomas,
The best way would be to enter a feature request against PDE to have
the interfaces moved to a public package. If this request is accepted,
they would then become API and you could access them without getting a
discouraged warning.
Jerome
Thomas Hallgren wrote:
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