Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Dali Discouraged Access Warnings"
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
For background, see | For background, see | ||
*[[DTP Ganymede Resolving Discouraged Access Warnings]] | *[[DTP Ganymede Resolving Discouraged Access Warnings]] | ||
Line 6: | Line 4: | ||
*[[WTP API Policy]] | *[[WTP API Policy]] | ||
− | Currently, Dali has four | + | Currently, Dali has four types of ''Discouraged Access'' warnings to deal with: |
*'''Internal ''Discouraged Access'' Warnings''' | *'''Internal ''Discouraged Access'' Warnings''' | ||
− | **'''Non-Test Plug-ins''' <br> We add non-test plug-ins as "friends" of other non-test plug-ins, ''as appropriate'' (e.g. ''all'' the non-test plug-ins are friends of <code>o.e.jpt.'''utility'''</code>; while ''none'' of the plug-ins are friends of <code>o.e.jpt.'''ui'''</code>). | + | **'''Non-Test Plug-ins''' <br> We add non-test plug-ins as "friends" of other non-test plug-ins, ''as appropriate'' (e.g. ''all'' the non-test generic plug-ins are friends of <code>o.e.jpt.common.'''utility'''</code>; while ''none'' of the plug-ins are friends of <code>o.e.jpt.jpa.'''ui'''</code>). |
**'''Test Plug-ins''' <br> Because test plug-ins are not loaded at run-time, there is no need to make them friends of the non-test plug-ins. To suppress the ''Discouraged Access'' warnings in a test plug-in, we add the ''appropriate'' build-time access rule exceptions to the project's Java build path (e.g. <code>o.e.jpt.core.tests</code> suppresses any access warnings caused by references to <code>o.e.jpt.core</code>). See [[DTP Resolving Internal Discouraged Access Warnings|the DTP description of this Eclipse feature]]. | **'''Test Plug-ins''' <br> Because test plug-ins are not loaded at run-time, there is no need to make them friends of the non-test plug-ins. To suppress the ''Discouraged Access'' warnings in a test plug-in, we add the ''appropriate'' build-time access rule exceptions to the project's Java build path (e.g. <code>o.e.jpt.core.tests</code> suppresses any access warnings caused by references to <code>o.e.jpt.core</code>). See [[DTP Resolving Internal Discouraged Access Warnings|the DTP description of this Eclipse feature]]. | ||
***'''NB:''' The test "extension" plug-in, <code>o.e.jpt.core.test.extension.resource</code>, ''should'' be using the Dali public API; but see the EclipseLink plug-ins discussion below. | ***'''NB:''' The test "extension" plug-in, <code>o.e.jpt.core.test.extension.resource</code>, ''should'' be using the Dali public API; but see the EclipseLink plug-ins discussion below. | ||
+ | **'''UI Plug-ins''' <br> The Dali UI plug-ins should be using the ''public'' Core API; but we still have a number of places where the UI plug-ins are using internal Core API. In most of these situations the code in the Core plug-in should be moved to the UI plug-in. | ||
− | *'''EclipseLink plug-ins ''Discouraged Access'' Warnings''' <br> | + | *'''Dali EclipseLink plug-ins ''Discouraged Access'' Warnings''' <br> |
In theory the EclipseLink plug-ins, <code>o.e.jpt.eclipselink.*</code>, should ''not'' add any access rule exceptions to their projects' Java build paths, since these plug-ins, as exemplary extensions, ''should'' be using only Dali's public API. But, in practice, when extending Dali it is much easier (though riskier) to use and/or subclass the Dali internal classes etc. | In theory the EclipseLink plug-ins, <code>o.e.jpt.eclipselink.*</code>, should ''not'' add any access rule exceptions to their projects' Java build paths, since these plug-ins, as exemplary extensions, ''should'' be using only Dali's public API. But, in practice, when extending Dali it is much easier (though riskier) to use and/or subclass the Dali internal classes etc. | ||
Line 23: | Line 22: | ||
*'''External ''Discouraged Access'' Warnings''' | *'''External ''Discouraged Access'' Warnings''' | ||
Because Dali is so tightly integrated with the Eclipse Java IDE, it references the internals of a number of other Eclipse plug-ins, particularly JDT plug-ins. A bug should be filed for each such warning, requesting the appropriate API be made public. Although these warnings could be suppressed (e.g. using the access rule exceptions described above or a Java annotation <code>@SuppressWarnings("restriction")</code>), it is more helpful to leave them visible and commented with a bug number. See [[Dali Access Warning Documentation]]. | Because Dali is so tightly integrated with the Eclipse Java IDE, it references the internals of a number of other Eclipse plug-ins, particularly JDT plug-ins. A bug should be filed for each such warning, requesting the appropriate API be made public. Although these warnings could be suppressed (e.g. using the access rule exceptions described above or a Java annotation <code>@SuppressWarnings("restriction")</code>), it is more helpful to leave them visible and commented with a bug number. See [[Dali Access Warning Documentation]]. | ||
− | |||
− | |||
− |
Latest revision as of 18:36, 9 March 2011
For background, see
Currently, Dali has four types of Discouraged Access warnings to deal with:
- Internal Discouraged Access Warnings
- Non-Test Plug-ins
We add non-test plug-ins as "friends" of other non-test plug-ins, as appropriate (e.g. all the non-test generic plug-ins are friends ofo.e.jpt.common.utility
; while none of the plug-ins are friends ofo.e.jpt.jpa.ui
). - Test Plug-ins
Because test plug-ins are not loaded at run-time, there is no need to make them friends of the non-test plug-ins. To suppress the Discouraged Access warnings in a test plug-in, we add the appropriate build-time access rule exceptions to the project's Java build path (e.g.o.e.jpt.core.tests
suppresses any access warnings caused by references too.e.jpt.core
). See the DTP description of this Eclipse feature.- NB: The test "extension" plug-in,
o.e.jpt.core.test.extension.resource
, should be using the Dali public API; but see the EclipseLink plug-ins discussion below.
- NB: The test "extension" plug-in,
- UI Plug-ins
The Dali UI plug-ins should be using the public Core API; but we still have a number of places where the UI plug-ins are using internal Core API. In most of these situations the code in the Core plug-in should be moved to the UI plug-in.
- Non-Test Plug-ins
- Dali EclipseLink plug-ins Discouraged Access Warnings
In theory the EclipseLink plug-ins, o.e.jpt.eclipselink.*
, should not add any access rule exceptions to their projects' Java build paths, since these plug-ins, as exemplary extensions, should be using only Dali's public API. But, in practice, when extending Dali it is much easier (though riskier) to use and/or subclass the Dali internal classes etc.
NB: The "base" Dali plug-ins do not list the EclipseLink plug-ins as x-friends; so we add the appropriate access rule exceptions to the EclipseLink plug-ins.
- WTP Discouraged Access Warnings
As a sub-project of WTP, Dali, ostensibly, is allowed access to the internals of any other WTP sub-project. This requires the appropriate WTP plug-ins to add various Dali plug-ins to their lists of "friends". Since this does not always happen in a timely fashion, we add access rule exceptions as necessary. Currently, only o.e.jpt.core
and o.e.jpt.ui
require these exceptions.
- External Discouraged Access Warnings
Because Dali is so tightly integrated with the Eclipse Java IDE, it references the internals of a number of other Eclipse plug-ins, particularly JDT plug-ins. A bug should be filed for each such warning, requesting the appropriate API be made public. Although these warnings could be suppressed (e.g. using the access rule exceptions described above or a Java annotation @SuppressWarnings("restriction")
), it is more helpful to leave them visible and commented with a bug number. See Dali Access Warning Documentation.