Simon Nash wrote:
Simon Laws wrote:
On Thu, Sep 30, 2010 at 9:06 AM, ant elder <ant.el...@gmail.com> wrote:
On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws
<simonsl...@googlemail.com> wrote:
There is an issue though. The extension meta-data repeats all the
dependencies that base provides. This actually doesn't make a
difference because the duplicates don't have a material impact on the
classpath (other than we might generate a classpath that is too long).
Aesthetically, and possibly for classpath length reasons, though it's
not that pleasing and so it could be useful to know when we're dealing
with extensions to filter our base dependencies from their meta data.
I agree, it would be much nicer if we can get them to only include
their own dependencies so i think we should try to fix that.
...ant
Y, two ways come to mind initially...
1/ We create a pom for each extension and use Maven dependency
mechanisms to exclude base dependencies. Is there a way to do that
simply? I.e. do an exclude for base and all it's transitive
dependencies without having to be explicit. For example, make base a
provided dependency. However I presume that means we need to change
things across the poms in modules to follow this pattern also.
I think this will be difficult if the base is made up of a large number
of jars and poms. AIUI the exlude list would have to name all the poms
in the base. If the list of poms in the base ever changes then all the
exclude lists would have to change as well.
A simple solution would be to create a single jar in the maven repository
called tuscany-sca-base. This could be made up of the contents of a number
of other maven jars but this relationship wouldn't be exposed via maven.
A further thought on this: to make it work, extensions would have to be
built with poms that include tuscany-sca-base and not with poms that
include all the different base components individually. This could be
inconvenient for developers of base components as it would be necessary to
rebuild tuscany-sca-base every time an individual base component changes.
Simon
2/ Alternatively we could rely on bundle plugin like logic which knows
internally what the dependencies are and can filter.
2 is initially attractive as it would be straightforward to implement
however I don't think its the right ways as it hides the process
inside the plugin. Using a pom (1) would seem the most
appropriate/obvious way if we can make it work.
+1
Simon
Simon
