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 "ECF API Refactoring"
m (ECF Refactoring moved to API Refactoring) |
(removed section on Application refactoring, since that is to get a page of its own) |
||
Line 77: | Line 77: | ||
<div style="border: 2px solid #8E87EB; padding: 6px;">This isn't necessarily correct as not all plug-ins should be J2SE-1.4 compliant (this is an awkward case since the issue is over a provider's library). Per the discussions on the dev-list, a provider should be allowed to be whatever EE it wants. I have renamed the header as "All Core Plug-ins" instead of "All Plugins". ''--Remy Suen''</div> | <div style="border: 2px solid #8E87EB; padding: 6px;">This isn't necessarily correct as not all plug-ins should be J2SE-1.4 compliant (this is an awkward case since the issue is over a provider's library). Per the discussions on the dev-list, a provider should be allowed to be whatever EE it wants. I have renamed the header as "All Core Plug-ins" instead of "All Plugins". ''--Remy Suen''</div> | ||
<div style="border: 2px solid #8E87EB; padding: 6px;">Reading it over, I guess my statement above makes the bug I filed invalid since if a provider plug-in can be whatever EE is necessary, then there is no need to change the Smack library's compiler compliance down to 1.4. I guess the point here is that plug-ins should be consistent in their MANIFEST.MF and compiler settings. Since the Smack library can run on J2SE-1.4 and does not use 5.0 features (generics, foreach, etc.), then the entire project's settings should be set to J2SE-1.4. If it were to need J2SE-1.5, then both the MANIFEST.MF EE and the compiler should be set as such. Inconsistent settings creates confusion for everyone. ''--Remy Suen''</div> | <div style="border: 2px solid #8E87EB; padding: 6px;">Reading it over, I guess my statement above makes the bug I filed invalid since if a provider plug-in can be whatever EE is necessary, then there is no need to change the Smack library's compiler compliance down to 1.4. I guess the point here is that plug-ins should be consistent in their MANIFEST.MF and compiler settings. Since the Smack library can run on J2SE-1.4 and does not use 5.0 features (generics, foreach, etc.), then the entire project's settings should be set to J2SE-1.4. If it were to need J2SE-1.5, then both the MANIFEST.MF EE and the compiler should be set as such. Inconsistent settings creates confusion for everyone. ''--Remy Suen''</div> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 18:58, 16 October 2006
Prior to 1.0, ECF will be going through a concerted API and exemplary app refactoring effort. See below for list of desired refactorings and current state
Contents
- 1 API Refactorings
- 1.1 Split org.eclipse.ecf Core Plugin into 2 or 3 Plugins--LARGE
- 1.2 Add Bulletin Board API to ECF Plugins and Features--LARGE
- 1.3 Create filetransfer plugin, remove fileshare plugin
- 1.4 'Low-end' Execution Environment Support
- 1.5 Add 'removeListener' methods
- 1.6 Streamline ClientSOContainer
- 1.7 Move IInvitationListener
- 1.8 Introduce Convention for Container Adapters
- 1.9 Assure JRE1.4 as EE for All Core Plug-ins
API Refactorings
Split org.eclipse.ecf Core Plugin into 2 or 3 Plugins--LARGE
Refactor org.eclipse.ecf plugin into 2 or 3 plugins. This is a large refactoring effort. See discussion thread on mailing list: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00399.html
Status: Not Done
Add Bulletin Board API to ECF Plugins and Features--LARGE
Add Bulletin Board API. Remove EE 1.5 dependencies See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=150756
Status: Not Done
Remove org.eclipse.ecf.fileshare API packages and classes. Create a new plugin: org.eclipse.ecf.filetransfer.
'Low-end' Execution Environment Support
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=149024
Problem: Dependency on javax.security.auth.callback.* classes. These classes are not available in Framework 1.1 (they are part of the JAAS classes that are optional for F1.1)
Removed ECF core and all provider references to classes
javax.security.auth.callback.Callback; javax.security.auth.callback.CallbackHandler; javax.security.auth.callback.NameCallback; javax.security.auth.callback.UnsupportedCallbackException;
Status: DONE
Explanation: Added new classes and changed existing references to above classes to classes in ECF org.eclipse.ecf.core.security package:
org.eclipse.ecf.core.security.Callback; org.eclipse.ecf.core.security.CallbackHandler; org.eclipse.ecf.core.security.NameCallback; org.eclipse.ecf.core.security.UnsupportedCallbackException;
Add 'removeListener' methods
Add removeListener methods in IChatRoomContainer (and in IPresenceContainer). Also check other listener add and check for availability of remove methods. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160968
Status: Not Done
Streamline ClientSOContainer
Streamline handling of creating/passing in connect data for new kind of authentication. See : https://bugs.eclipse.org/bugs/show_bug.cgi?id=150398
Status: Not Done
Move IInvitationListener
Move (in presence API) access to IInvitationListener to IChatRoomManager rather than IPresenceContainer. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160137
Status: Not Done
Introduce Convention for Container Adapters
Change all occurrences of I<whatever>Container that are intended to be used as adapters off of IContainer (via IContainer.getAdapter(I<whatever>Container) to have the following naming convention:
Was: I<whatever>Container Will be: I<whatever>ContainerAdapter
This way, it should be more obvious which interface in a given API plugin is the container adapter that should be use for the call to IContainer.getAdapter
Status: Not Done
Assure JRE1.4 as EE for All Core Plug-ins
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160805