What are the things that are not completely trivial? It might be a warning
sign that the "merge" is complicating the dependencies.
If you can share one or two examples, we can discuss how we handle them in
concrete context.
We probably have to think about the modularity in a broader view. Sure, if
it's just for our standalone runtime, we can organize the
code in anyway we want. But taking the usage patterns from tools and other
vendors that want to reuse/embed Tuscany.
Some of the problems are related to how we use different scopes of the maven
modules as well as the transitive dependencies. For
example, we could have two different implementation for binding.ws (Axis2 or
JAX-WS), or two different HTTP hosts (Jetty or Tomcat).
To test a web service, we could choose one of them as the "test"
dependencies instead of "compile" or "runtime" dependency. Being careful
about the pom.xml will help us to minimize the dependencies.
Can you give us an example to show the runtime module is dragged in? We
probably should fix that instead of moving away from the modular
structure.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Monday, April 27, 2009 2:38 AM
To: <[email protected]>
Subject: Re: Merging model and model-xml modules into one
I've cleaned up most of these now, of the remaining mike has said
he'll do implemantaion-spring-xml, we're keeping assembly-xml and
policy-xml for the time being, and that leaves: binding-ws-xml,
contribution-xml, definitions-xml, implementation-java-xml,
interface-java-xml. It turns out that those are not completely trivial
to fix. I'd still like to fix those but its going to take a bit longer
as some refactoring and plug points need to be done, I'll start some
seperate threads about those. From this one comment below...
...ant
On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng <[email protected]> wrote:
over-engineering. Meanwhile, I really don't think merging functionally
decoupled modules into a fat one is going to reduce spaghetti as it just
hides the spaghetti.
My experience from trying to tidy up these up is that the opposite can
be the case too - having lots of separate modules is sometimes what is
hiding the spaghetti. Its easish to see where a single module is being
used and what its dependencies are but its really quite hard to see
that for collection of modules. A module may look like its
functionally decoupled at first glance but its not until you actually
trace all the links from other modules and modules its using that you
find issues. We say we keep the model and runtime modules separate so
you that can use them independently but no one does use them that way
and we don't have any tests to verify that its possible - and it it
turns out that its not possible. Having tried tidying up these modules
shows in the end most of the runtime does get dragged in anyway and
that its not really possible to use subsets of the modules like we
expect.
...ant
