>>>
>>> Well it would work ok if the "base" remained as an "pom" type pom
>>> which just groups together other modules. The only time this would
>>> need rebuilding would be when the set of dependency jars change. Which
>>> isn't very often.
>>>
>>> The question then remains whether you can exclude the dependencies
>>> without unnecessarily arduous exclude editing.
>>>
>>> The other drawback of this is that Ant found problems when depending
>>> on this pom type pom in order to build aggregate jars. I can't
>>> remember precisely what the problem was off the top of my head.
>>>
>>> So it needs some experimentation to see what really can be made to work.
>>>
>>
>> I've looked at this before and I don't think there is an easy
>> non-arduous way to do the excludes. The simplest solution to me is to
>> have the extensions use provided scope for the base dependencies.
>>
>> ...ant
>>
>>
> This approach seems OK to me.
>
> Simon
>
>
So to be more concrete what were looking at is having
tuscany-base-runtime defined something like....
<artifactId>tuscany-base-runtime</artifactId>
<name>Apache Tuscany SCA Base Runtime</name>
<packaging>pom</packaging>
<!--
The dependencies required to run the Assembly otests minus
the web service
binding (which is only required by the otest framework).
Provides a minimum
set of function for running composites using
implementation.java and local
wiring. Other extensions can be added to this base when required
-->
<dependencies>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-assembly</artifactId>
<version>${pom.version}</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-assembly-xml</artifactId>
<version>${pom.version}</version>
</dependency>
etc.
Then an extension, for example, binding-rmi, would be defined like....
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-modules</artifactId>
<version>2.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>tuscany-binding-rmi</artifactId>
<name>Apache Tuscany SCA RMI Binding Model</name>
<dependencies>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-base-runtime</artifactId>
<version>2.0-SNAPSHOT</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
It's then very easy to tweak the bundle plugin to take notice of the
provided dependency and omit it from the meta-data, e.g. the
tuscany-base-runtime which-jars list is...
jaxb-api-2.1/jaxb-api-2.1.jar
tuscany-policy-security-2.0-SNAPSHOT.jar
tuscany-assembly-xml-2.0-SNAPSHOT.jar
jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar
tuscany-common-xml-2.0-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-SNAPSHOT.jar
tuscany-databinding-jaxb-2.0-SNAPSHOT.jar
tuscany-node-impl-osgi-2.0-SNAPSHOT.jar
tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar
activation-1.1/activation-1.1.jar
tuscany-core-spi-2.0-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar
jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar
tuscany-binding-ws-2.0-SNAPSHOT.jar
tuscany-builder-2.0-SNAPSHOT.jar
XmlSchema-1.4.3.jar
tuscany-sca-api-2.0-SNAPSHOT.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
jetty-6.1.19.jar
services-3.2.0-v20090520-1800.jar
tuscany-monitor-2.0-SNAPSHOT.jar
tuscany-host-http-2.0-SNAPSHOT.jar
jsr250-api-1.0/jsr250-api-1.0.jar
jetty-util-6.1.19.jar
tuscany-databinding-2.0-SNAPSHOT.jar
asm-3.1/asm-3.1.jar
tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar
tuscany-node-launcher-2.0-SNAPSHOT.jar
tuscany-implementation-java-2.0-SNAPSHOT.jar
tuscany-deployment-2.0-SNAPSHOT.jar
tuscany-contribution-2.0-SNAPSHOT.jar
tuscany-core-2.0-SNAPSHOT.jar
tuscany-node-impl-2.0-SNAPSHOT.jar
tuscany-xsd-2.0-SNAPSHOT.jar
cglib-2.2/cglib-2.2.jar
wstx-asl-3.2.6/wstx-asl-3.2.6.jar
tuscany-extensibility-2.0-SNAPSHOT.jar
tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar
tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar
tuscany-node-api-2.0-SNAPSHOT.jar
tuscany-extensibility-equinox-2.0-SNAPSHOT.jar
jaxws-api-2.1/jaxws-api-2.1.jar
servlet-api-2.5/servlet-api-2.5.jar
tuscany-core-databinding-2.0-SNAPSHOT.jar
tuscany-contribution-osgi-2.0-SNAPSHOT.jar
tuscany-assembly-2.0-SNAPSHOT.jar
tuscany-assembly-xsd-2.0-SNAPSHOT.jar
wsdl4j-1.6.2/wsdl4j-1.6.2.jar
tuscany-implementation-osgi-2.0-SNAPSHOT.jar
osgi-3.5.0-v20090520.jar
tuscany-host-jetty-2.0-SNAPSHOT.jar
tuscany-common-java-2.0-SNAPSHOT.jar
commons-cli-1.2.jar
tuscany-interface-java-2.0-SNAPSHOT.jar
while the binding-rmi-runtime which-jars list is....
Jars required to enable extension: tuscany-binding-rmi-runtime
tuscany-host-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar
Which is a bit shorter than it was (and not very interesting for rmi).
Now I don't really know yet what issues are lurking in modules by doing this.
For example, we have test dependencies of extensions which change to
being provided dependencies and dependending on base will imply more
dependencies that is absolutely necessary but at least it's
consistent.
I haven't tried using the project in eclipse.
Also I don't know if this makes it any harder to do other things with
the extension such as make an aggregate jar.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
