You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/05/11 15:46:46 UTC

2.x module refactoring status

I thought it would be worthwhile to post a status of this and the
things remaining that (IMHO) it would be good to get done. A lot has
already been done and the current outstanding items are:

1) Finish tuscany-contribution module split. Under discussion and
looks like its close to being agreed see [1], comments welcome.

2) We've consensus to merge the -xml modules into the model modules,
most have now been done, there's five remaining to do:
tuscany-assembly-xml
tuscany-binding-ws-xml
tuscany-definitions-xml
tuscany-interface-java-xml
tuscany-policy-xml

3) Agree or not to split tuscany-binding-sca and if so do that, see [3]

4) Clarify and agree on what are tooling versus runtime dependencies.
There is some discussion [2] but need to start a separate thread to
close on it.

5) Once (3) is done write a testcase to read/process/write scdl that
uses all the model and xml modules to verify it works without the core
runtime.

6) Clean up WS binding modules. Right now using the WS binding drags
in Axis2 and most of tuscany core, see [4]

7) Would be worthwhile to review the "core/runtime" modules? Look at
things like: are they fine as-is or any changes, do we know what
they're for and why we have them like this? Which is it ok or not ok
for the extension model and runtime modules to be declaring as
dependencies? Or maybe this can be left for later when we're close to
2.0? The main core modules are these ones:
tuscany-core
tuscany-core-databinding
tuscany-core-spi
tuscany-databinding
tuscany-endpoint
tuscany-extensibility
tuscany-launcher
tuscany-monitor
tuscany-node-api
tuscany-node-impl
tuscany-node-launcher

Any comments on all that?

   ...ant

[1] http://apache.markmail.org/message/ajo2vnf4tgm3g2vn
[2] http://apache.markmail.org/message/iupl7xguejh37zz3
[3] http://apache.markmail.org/message/ypg5axk347h7qnyx
[4] http://apache.markmail.org/message/xw5hecrcun2dxe7h

Re: 2.x module refactoring status

Posted by ant elder <an...@apache.org>.
On Mon, May 11, 2009 at 9:26 PM, Raymond Feng <en...@gmail.com> wrote:

>>
>> 3) Agree or not to split tuscany-binding-sca and if so do that, see [3]
>
> IMO, the binding.sca models and processors can be merged into assembly and
> assembly-xml. But the runtime provider code should be
> in its own module, for example, binding-sca-runtime.
>

Ok that sounds fine to me too so if no one disagrees i'll do that.

   ...ant

Re: 2.x module refactoring status

Posted by ant elder <an...@apache.org>.
On Tue, May 12, 2009 at 10:53 AM, ant elder <an...@apache.org> wrote:
> On Mon, May 11, 2009 at 9:26 PM, Raymond Feng <en...@gmail.com> wrote:
>
>>>
>>> 2) We've consensus to merge the -xml modules into the model modules,
>>> most have now been done, there's five remaining to do:
>>> tuscany-assembly-xml
>>> tuscany-binding-ws-xml
>>> tuscany-definitions-xml
>>> tuscany-interface-java-xml
>>> tuscany-policy-xml
>>
>> I prefer to leave assembly-xml, policy-xml.
>
> That could be fine but i would like to understand why, so could you explain?
>
>   ...ant
>

Ping?

   ...ant

Re: 2.x module refactoring status

Posted by ant elder <an...@apache.org>.
On Mon, May 11, 2009 at 9:26 PM, Raymond Feng <en...@gmail.com> wrote:

>>
>> 2) We've consensus to merge the -xml modules into the model modules,
>> most have now been done, there's five remaining to do:
>> tuscany-assembly-xml
>> tuscany-binding-ws-xml
>> tuscany-definitions-xml
>> tuscany-interface-java-xml
>> tuscany-policy-xml
>
> I prefer to leave assembly-xml, policy-xml.

That could be fine but i would like to understand why, so could you explain?

   ...ant

Re: 2.x module refactoring status

