[wtp-dev] Some more arch/design observations

[David M Williams <david_williams@xxxxxxxxxx>]

Continuing in the spirit of "group
learning" (including my own) ... thought I'd post a few observations.


First, I started looking at some plugin
dependancies today, and the first thing I found was that many plugins have
pre-reqs in them that are not needed. (I sampled about 6, and half of those
had extra prereqs ... one with 19 extra prereqs!  I don't completely
trust that auto-checking , so will leave it up to each team to fix their
own pre-reqs, but just was hoping that could be done soon, say by this
weeks I-build, since that makes it much easier to explore/review relationships.


Second, I'll add a new "WTP Development
Practice" that says, basically, 

"Tend to not use the export="true"
attribute on pre-req plugins. Its never appropriate to use it just so your
upstream clients save typing a line in their plugin.xml file. But, sometimes
it is appropriate to use it -- when the classes/interfaces in pre-req plugin
really are part of the pre-reqing plugins API. If it fits this later case,
please, that is it is part of the plugins API, please document what that
is." [Example below]

So, here's some detailed thoughts on
those plugins that have export="true". 

1.

org.eclipse.wst.rdb.models.dbdefinition
org.eclipse.wst.rdb.models.sql

both contain a pre-req as

<import
plugin="org.eclipse.emf.ecore"
export="true"/>

My thought on this is that emf should
never be part of a model's API .. I think of EMF as a way to 
implement models, but should not rise
so close to the surface that client users (co-developers) should 
have to worry (or know) about how the
model is implemented. 

So .. are there plans for these to do
away with their export? Or, am I missing some good reason to export them?

2. 

org.eclipse.wst.common.ui.properties
- 

exports 4 plugins. I could imagine these
are needed by the interface for
clients (would be nice to not to, but
would appreciated the team checking and documenting what API they are part
of. )
(And, remember, shouldn't be just "for
convenience". 

     
<import plugin="org.eclipse.ui.forms"
export="true"/>
      <import
plugin="org.eclipse.ui.ide"
export="true"/>
      <import
plugin="org.eclipse.ui.views"
export="true"/>
      <import
plugin="org.eclipse.ui"
export="true"/>



3. Here's a really, really great example
where some team has documented where the export is logically required by
the interface provided (found in org.eclipse.wst.sse.core :)

         
      <!--
need to re-export org.eclipse.text since our API depends on it, 
     
               
  such as IStructuredDocument extends IDocument 
     
          -->
      <import
plugin="org.eclipse.text"
export="true"/>

         
      <!--
need to re-export emf.common since our API depends on it, 
     
               
  such as StructuredTextUndoManager's getCommmand method returns
an
     
               
  emf.common.Command
     
          -->
      <import
plugin="org.eclipse.emf.common"
export="true"/>


4. org.eclipse.jst.ejb.ui
hard to imagine an API
here ... but, I'd be the last to know. 

<import
plugin="org.eclipse.jst.j2ee.ui"
export="true"/>



5. org.eclipse.wst.common.frameworks

 <import
plugin="com.ibm.wtp.common.util"
export="true"/>

Yikes ... not the dreaded
com.ibm.wtp.common.util
again. I'm sure its not part of any
API! (Chuck and I have
an on going joke of sorts, since I'm obsessive about not wanting this "logging
utility" function to end up being one of our APIs, and he agrees he
thinks can eventually get rid of it -- in the mean time, I wouldn't export
it, since some upstream clients might not know they are using it, and could
go ahead and make other plans.)