tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Date Thu, 01 Oct 2009 09:13:57 GMT
On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng <enjoyjava@gmail.com> wrote:
> 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" <ant.elder@gmail.com>
> Sent: Thursday, September 10, 2009 12:31 AM
> To: <dev@tuscany.apache.org>
> Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
> module
>> On Thu, Sep 10, 2009 at 12:58 AM, Raymond Feng<enjoyjava@gmail.com> 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

Ok from all this can we look at some of the runtime modules, eg core,
core-spi, databinding, core-databinding, can we do any tidy up there?


View raw message