Posted by ant elder <an...@apache.org>.
On Mon, May 11, 2009 at 9:26 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>> 7) Would be worthwhile to review the "core/runtime" modules? Look at
>> things like: are they fine as-is or any changes, do we know what
>> they're for and why we have them like this? Which is it ok or not ok
>> for the extension model and runtime modules to be declaring as
>> dependencies? Or maybe this can be left for later when we're close to
>> 2.0? The main core modules are these ones:
>> tuscany-core
>> tuscany-core-databinding
>> tuscany-core-spi
>> tuscany-databinding
>> tuscany-endpoint
>> tuscany-extensibility
>> tuscany-launcher
>> tuscany-monitor
>> tuscany-node-api
>> tuscany-node-impl
>> tuscany-node-launcher
>>
>
> I would rather defer that until we have the SCA domain/node story into a
> clearer picture.
>

Fair enough. We have said in the past that the core-spi module is the
interface to core and extensions should only be having a compile
dependency on core-spi not core but there's still quite a lot using
core directly so we do need to look at this at some point. I've raised
TUSCANY-3016 to remember this so we can review before 2.0.

   ...ant

Re: 2.x module refactoring status

Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.

Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Monday, May 11, 2009 6:46 AM
To: <de...@tuscany.apache.org>
Subject: 2.x module refactoring status

> I thought it would be worthwhile to post a status of this and the
> things remaining that (IMHO) it would be good to get done. A lot has
> already been done and the current outstanding items are:
>
> 1) Finish tuscany-contribution module split. Under discussion and
> looks like its close to being agreed see [1], comments welcome.

We should probably refactor the java related stuff into contribution-java 
for a few reasons:
* <import.java> and <export.java> is defined by the Java spec instead of 
assembly spec
* It's very likely that the resolution of import/export and java classes is 
hosting environment specific

>
> 2) We've consensus to merge the -xml modules into the model modules,
> most have now been done, there's five remaining to do:
> tuscany-assembly-xml
> tuscany-binding-ws-xml
> tuscany-definitions-xml
> tuscany-interface-java-xml
> tuscany-policy-xml

I prefer to leave assembly-xml, policy-xml. We could potentially merge 
definitions and definitions.xml into assembly or policy though.

>
> 3) Agree or not to split tuscany-binding-sca and if so do that, see [3]

IMO, the binding.sca models and processors can be merged into assembly and 
assembly-xml. But the runtime provider code should be
in its own module, for example, binding-sca-runtime.

>
> 4) Clarify and agree on what are tooling versus runtime dependencies.
> There is some discussion [2] but need to start a separate thread to
> close on it.
>
> 5) Once (3) is done write a testcase to read/process/write scdl that
> uses all the model and xml modules to verify it works without the core
> runtime.

+1.

>
> 6) Clean up WS binding modules. Right now using the WS binding drags
> in Axis2 and most of tuscany core, see [4]

The binding-ws related code is a bit messy. We should look into the binding 
invocation chain idea to refactor the pieces into interceptors, so do the 
WS-* support.

>
> 7) Would be worthwhile to review the "core/runtime" modules? Look at
> things like: are they fine as-is or any changes, do we know what
> they're for and why we have them like this? Which is it ok or not ok
> for the extension model and runtime modules to be declaring as
> dependencies? Or maybe this can be left for later when we're close to
> 2.0? The main core modules are these ones:
> tuscany-core
> tuscany-core-databinding
> tuscany-core-spi
> tuscany-databinding
> tuscany-endpoint
> tuscany-extensibility
> tuscany-launcher
> tuscany-monitor
> tuscany-node-api
> tuscany-node-impl
> tuscany-node-launcher
>

I would rather defer that until we have the SCA domain/node story into a 
clearer picture.

> Any comments on all that?
>
>   ...ant
>
> [1] http://apache.markmail.org/message/ajo2vnf4tgm3g2vn
> [2] http://apache.markmail.org/message/iupl7xguejh37zz3
> [3] http://apache.markmail.org/message/ypg5axk347h7qnyx
> [4] http://apache.markmail.org/message/xw5hecrcun2dxe7h