You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/09/10 01:58:54 UTC
[2.x] Refactor builders into a new tuscany-assembly-builder module
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.
Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action: http://www.manning.com/laws
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by Simon Laws <si...@googlemail.com>.
As I'm distracted trying to get 1.5.1 I've lost track of what is being
moved and why. I'd suggest doing whatever you need to do to get your
workspace clean and we can take a step back before we do any more
aesthetic refactoring to try and get as much of it done in one pass as
we can.
If we are all happy to commit a day or so to focus and discuss the
subject I'm sure we can come to some conclusion.
Regards
Simon
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Thu, Oct 1, 2009 at 5:50 PM, Simon Laws <si...@googlemail.com> wrote:
>> 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?
>>
>> ...ant
>>
>
> With this kind of refactoring I'd rather we plan what we are going to
> do across the code base, agree it and then apply it. This incremental
> changing of the module structure keeps breaking me as I try to look at
> the tests and it's taking me (personally, maybe it's just me) a long
> time to recover from module moves.
>
> I also think we need to get all the requirements on the table as this
> is bound to overlap with our need to decide how to prevent the build
> getting out of hand and (our old favourite) of how to structure the
> features/downloads we actually ship. Nibbling away at it may back us
> into a corner.
>
> Can we start a new thread to get all of the refactoring/restructuring
> requirements out on the table. I'm happy to start the thread and give
> my 2c if people want me too.
>
> Regards
>
> Simon
>
Sure ok though without any scoping that could quite easily turn into a
bit of a never ending discussion. There's that thread i started
earlier today "Making the 2.x build more modular" you could use to add
you 2c or start a fresh one. Does not doing refactoring include the
remaining policy-xml ones i said this morning i was starting to do
and now have ready to commit (hoping you'll not mind this last one as
it will go stale v quickly if i don't commit it now)?
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
+1.
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Thursday, October 01, 2009 9:50 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
>> 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?
>>
>> ...ant
>>
>
> With this kind of refactoring I'd rather we plan what we are going to
> do across the code base, agree it and then apply it. This incremental
> changing of the module structure keeps breaking me as I try to look at
> the tests and it's taking me (personally, maybe it's just me) a long
> time to recover from module moves.
>
> I also think we need to get all the requirements on the table as this
> is bound to overlap with our need to decide how to prevent the build
> getting out of hand and (our old favourite) of how to structure the
> features/downloads we actually ship. Nibbling away at it may back us
> into a corner.
>
> Can we start a new thread to get all of the refactoring/restructuring
> requirements out on the table. I'm happy to start the thread and give
> my 2c if people want me too.
>
> Regards
>
> Simon
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by Simon Laws <si...@googlemail.com>.
> 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?
>
> ...ant
>
With this kind of refactoring I'd rather we plan what we are going to
do across the code base, agree it and then apply it. This incremental
changing of the module structure keeps breaking me as I try to look at
the tests and it's taking me (personally, maybe it's just me) a long
time to recover from module moves.
I also think we need to get all the requirements on the table as this
is bound to overlap with our need to decide how to prevent the build
getting out of hand and (our old favourite) of how to structure the
features/downloads we actually ship. Nibbling away at it may back us
into a corner.
Can we start a new thread to get all of the refactoring/restructuring
requirements out on the table. I'm happy to start the thread and give
my 2c if people want me too.
Regards
Simon
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@gmail.com>.
On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng <en...@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" <an...@gmail.com>
> Sent: Thursday, September 10, 2009 12:31 AM
> To: <de...@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<en...@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?
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@gmail.com>.
On Thu, Sep 10, 2009 at 7:55 PM, Raymond Feng<en...@gmail.com> wrote:
> Good question. This is in fact a good use case of the Tuscany and such
> scenarios can help us organize the modules.
>
> Assembly depends on policy as the assembly model references intents and
> policySets from the policy model. From the xml loading perspective,
> assembly-xml doesn't depend on policy-xml or definitions-xml which handles
> the loading of intent/policySet definitions. So it is possible to use
> assembly-xml without policy-xml or definitions-xml in Android to reduce
> memory footprint. We can try to find a good balance here.
>
That case doesn't make any sense to try to optimize. The policy-xml
and definitions-xml modules take only 40k which is a _tiny_ fraction
of the total runtime size and they don't bring in any new
dependencies, and its not possible now to run without the xml modules
as all the other xml modules have been merged into their model
modules.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
Good question. This is in fact a good use case of the Tuscany and such
scenarios can help us organize the modules.
Assembly depends on policy as the assembly model references intents and
policySets from the policy model. From the xml loading perspective,
assembly-xml doesn't depend on policy-xml or definitions-xml which handles
the loading of intent/policySet definitions. So it is possible to use
assembly-xml without policy-xml or definitions-xml in Android to reduce
memory footprint. We can try to find a good balance here.
Thanks,
Raymond
--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Thursday, September 10, 2009 10:47 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
[[snip]]
> 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 ?
>
[[snip]]
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Sep 10, 2009 at 10:41 AM, Raymond Feng<en...@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" <an...@gmail.com>
> Sent: Thursday, September 10, 2009 12:31 AM
> To: <de...@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<en...@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/
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
Why do we need to change the package names? We should keep the packages and
simply export multiple packages.
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Friday, September 11, 2009 8:25 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
> On Fri, Sep 11, 2009 at 7:32 AM, ant elder<an...@gmail.com> wrote:
>> On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng<en...@gmail.com> wrote:
>>> Following the criteria, I would be fine if we merge assembly,
>>> definitions,
>>> policy into one module,
>>
>> Done in r813673.
>>
>> ...ant
>>
>
> The merged modules do still need all the packages renamed to fit in
> with the assembly module, thats a bit harder as refactors don't change
> all the other module manifests but i'll try to get it done over the
> weekend.
>
> ...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@gmail.com>.
On Fri, Sep 11, 2009 at 7:32 AM, ant elder<an...@gmail.com> wrote:
> On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng<en...@gmail.com> wrote:
>> Following the criteria, I would be fine if we merge assembly, definitions,
>> policy into one module,
>
> Done in r813673.
>
> ...ant
>
The merged modules do still need all the packages renamed to fit in
with the assembly module, thats a bit harder as refactors don't change
all the other module manifests but i'll try to get it done over the
weekend.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Tue, Sep 15, 2009 at 5:45 PM, Raymond Feng <en...@gmail.com> wrote:
> What causes the circular dependency? I understand the assembly will have
> dependency on interface.
>
assembly used policy and interface and interface used policy.
It seems quite clean and tidy to me like it is now with all those in
the assembly module, and it fits in with these discussions about the
reasons for having things together or separate so i'd be quite fine
leaving this as it is now.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
What causes the circular dependency? I understand the assembly will have
dependency on interface.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, September 15, 2009 9:19 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
> On Mon, Sep 14, 2009 at 10:22 AM, ant elder <an...@apache.org> wrote:
>
>> that caused another circular
>> dependency in the interface module so i merged that as well as it
>> meets all the criteria that Raymond defined. However I don't want the
>> interface module to disrupt getting agreement on merging the other xml
>> modules so i'll go look at finding a different way around the
>> interface circular dependency and separate that out again for now.
>
> I've tried but I can't see how to have the interface module separate
> without getting circular dependencies so I'd like to leave it merged
> in the assembly module. Happy to revisit if anyone has any suggestions
> but in the assembly module seems quite appropriate to me.
>
> ...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Mon, Sep 14, 2009 at 10:22 AM, ant elder <an...@apache.org> wrote:
> that caused another circular
> dependency in the interface module so i merged that as well as it
> meets all the criteria that Raymond defined. However I don't want the
> interface module to disrupt getting agreement on merging the other xml
> modules so i'll go look at finding a different way around the
> interface circular dependency and separate that out again for now.
I've tried but I can't see how to have the interface module separate
without getting circular dependencies so I'd like to leave it merged
in the assembly module. Happy to revisit if anyone has any suggestions
but in the assembly module seems quite appropriate to me.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Thu, Oct 1, 2009 at 10:01 AM, ant elder <an...@apache.org> wrote:
> On Mon, Sep 14, 2009 at 10:22 AM, ant elder <an...@apache.org> wrote:
>
>
>> While thats happening what about the xml modules, no one has replied
>> to the comments I made - is there really any need to keep them
>> separate when you can't run without them now and even if you could
>> they only add a 40k overhead.
>>
>
> There's been no comments on this for some weeks now so i'd like to go
> ahead and make the changes.
>
Done in r820951
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Mon, Sep 14, 2009 at 10:22 AM, ant elder <an...@apache.org> wrote:
> While thats happening what about the xml modules, no one has replied
> to the comments I made - is there really any need to keep them
> separate when you can't run without them now and even if you could
> they only add a 40k overhead.
>
There's been no comments on this for some weeks now so i'd like to go
ahead and make the changes.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@apache.org>.
On Fri, Sep 11, 2009 at 5:05 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Sep 11, 2009 at 8:59 AM, Raymond Feng <en...@gmail.com> wrote:
>> Have we reached a conclusion yet? I think other people are still chiming in
>> with opinions. It seems that you merged more modules than what we discussed.
>>
>
> I agree with Raymond and would really appreciate if we don't jump on
> making changes before reaching consensus, particularly on areas where
> there are some disagreements such as our scope of modularity.
>
> Ant, could you please revert/hold on these changes until we reach
> consensus here.
>
>
Luciano, I think this is a misunderstanding - I have _not_ merged the
modules that you questioned, i've left definitions-xml and policy-xml
alone for now. I have merged assembly, definitions, and policy, I
don't think any one objects to those, and that caused another circular
dependency in the interface module so i merged that as well as it
meets all the criteria that Raymond defined. However I don't want the
interface module to disrupt getting agreement on merging the other xml
modules so i'll go look at finding a different way around the
interface circular dependency and separate that out again for now.
While thats happening what about the xml modules, no one has replied
to the comments I made - is there really any need to keep them
separate when you can't run without them now and even if you could
they only add a 40k overhead.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Sep 11, 2009 at 8:59 AM, Raymond Feng <en...@gmail.com> wrote:
> Have we reached a conclusion yet? I think other people are still chiming in
> with opinions. It seems that you merged more modules than what we discussed.
>
I agree with Raymond and would really appreciate if we don't jump on
making changes before reaching consensus, particularly on areas where
there are some disagreements such as our scope of modularity.
Ant, could you please revert/hold on these changes until we reach
consensus here.
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
Have we reached a conclusion yet? I think other people are still chiming in
with opinions. It seems that you merged more modules than what we discussed.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, September 10, 2009 11:32 PM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
> On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng<en...@gmail.com> wrote:
>> Following the criteria, I would be fine if we merge assembly,
>> definitions,
>> policy into one module,
>
> Done in r813673.
>
> ...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@gmail.com>.
On Thu, Sep 10, 2009 at 6:41 PM, Raymond Feng<en...@gmail.com> wrote:
> Following the criteria, I would be fine if we merge assembly, definitions,
> policy into one module,
Done in r813673.
...ant
Re: [2.x] Refactor builders into a new tuscany-assembly-builder module
Posted by Raymond Feng <en...@gmail.com>.
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" <an...@gmail.com>
Sent: Thursday, September 10, 2009 12:31 AM
To: <de...@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<en...@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
Re: [2.x] Refactor builders into a new tuscany-assembly-builder
module
Posted by ant elder <an...@gmail.com>.
On Thu, Sep 10, 2009 at 12:58 AM, Raymond Feng<en...@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