FYI: There is an maven eclipse plugin that can be used to generate maven
dependency graph.
http://m2eclipse.sonatype.org/
Thanks,
Raymond
--------------------------------------------------
From: "kelvin goodson" <[email protected]>
Sent: Thursday, March 11, 2010 9:22 AM
To: <[email protected]>
Subject: Re: [2.x] SPI documentation, testing and tracking
I started investigating the dependencies of the binding modules, as a
starty in breaking this down and understanding the bigger picture. I
put a graph of this on the wiki [1] -- I plan to do the same for the
other extension types.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPI+Investigations
On Wed, Mar 10, 2010 at 3:56 PM, Simon Laws <[email protected]>
wrote:
On Wed, Mar 10, 2010 at 1:53 PM, kelvin goodson <[email protected]>
wrote:
There's a first output from my endeavours at [1]
I haven't checked the output, but how does this generally fit the bill?
Kelvin
[1] http://people.apache.org/~kelvingoodson/digests/out.xml
Nice. As a short term measure we can tell which code has changed
easily without having to revert to looking up each file in the svn
log. We need to filter it down a bit though.
What we do need to do is be more precise about what we mean about SPI.
Probably down to the level of classes we expect people to extend vs
classes we expect people to call.
A way of attacking this would be to take each of the extension types in
turn;
SCA specific ones
--------------------------
binding
implementation
interface
policy
Tuscany runtime specific ones
---------------------------------------------
databinding
contribution
host
monitor
extensibility
endpointregistry
etc.
And look at which SPI like classes are used in each case. Then rather
than just having a long list of SPI packages/classes which is
difficult to understand at least we could identify those used when
creating a particular extension type.
So, for example, we could take a binding like binding.ws (it's
relatively interesting) and look at it's dependencies. Obviously there
are dependencies between the modules starting binding-ws-xxx however
we are interested in the other, non-atom, Tuscany dependencies. We can
ignore all the 3rd party and test dependencies. So the list I see for
binding-ws (produced with mvn dependency:tree) is
[INFO] org.apache.tuscany.sca:tuscany-binding-ws:jar:2.0-SNAPSHOT
[INFO] +-
org.apache.tuscany.sca:tuscany-contribution:jar:2.0-SNAPSHOT:compile
[INFO] | +-
org.apache.tuscany.sca:tuscany-assembly:jar:2.0-SNAPSHOT:compile
[INFO] | | \-
org.apache.tuscany.sca:tuscany-monitor:jar:2.0-SNAPSHOT:compile
[INFO] | +-
org.apache.tuscany.sca:tuscany-assembly-xsd:jar:2.0-SNAPSHOT:compil
e
[INFO] | +-
org.apache.tuscany.sca:tuscany-extensibility:jar:2.0-SNAPSHOT:compi
le
[INFO] | +-
org.apache.tuscany.sca:tuscany-common-xml:jar:2.0-SNAPSHOT:compile
[INFO] | \-
org.apache.tuscany.sca:tuscany-common-java:jar:2.0-SNAPSHOT:compile
[INFO] | \-
org.apache.tuscany.sca:tuscany-sca-api:jar:2.0-SNAPSHOT:compile
[INFO] +-
org.apache.tuscany.sca:tuscany-assembly-xml:jar:2.0-SNAPSHOT:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:comp
ile
[INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.4:runtime
[INFO] +-
org.apache.tuscany.sca:tuscany-interface-wsdl:jar:2.0-SNAPSHOT:compile
[INFO] | +- org.apache.tuscany.sca:tuscany-xsd:jar:2.0-SNAPSHOT:compile
[INFO] | \- org.apache.ws.commons.schema:XmlSchema:jar:1.4.3:compile
[INFO] +- wsdl4j:wsdl4j:jar:1.6.2:compile
[INFO] +- org.apache.tuscany.sca:tuscany-builder:jar:2.0-SNAPSHOT:test
[INFO] +- org.apache.tuscany.sca:tuscany-core:jar:2.0-SNAPSHOT:test
[INFO] | +-
org.apache.tuscany.sca:tuscany-core-spi:jar:2.0-SNAPSHOT:test
[INFO] | +-
org.apache.tuscany.sca:tuscany-interface-java:jar:2.0-SNAPSHOT:test
[INFO] | +- cglib:cglib:jar:2.2:test
[INFO] | \- asm:asm:jar:3.1:test
[INFO] +-
org.apache.tuscany.sca:tuscany-binding-sca-runtime:jar:2.0-SNAPSHOT:te
st
[INFO] | \-
org.apache.tuscany.sca:tuscany-databinding:jar:2.0-SNAPSHOT:test
[INFO] \- junit:junit:jar:4.8.1:test
Extracting the real dependencies gives
tuscany-contribution - processor and resolver base classes
tuscany-assembly - assembly models
tuscany-monitor - error reporting
tuscany-assembly-xsd - model schema (don't know why it needs this here)
tuscany-extensibility - locating extension points
tuscany-common-xml - xml utilities
tuscany-common-java - java utilities
tuscany-sca-api - the SCA api (don't know why it needs this here,
possibly for annotations)
tuscany-assembly-xml - processor base classes
tuscany-interface-wsdl - models WSDL interfaces
tuscany-xsd - models schema
If you look across the bindings it would be nice to think a pattern
emerges.
Ultimately we'll end up with a list again of course but well be able
to add more detail about what each of the SPIs is for.
Simon
