On Thu, Sep 10, 2009 at 10:41 AM, Raymond Feng<enjoyj...@gmail.com> wrote: > 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. >
+1 > 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. > +1 > 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. > Are there possible runtimes where policy might be not required (e.g when running in a mobile/android platform) ? then we probably want to avoid assembly-xml to be merged to definitions-xml + policy-xml ? > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <ant.el...@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<enjoyj...@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 > > -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
