Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Checklist of things to do for API definition


To help us complete our API definition work for M4, I thought a checklist of things to do may be helpful...

1. I think we have a lot of APIs that are suppose to be internal, but aren't. For these APIs, all we need to do is put them into an internal package. We now have an API usage report that shows all the APIs for a component and who in WTP is using them. Here's the URL to the N20050313's usage report:

http://download.eclipse.org/webtools/downloads/drops/N-N20050313-200503130647/apitools/index-api-uc.html

APIs flagged with a red X means nobody in WTP is using them. These APIs are candidate for removal unless they have customers outside of WTP, or they are designed for public consumption. I suggest we review all APIs with a red X and remove the ones that we don't need. Removing these APIs should be easy because nobody is using them, but just to be safe, you may still want to send an email to the mailing list.

2. I'm sure at some point, you'll run into an API that you want to remove, but somebody in WTP is using it. The API usage report tells you exactly who that is. So you can coordintate the changes. I suggest we do item 1 and 2 early on because we don't want anybody to start using APIs that are going away. Also, WTP components higher up in the stack will need time to react to API changes.

Let's not forget, when you change/remove an API, our junit tests may be affect as well. For that, you can look at the junit test coverage report to see whether your API is being used by a junit test:

http://download.eclipse.org/webtools/downloads/drops/N-N20050313-200503130647/apitools/index-api-tc.html

3. We need to javadoc our APIs. We have an Javadoc coverage report that shows you APIs that have incomplete javadocs. Here's the URL to the report:

http://download.eclipse.org/webtools/downloads/drops/N-N20050313-200503130647/apitools/index-api-javadoc.html

The goal here is to get the number of incomplete javadocs down to zero.

4. We need to junit our APIs. You can use the junit test coverage report to see which APIs are not currently tested. Again, the goal is to get the number of untested APIs down to zero. Here's the URL to the junit test coverage report:

http://download.eclipse.org/webtools/downloads/drops/N-N20050313-200503130647/apitools/index-api-tc.html

5. Let's not forget, we need to define our component.xml files. Right now, new component.xml files are generated in every build based on the default Eclipse naming convention. However, we need a way to tell our customers the allowed usage of our APIs. For example, can we implement this interface, can we subclass, etc... Our earlier consent is to put these component.xml files into any of the plugins that the component owns. If you need a sample component.xml to get you started, let me know which component you are looking for and I can send it to you.

If you have other API related work items that you want to share, please append to this thread. Thanks for everyone's time.

Jeffrey Liu
IBM Rational Software - Performance Analyst
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/R8V/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920
jeffliu@xxxxxxxxxx

Back to the top