Skip to main content
Jump to: navigation, search

Difference between revisions of "ECF API Refactoring"

(Assure JRE1.4 as EE for All Plugins: Only base should be J2SE-1.4)
m (Assure JRE1.4 as EE for All Core Plug-ins: Clarification)
Line 72: Line 72:
  
 
<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>
  
 
==Application Refactorings and Rewrites==
 
==Application Refactorings and Rewrites==

Revision as of 00:56, 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

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. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=150756

Status: Not Done

'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

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
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

Application Refactorings and Rewrites

Example Collab Application

Refactor and rewrite org.eclipse.ecf.example.collab plugin. Also need to create RCP app from new set of top-level plugins. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633

Suggested Initial Set of Features:

Copyright © Eclipse Foundation, Inc. All Rights Reserved.