Community
Participate
Working Groups
See also bug 225078 for TCF: In order to be able to continue evolving RSE APIs without breaking binary compatibility, it is extremely important that we document what classes the client is allowed to extend or instantiate, and what interfaces the client is allowed to implement (or just use). Eclipse SDK 3.4M6 comes with API Tooling that defines new Javadoc tags for this markup. Content assist is available for these, so you can just @no<Ctrl+Space> to add the tag: @noextend, @noimplement, @noinstantiate, @noreference See http://wiki.eclipse.org/API_Javadoc_tags http://wiki.eclipse.org/API_Tooling_User_Guide http://wiki.eclipse.org/Api_Tooling As example, ISaveAsDialog should most probably be marked @noimplement. I need each committer to review the APIs that he or she owns and add the markup by M7, since nominally the markup is part of API (even if the Javadoc doesn't change functionality, it does change the contract what clients are allowed to do legally).
Finished so far org.eclipse.rse.core org.eclipse.rse.core.filters org.eclipse.rse.core.model org.eclipse.rse.core.references org.eclipse.rse.logging org.eclipse.rse.persistence org.eclipse.rse.ui.model Still to do from my list org.eclipse.rse.ui.filters org.eclipse.rse.ui.model org.eclipse.rse.ui.subsystems org.eclipse.rse.ui.systems org.eclipse.rse.ui.propertypages (filter aspects)
Finished so far org.eclipse.rse.core org.eclipse.rse.core.filters org.eclipse.rse.core.model org.eclipse.rse.core.references org.eclipse.rse.logging org.eclipse.rse.persistence org.eclipse.rse.ui.model org.eclipse.rse.ui.filters Still to do from my list org.eclipse.rse.ui.subsystems org.eclipse.rse.ui.systems org.eclipse.rse.ui.propertypages (filter aspects)
Finished so far org.eclipse.rse.core org.eclipse.rse.core.filters org.eclipse.rse.core.model org.eclipse.rse.core.references org.eclipse.rse.logging org.eclipse.rse.persistence org.eclipse.rse.ui.model org.eclipse.rse.ui.filters org.eclipse.rse.core.subsystems (in UI plugin) (OK as is) org.eclipse.rse.ui.systems (OK as is) org.eclipse.rse.ui.propertypages.SystemChangeFilterPropertyPage.java (OK as is) org.eclipse.rse.ui.propertypages.SystemFilterStringPropertyPage.java (OK as is)
DaveM -- assigning to you. If you can't get to this now, please pass it on.
Added for: org.eclipse.dstore.core org.eclipse.dstore.core.client org.eclipse.dstore.core.java org.eclipse.dstore.core.miners org.eclipse.dstore.core.model org.eclipse.dstore.core.server org.eclipse.dstore.core.util org.eclipse.dstore.core.util.ssl
Not for M7
Added for: org.eclipse.rse.services.dstore/org.eclipse.rse.dstore.universal.miners
Bulk update of target milestone
Here is a blueprint text for the Javadoc in 3.1, as per bug 187739 comment 15: noimplement - Extending or implementing this interface in client code is strongly discouraged, may break your code in a future major release, and will likely lead to degradation of RSE behavior. noextend - Extending this class in client code is strongly discouraged, may break your code in a future major release, and will likely lead to degradation of RSE behavior. noinstantiate - Instantiating this class in client code is strongly discouraged, may break your code in a future major release, and will likely lead to degradation of RSE behavior.
(In reply to comment #9) Reconsidering this, I think it is unwise not to make use of the automated tooling which the PDE API Tooling gives us through its special markup. I think the right solution is to use the API Tooling markup, but add a message when the markup was added: @noimplement This interface is not intended to be implemented by clients (this message added in RSE 3.0.1). @noextend This class is not intended to be subclassed by clients (this message added in RSE 3.0.1). @noinstantiate This class is not intended to be instantiated by clients (this message added in RSE 3.0.1).
Reassigning all API related to 3.3
Moving 3.3 cleanup items to 3.3.1
