Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Some more arch/design observations

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



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

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
      <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="" export="true"/>

Yikes ... not the dreaded 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.)

Back to the top