Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DTP Ganymede Resolving Discouraged Access Warnings"

Line 22: Line 22:
 
Ideally we'd like to make use of the ''x-friend'' directive for plug-in manifests. Rather than setting certain packages to "internal," we would specify the exceptions ("friends") to default internal visibilty. Since there are a large number of DTP plug-ins, and this number is changing over time, we would like to use a pattern here: something like ''x-friend=org.eclipse.datatools.*'' to indicate that any ''org.eclipse.datatools'' code can free use other ''org.eclipse.datatools'' code. Unfortunately, this is not possible: the ''x-friend'' directive requires listing each "friend" bundle, and hence is not a good solution for DTP.
 
Ideally we'd like to make use of the ''x-friend'' directive for plug-in manifests. Rather than setting certain packages to "internal," we would specify the exceptions ("friends") to default internal visibilty. Since there are a large number of DTP plug-ins, and this number is changing over time, we would like to use a pattern here: something like ''x-friend=org.eclipse.datatools.*'' to indicate that any ''org.eclipse.datatools'' code can free use other ''org.eclipse.datatools'' code. Unfortunately, this is not possible: the ''x-friend'' directive requires listing each "friend" bundle, and hence is not a good solution for DTP.
  
We can, however, at least filter the ''Discouraged Access'' warnings at build time, giving us a clearer picture of warnings we should be addressing and allow us (if we wish) to choose error severity when reporting this class of warnings. Eclipse supports this type of build-time filtering, as described on a [[WTP:_Consumer_Control_of_Access_Rules | WTP wiki page]].
+
We can, however, at least filter the ''Discouraged Access'' warnings at build time, giving us a clearer picture of warnings we should be addressing and allow us (if we wish) to choose error severity when reporting this class of warnings. Eclipse supports this type of build-time filtering, as described on a [[WTP:_Consumer_Control_of_Access_Rules | WTP wiki page]]. While WTP suggests that the filters be as specific as possible, for the DTP policy, it will be acceptable to have one catch-all filter: "org/eclipse/datatools/**". Thus, the steps for each DTP plug-in owner who has '''internal''' ''Discouraged Access'' warnings is to add the above filter to the plug-in project's build configuration.
  
 
====Resolving External ''Discouraged Access'' Warnings====
 
====Resolving External ''Discouraged Access'' Warnings====

Revision as of 11:42, 24 August 2007

Back to DTP Main Page

Document Status

[8/24/07]: This document is a draft and should not be taken as offical until reviewed and approved by the DTP PMC and project leads.

Overview

As described in the DTP Ganymede Project Plan, a main goal of DTP Ganymede is to resolve as many Discouraged Access warnings in the DTP code line as possible. The reasoning and general process for doing this is outlined in the DTP Ganymede Development Guildlines. The purpose of this page is to collect specific information about how these Discouraged Access warnings will be resolved.

Current Status

A check of DTP HEAD at the beginning of August, 2007, reveals a large number of Discouraged Access warnings. We will call a Discouraged Access warning internal if the reference is within DTP itself, and external otherwise. Using this distinction, we find:

  • About 1800 internal warnings
  • About 160 external warnings

Resolution of Warnings

While there are a large number of Discouraged Access warnings, fortunately the vast majority of these are internal. Since we have decided that DTP components can freely use code among themselves, this means that most of the Discouraged Access warnings are really not a problem. Hence, we only need to find a way of indicating, in project and/or plug-in meta-data, that no Discouraged Access warning should be registered for org.eclipse.datatools.* classes using org.eclipse.datatools.* code.

Resolving Internal Discouraged Access Warnings

Ideally we'd like to make use of the x-friend directive for plug-in manifests. Rather than setting certain packages to "internal," we would specify the exceptions ("friends") to default internal visibilty. Since there are a large number of DTP plug-ins, and this number is changing over time, we would like to use a pattern here: something like x-friend=org.eclipse.datatools.* to indicate that any org.eclipse.datatools code can free use other org.eclipse.datatools code. Unfortunately, this is not possible: the x-friend directive requires listing each "friend" bundle, and hence is not a good solution for DTP.

We can, however, at least filter the Discouraged Access warnings at build time, giving us a clearer picture of warnings we should be addressing and allow us (if we wish) to choose error severity when reporting this class of warnings. Eclipse supports this type of build-time filtering, as described on a WTP wiki page. While WTP suggests that the filters be as specific as possible, for the DTP policy, it will be acceptable to have one catch-all filter: "org/eclipse/datatools/**". Thus, the steps for each DTP plug-in owner who has internal Discouraged Access warnings is to add the above filter to the plug-in project's build configuration.

Resolving External Discouraged Access Warnings

Copyright © Eclipse Foundation, Inc. All Rights Reserved.