If I add the policy attachment builder to definitions-xml, it then depends
on assembly-xml to write the composite into DOM. But assembly-xml has a
"test" dependency on definitions-xml to test the builder. This is a warning
sign that the builder is in wrong module.
The logic in the builder depends on functions provided by the models
(assembly, policy, definitions) and the processors (contribution,
assembly-xml, policy-xml, definitions-xml). It sits on a different layer
than assembly which holds the java models for the SCA assembly.
I'm keen on keeping Tuscany modular. There are two important criteria to
justify if module A and B should be separate:
1) Module A and B can be used independently (supporting different
technologies, for example, interface-java vs. interface-wsdl)
2) Module A provides functions at a different layer than B. In Tuscany, we
have layers to deal with extensibility, java models, contribution
processing, build, and activation/invocation (for example, assembly-xml vs.
assembly, core vs contribution). Higher levels typically depend on lower
layers, but lower layers can be used without higher layers.
As I have said many times, merging all the modules together just hide the
circular dependencies. To the extreme, if we just have one giant module,
there won't be any dependency issues as they are hidden.
Following the criteria, I would be fine if we merge assembly, definitions,
policy into one module, and assembly-xml, definitions-xml and policy-xml
into another module. But don't try to merge across functional layers.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, September 10, 2009 12:31 AM
To: <[email protected]>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
On Thu, Sep 10, 2009 at 12:58 AM, Raymond Feng<[email protected]> wrote:
Hi,
I'm working on a policy builder that attaches the policy sets to a
composite
using xpath expressions. To implement this capability, I'll have to write
the Composite object into a DOM tree so that the xpath expression can be
evaluated. It introduces dependencies on the tuscany-contribution and
various tuscany-???-xml modules to leverage the XML write() in the StAX
processors. I couldn't find an existing module (such as policy-xml,
definitions-xml) to add this builder as it leads to circular
dependencies.
I propose that we refactor the builder related code from tuscany-assembly
module into a new tuscany-assembly-builder module. After all, the
builders
depends on the assembly model but it provides the "build" function for
the
models including those from extension types.
If there is no objection, I'll check in the changes in a few days.
What are the circular dependencies which cause a problem? I think we
should fix those rather than add yet another module.
I also get problems with circular dependencies, i think they're caused
by the module breakdown not quite being right yet. IIRC we started to
come up with some guidelines on what should be a separate module when
we did the refactoring a little while back - related function that
doesn't drag in extra dependencies and has default factory impls which
can be overridden doesn't need to be a separate module, if it is made
a separate module then that contributes to these circular dependency
problems.
These are the core/kernel/base modules that you need when you do
anything with Tuscany, lets minimize these and that will likely
resolve any circular dependency problems, so which of these really
need to be separate?
assembly
assembly-xml
assembly-xsd
binding-sca-runtime
common-java
common-xml
contribution
core
core-databinding
core-spi
databinding
databinding-jaxb
definitions
definitions-xml
endpoint
extensibility
host-http
implementation-java
implementation-java-runtime
interface
interface-java
interface-java-jaxws
interface-wsdl
monitor
policy
policy-xml
sca-api
xsd
...ant
