Skip to main content

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


There was some talk earlier about marking extension points as internal if they are not intended to be public API.  I'm not sure we ever came to a final decision on that.  Are we going to do that?

Larry Dunnell
Internet address: ledunnel@xxxxxxxxxx




                                                                         
           Jeffrey                                                      
           Liu/Toronto/IBM@I                                            
           BMCA                                                       To
           Sent by:                  wtp-dev@xxxxxxxxxxx                
           wtp-dev-admin@ecl                                          cc
           ipse.org                                                      
                                                                 Subject
                                     [wtp-dev] Checklist of things to do
           03/13/2005 01:26          for API definition                  
           PM                                                            
                                                                         
                                                                         
           Please respond to                                            
                wtp-dev                                                  
                                                                         
                                                                         





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

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/wtp-dev



Back to the top