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/04/21 14:35:39 UTC
Merging model and model-xml modules into one
I think we've consensus now that instead of having three maven modules
(model/model-xml/model-runtime) its ok to have the model and model-xml in a
single module, but we've still some model-xml modules in 2.x so i'd like to
merge them into the associated model module. Please say if you've any
objections.
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 22, 2009 at 12:45 AM, ant elder <an...@apache.org> wrote:
>> > But what are those concerns? No one has ever given any technical reasons
>> > for
>> > keeping them separate that makes sense if we're not doing it
>> > consistently.
>> >
>>
>> Having the xml processors in a separate module would allow us execute
>> the compatibility stuff for 2.x discussed in [1]....
>>
>> [1] http://markmail.org/message/2cez45rwmj43jxwa
>>
>
> What specifically in there could we not do if the code was in a single
> module?
>
> ...ant
>
Having separate modules give us the flexibility to provide a clean
OASIS distribution and also a OSOA backward compatible
distribution.... users/embedders/etc would have a choice.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng <en...@gmail.com> wrote:
> +1 on Mike's proposal.
Wonderful!
> over-engineering. Meanwhile, I really don't think merging functionally
> decoupled modules into a fat one is going to reduce spaghetti as it just
> hides the spaghetti. I would rather get all the dependencies uncovered and
> refactor the code to reduce them to a bare minimum. From OSGi's view,
> creating a big bundle that contains everything won't get any benefits such
> as modularity, isolations, versioning, or dynamicity promised by OSGi.
>
No one has suggested "a big bundle that contains everything". I know
the module breakdown is a bit of a touchy subject from Tuscany's
history thats why i've started all this discussion not just gone off
CTR changing things, lets try to forget past prejudices and make it
better this time.
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 29, 2009 at 6:29 PM, Raymond Feng <en...@gmail.com> wrote:
> I see the dependency is a bit involved. IMO, the databinding based schema
> generation is OK as dependencies.
> The J2W piece doesn't have to be viewed as runtime dependencies.
>
The problem is with the lengthy list of dependencies. Its been said a
goal is to have the model separated from the runtime so people could
use it to read/write/proccess the SCDL XML files, but for that to be
useful you'd expect it to be an obvious list of modules with few
dependencies - ideally something like some Tuscany jars with obvious
names and some stax parser dependencies, but its not that, here's the
list of modules needed by tuscany-binidng-ws-wsdlgen:
activation-1.1.jar
annogen-0.1.0.jar
ant-1.7.0.jar
ant-launcher-1.7.0.jar
asm-3.1.jar
axiom-api-1.2.7.jar
axiom-dom-1.2.7.jar
axiom-impl-1.2.7.jar
axis2-kernel-1.4.1.jar
cglib-2.2.jar
commons-codec-1.2.jar
commons-fileupload-1.2.jar
commons-httpclient-3.1.jar
commons-io-1.4.jar
commons-logging-1.1.1.jar
geronimo-activation_1.1_spec-1.0.1.jar
geronimo-javamail_1.4_spec-1.2.jar
geronimo-jms_1.1_spec-1.1.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
httpcore-4.0-beta1.jar
httpcore-nio-4.0-beta1.jar
jaxb-api-2.1.jar
jaxb-impl-2.1.9.jar
jaxen-1.1.1.jar
jaxws-api-2.1.jar
jsr181-api-1.0-MR1.jar
jsr250-api-1.0.jar
junit-4.5.jar
mail-1.4.jar
neethi-2.0.4.jar
servlet-api-2.3.jar
tuscany-assembly-2.0-SNAPSHOT.jar
tuscany-assembly-xml-2.0-SNAPSHOT.jar
tuscany-binding-ws-2.0-SNAPSHOT.jar
tuscany-binding-ws-axis2-policy-2.0-SNAPSHOT.jar
tuscany-contribution-2.0-SNAPSHOT.jar
tuscany-contribution-java-2.0-SNAPSHOT.jar
tuscany-contribution-namespace-2.0-SNAPSHOT.jar
tuscany-contribution-xml-2.0-SNAPSHOT.jar
tuscany-core-2.0-SNAPSHOT.jar
tuscany-core-databinding-2.0-SNAPSHOT.jar
tuscany-core-spi-2.0-SNAPSHOT.jar
tuscany-databinding-2.0-SNAPSHOT.jar
tuscany-databinding-axiom-2.0-SNAPSHOT.jar
tuscany-databinding-jaxb-2.0-SNAPSHOT.jar
tuscany-definitions-2.0-SNAPSHOT.jar
tuscany-extensibility-2.0-SNAPSHOT.jar
tuscany-interface-2.0-SNAPSHOT.jar
tuscany-interface-java-2.0-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar
tuscany-interface-java-xml-2.0-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-SNAPSHOT.jar
tuscany-monitor-2.0-SNAPSHOT.jar
tuscany-policy-2.0-SNAPSHOT.jar
tuscany-policy-security-2.0-SNAPSHOT.jar
tuscany-sca-api-2.0-SNAPSHOT.jar
tuscany-xsd-2.0-SNAPSHOT.jar
woden-api-1.0M8.jar
woden-impl-dom-1.0M8.jar
wsdl4j-1.6.2.jar
wstx-asl-3.2.4.jar
xmlParserAPIs-2.6.0.jar
XmlSchema-1.4.2.jar
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 29, 2009 at 6:29 PM, Raymond Feng <en...@gmail.com> wrote:
> Please see comments inline.
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, April 28, 2009 12:55 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Merging model and model-xml modules into one
>
>> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> What are the things that are not completely trivial?
>>
>> As i said in the previous mail the non-trivial ones remaining are:
>> binding-ws-xml, contribution-xml, definitions-xml,
>> implementation-java-xml,
>> interface-java-xml
>
> Maybe my question wasn't clear. I was asking what are things in these
> modules make it not trivial to merge them with
> the model module.
>
Ah ok i'd misunderstood. I didn't investigate. All i did was one by
one merge all the old -xml modules into the model modules and most
just worked except for those five. A quick look showed there was
problems with things like cyclic dependencies. It may turn out that we
need to keep some of those separate or we need to move classes about
into more appropriate modules.
Each module needs to be investigated, i've started on the
binding-ws-xml one and posted that other thread about it, and there's
now some conversation on this thread about the contribution-xml one
too. If you'd like to help pick one of those other modules and try to
do the merge.
What would be good to end up with is a clear and common understanding
of the type of function provided by each module and have that
reflected in an as consistent as possible naming pattern and have a
README in each module briefly summarizing its purpose.
>>
>>> Can you give us an example to show the runtime module is dragged in?
>>
>> See http://apache.markmail.org/message/tyvnziazg22or4lu
>
> I see the dependency is a bit involved. IMO, the databinding based schema
> generation is OK as dependencies.
> The J2W piece doesn't have to be viewed as runtime dependencies.
Thats possibly true, i guess we just have to decide what functions
we're trying to achieve with the modularization structure.
On another thread we're talking about spiting out some Java
introspection code into a separate pluggable piece with interfaces and
factories, if we go that far just for some Java introspection you'd
think we'd at least want to do something similar for this wsdl
generation function - make the J2W implementation pluggable and
binding-ws isn't dependent directly on our particular J2W
implementation detail, so have an SPI extension point for wsdl
generation which binding-ws-xml can use instead of directly calling a
static method in binding-ws-wsdlgen.
>
> BTW, I don't see any dependencies to binding-ws-axis2 and
> binding-ws-axis2-policy though.
>
LOL, thats precisely what i was saying earlier - these are hard to
spot as soon as they're not from one explicit dependency in a single
module pom.xml. The problem in this case is that it results in two
cyclic dependencies - binding-ws-xml is merged to binding-ws so
binding-ws gets a static method call to binding-ws-wsdlgen,
binding-ws-wsdlgen has a dependency on binding-ws and
binding-ws-axis2-policy, binding-ws-axis2 also depends on
binding-ws-axis2-policy and binding-ws-axis2-policy depends on
binding-ws - hence you can't build binding-ws until
binding-ws-axis2-policy is built and vica-versa, and you can't build
binding-ws-wsdlgen until binding-ws is built and visa-versa.
...ant
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
Please see comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, April 28, 2009 12:55 AM
To: <de...@tuscany.apache.org>
Subject: Re: Merging model and model-xml modules into one
> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
>> What are the things that are not completely trivial?
>
> As i said in the previous mail the non-trivial ones remaining are:
> binding-ws-xml, contribution-xml, definitions-xml,
> implementation-java-xml,
> interface-java-xml
Maybe my question wasn't clear. I was asking what are things in these
modules make it not trivial to merge them with
the model module.
>
>> Can you give us an example to show the runtime module is dragged in?
>
> See http://apache.markmail.org/message/tyvnziazg22or4lu
I see the dependency is a bit involved. IMO, the databinding based schema
generation is OK as dependencies.
The J2W piece doesn't have to be viewed as runtime dependencies.
BTW, I don't see any dependencies to binding-ws-axis2 and
binding-ws-axis2-policy though.
>
>> probably should fix that instead of moving away from the modular
>> structure.
>
> This is not trying to move away from a modular structure, its tidying
> up the current structure so that it actual works and makes sense, and
> also so that there is more of a common understanding about when to
> create a new module versus a new package in an exsiting module.
>
> ...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Thu, May 7, 2009 at 8:33 AM, ant elder <an...@gmail.com> wrote:
> On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > So how about
> >
> > contribution-metadata - I can never find this stuff
> > contribution (or core-contribution or contribution-runtime) for all
> > the spi/infrastructure type of stuff
> > contribution-xxxx
> >
>
> Thats starting to look much cleaner to me.
>
> There are three contribution-xxxx modules - contribution-java,
> contribution-namespace, contribution-osgi. Do we really need the -java
> and -namespace ones as separate modules? Unless there are real use
> cases or problems solved by keeping them separate i think they should
> be merged with one of the other contribution modules.
>
> ...ant
>
In r773311 I've redone the module merge for this to include the svn history.
Now i'll review all the classes in that one module to try to work out what
should be there or moved to a separate module. The build is working for me
except fo a test fail on node-launcher-equinox, but that was failing for me
before these changes but i look at that too.
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, May 6, 2009 at 5:09 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't think we use the contribution service any more in 2.x. The workspace
> modules are now in charge of contribution processing.
>
That brings up an interesting point :-) Another place i think we can
be tidying up is with how the workspace, implementation-node and Node
APIs work. I was leaving this till after some of the other refactoring
threads have quietened down but as its come up here i'll start a new
thread about it - see the email "Node usage of the workspace and
implementation-node modules".
...ant
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Mon, May 11, 2009 at 10:44 AM, ant elder <an...@gmail.com> wrote:
> On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
>
>> So how about
>>
>> contribution-metadata - I can never find this stuff
>> contribution (or core-contribution or contribution-runtime) for all
>> the spi/infrastructure type of stuff
>> contribution-xxxx
>>
>> Simon
>>
>
> Continuing with these changes, to clarify what we think are -metadata
> classes, spi/infrastructure, etc, it looks like we have the following
> functions in the contribution module:
>
> - model and xml processors for the sca-contribution.xml file
> - generic code shared by all the model/xml modules like
> BaseStAXArtifactProcessor
> - runtime contribution service classes
>
> so would it be reasonable to split the current contribution module up
> like that?
>
> Does the generic code like BaseStAXArtifactProcessor need to be in its
> own contribution-xxx module or could it be somewhere shared like the
> existing spi module?
>
> ...ant
>
Ok, looking at it now the name "contribution-metadata" seems a little
awkward so we could stick with "contribution" as the module that
models the contribution an (now) contains the code to do all the
processing to read and create that model.
I think we should have the support for import/export namespace and
java as separate modules as they implement extension points
independent of the actual contribution processing.
Re. the generic code classes. It's certainly shared by lots of other
modules which currently depend on contribution. We could fluff up
something like core-contribution. Do the core-* module though only
contain runtime things? Alternatively I could be persuaded just leave
it where it is.
Simon
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
> So how about
>
> contribution-metadata - I can never find this stuff
> contribution (or core-contribution or contribution-runtime) for all
> the spi/infrastructure type of stuff
> contribution-xxxx
>
> Simon
>
Continuing with these changes, to clarify what we think are -metadata
classes, spi/infrastructure, etc, it looks like we have the following
functions in the contribution module:
- model and xml processors for the sca-contribution.xml file
- generic code shared by all the model/xml modules like
BaseStAXArtifactProcessor
- runtime contribution service classes
so would it be reasonable to split the current contribution module up
like that?
Does the generic code like BaseStAXArtifactProcessor need to be in its
own contribution-xxx module or could it be somewhere shared like the
existing spi module?
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
> So how about
>
> contribution-metadata - I can never find this stuff
> contribution (or core-contribution or contribution-runtime) for all
> the spi/infrastructure type of stuff
> contribution-xxxx
>
Thats starting to look much cleaner to me.
There are three contribution-xxxx modules - contribution-java,
contribution-namespace, contribution-osgi. Do we really need the -java
and -namespace ones as separate modules? Unless there are real use
cases or problems solved by keeping them separate i think they should
be merged with one of the other contribution modules.
...ant
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Wed, May 6, 2009 at 5:09 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't think we use the contribution service any more in 2.x. The workspace
> modules are now in charge of contribution processing.
>
> The current tuscany-contribution module contains the model for
> Contribution/Artifact. It also defines the SPIs for contribution scanners,
> artifact processors, and model resolvers.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, May 05, 2009 11:39 PM
> To: <de...@tuscany.apache.org>
> Subject: Re: Merging model and model-xml modules into one
>
>> On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
>>
>>> processing. I wonder if there is still some refactoring that could be
>>> done here - it sounds like the "contribution" module includes the
>>> model code for the sca-contribution.xml and
>>> sca-contribution-generated.xml files as well as the code for the
>>> contribution service and its SPIs and extension points - perhaps the
>>> model code should be separated from the contribution service so there
>>> is module for the contribution service and another module for the
>>> sca-contribution model, and then the existing contribution-xml module
>>> gets merged into the new model module. (Which fits in nicely with a
>>> conversation from 2 years ago!
>>> http://apache.markmail.org/message/nncxz73tbozov44y)
>>>
>>> ...ant
>>>
>>
>> No replies to that so i'll assume its reasonable and add it to the
>> list of tidying up I'm doing.
>>
>> ...ant
>
>
We seem to have several things then...
contribution
contribution metadata model
contribution model
artifact model - derived from scanner
import model - derived from metadata
export model - derived from metadata
contribution scanner SPI - used to locate artifacts
stax processing base support - seems like a strange place for it
model resolver base support - again slightly odd place
contribution-xml
contribution metadata processor
then we have several...
contribution.xxxx
where xxxx seems to vary between how imports/exports are processed
(java/namespace) and how OSGi contributions as a whole are treated
(osgi).
So how about
contribution-metadata - I can never find this stuff
contribution (or core-contribution or contribution-runtime) for all
the spi/infrastructure type of stuff
contribution-xxxx
Simon
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
I don't think we use the contribution service any more in 2.x. The workspace
modules are now in charge of contribution processing.
The current tuscany-contribution module contains the model for
Contribution/Artifact. It also defines the SPIs for contribution scanners,
artifact processors, and model resolvers.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, May 05, 2009 11:39 PM
To: <de...@tuscany.apache.org>
Subject: Re: Merging model and model-xml modules into one
> On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
>
>> processing. I wonder if there is still some refactoring that could be
>> done here - it sounds like the "contribution" module includes the
>> model code for the sca-contribution.xml and
>> sca-contribution-generated.xml files as well as the code for the
>> contribution service and its SPIs and extension points - perhaps the
>> model code should be separated from the contribution service so there
>> is module for the contribution service and another module for the
>> sca-contribution model, and then the existing contribution-xml module
>> gets merged into the new model module. (Which fits in nicely with a
>> conversation from 2 years ago!
>> http://apache.markmail.org/message/nncxz73tbozov44y)
>>
>> ...ant
>>
>
> No replies to that so i'll assume its reasonable and add it to the
> list of tidying up I'm doing.
>
> ...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
> processing. I wonder if there is still some refactoring that could be
> done here - it sounds like the "contribution" module includes the
> model code for the sca-contribution.xml and
> sca-contribution-generated.xml files as well as the code for the
> contribution service and its SPIs and extension points - perhaps the
> model code should be separated from the contribution service so there
> is module for the contribution service and another module for the
> sca-contribution model, and then the existing contribution-xml module
> gets merged into the new model module. (Which fits in nicely with a
> conversation from 2 years ago!
> http://apache.markmail.org/message/nncxz73tbozov44y)
>
> ...ant
>
No replies to that so i'll assume its reasonable and add it to the
list of tidying up I'm doing.
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 29, 2009 at 5:31 PM, Luciano Resende <lu...@gmail.com> wrote:
> My take on this is that contribution module is about contribution
> services, defining spis for these services, and extensions points,
> where contribution-xml is about providing support for handling
> sca-contribution.xml and sca-contribution-generated.xml files.
Ok that helps a lot. So it sounds like these contribution modules have
a different pattern to what we've had in the other modules which used
a module for the scdl model and another module for the model XML
processing. I wonder if there is still some refactoring that could be
done here - it sounds like the "contribution" module includes the
model code for the sca-contribution.xml and
sca-contribution-generated.xml files as well as the code for the
contribution service and its SPIs and extension points - perhaps the
model code should be separated from the contribution service so there
is module for the contribution service and another module for the
sca-contribution model, and then the existing contribution-xml module
gets merged into the new model module. (Which fits in nicely with a
conversation from 2 years ago!
http://apache.markmail.org/message/nncxz73tbozov44y)
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 29, 2009 at 12:17 AM, ant elder <an...@apache.org> wrote:
> On Tue, Apr 28, 2009 at 10:39 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Tue, Apr 28, 2009 at 12:55 AM, ant elder <an...@apache.org> wrote:
>>> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
>>>> What are the things that are not completely trivial?
>>>
>>> As i said in the previous mail the non-trivial ones remaining are:
>>> binding-ws-xml, contribution-xml, definitions-xml,
>>> implementation-java-xml,
>>> interface-java-xml
>>>
>>
>> I'm not sure about definition-xml, but I wouldn't like to see
>> contribution-xml merged with contribution module.
>>
>
> Could you explain why you wouldn't like to see this? I've not looked
> at that model in any detail so that could well be correct but it would
> be helpful for now or anyone in the future looking for why things are
> the way they are if the technical reasons for decisions are on the
> mailing list.
>
> ...ant
>
My take on this is that contribution module is about contribution
services, defining spis for these services, and extensions points,
where contribution-xml is about providing support for handling
sca-contribution.xml and sca-contribution-generated.xml files. I like
having the separation of concerns applied to these modules to avoid
confusion. Also, I don' t see any good technical reason and benefit of
merging these modules together.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Tue, Apr 28, 2009 at 10:39 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Apr 28, 2009 at 12:55 AM, ant elder <an...@apache.org> wrote:
>> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
>>> What are the things that are not completely trivial?
>>
>> As i said in the previous mail the non-trivial ones remaining are:
>> binding-ws-xml, contribution-xml, definitions-xml,
>> implementation-java-xml,
>> interface-java-xml
>>
>
> I'm not sure about definition-xml, but I wouldn't like to see
> contribution-xml merged with contribution module.
>
Could you explain why you wouldn't like to see this? I've not looked
at that model in any detail so that could well be correct but it would
be helpful for now or anyone in the future looking for why things are
the way they are if the technical reasons for decisions are on the
mailing list.
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 28, 2009 at 12:55 AM, ant elder <an...@apache.org> wrote:
> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
>> What are the things that are not completely trivial?
>
> As i said in the previous mail the non-trivial ones remaining are:
> binding-ws-xml, contribution-xml, definitions-xml,
> implementation-java-xml,
> interface-java-xml
>
I'm not sure about definition-xml, but I wouldn't like to see
contribution-xml merged with contribution module.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <en...@gmail.com> wrote:
> What are the things that are not completely trivial?
As i said in the previous mail the non-trivial ones remaining are:
binding-ws-xml, contribution-xml, definitions-xml,
implementation-java-xml,
interface-java-xml
> Can you give us an example to show the runtime module is dragged in?
See http://apache.markmail.org/message/tyvnziazg22or4lu
> probably should fix that instead of moving away from the modular
> structure.
This is not trying to move away from a modular structure, its tidying
up the current structure so that it actual works and makes sense, and
also so that there is more of a common understanding about when to
create a new module versus a new package in an exsiting module.
...ant
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
What are the things that are not completely trivial? It might be a warning
sign that the "merge" is complicating the dependencies.
If you can share one or two examples, we can discuss how we handle them in
concrete context.
We probably have to think about the modularity in a broader view. Sure, if
it's just for our standalone runtime, we can organize the
code in anyway we want. But taking the usage patterns from tools and other
vendors that want to reuse/embed Tuscany.
Some of the problems are related to how we use different scopes of the maven
modules as well as the transitive dependencies. For
example, we could have two different implementation for binding.ws (Axis2 or
JAX-WS), or two different HTTP hosts (Jetty or Tomcat).
To test a web service, we could choose one of them as the "test"
dependencies instead of "compile" or "runtime" dependency. Being careful
about the pom.xml will help us to minimize the dependencies.
Can you give us an example to show the runtime module is dragged in? We
probably should fix that instead of moving away from the modular
structure.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Monday, April 27, 2009 2:38 AM
To: <de...@tuscany.apache.org>
Subject: Re: Merging model and model-xml modules into one
> I've cleaned up most of these now, of the remaining mike has said
> he'll do implemantaion-spring-xml, we're keeping assembly-xml and
> policy-xml for the time being, and that leaves: binding-ws-xml,
> contribution-xml, definitions-xml, implementation-java-xml,
> interface-java-xml. It turns out that those are not completely trivial
> to fix. I'd still like to fix those but its going to take a bit longer
> as some refactoring and plug points need to be done, I'll start some
> seperate threads about those. From this one comment below...
>
> ...ant
>
> On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> over-engineering. Meanwhile, I really don't think merging functionally
>> decoupled modules into a fat one is going to reduce spaghetti as it just
>> hides the spaghetti.
>
> My experience from trying to tidy up these up is that the opposite can
> be the case too - having lots of separate modules is sometimes what is
> hiding the spaghetti. Its easish to see where a single module is being
> used and what its dependencies are but its really quite hard to see
> that for collection of modules. A module may look like its
> functionally decoupled at first glance but its not until you actually
> trace all the links from other modules and modules its using that you
> find issues. We say we keep the model and runtime modules separate so
> you that can use them independently but no one does use them that way
> and we don't have any tests to verify that its possible - and it it
> turns out that its not possible. Having tried tidying up these modules
> shows in the end most of the runtime does get dragged in anyway and
> that its not really possible to use subsets of the modules like we
> expect.
>
> ...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
I've cleaned up most of these now, of the remaining mike has said
he'll do implemantaion-spring-xml, we're keeping assembly-xml and
policy-xml for the time being, and that leaves: binding-ws-xml,
contribution-xml, definitions-xml, implementation-java-xml,
interface-java-xml. It turns out that those are not completely trivial
to fix. I'd still like to fix those but its going to take a bit longer
as some refactoring and plug points need to be done, I'll start some
seperate threads about those. From this one comment below...
...ant
On Wed, Apr 22, 2009 at 5:11 PM, Raymond Feng <en...@gmail.com> wrote:
> over-engineering. Meanwhile, I really don't think merging functionally
> decoupled modules into a fat one is going to reduce spaghetti as it just
> hides the spaghetti.
My experience from trying to tidy up these up is that the opposite can
be the case too - having lots of separate modules is sometimes what is
hiding the spaghetti. Its easish to see where a single module is being
used and what its dependencies are but its really quite hard to see
that for collection of modules. A module may look like its
functionally decoupled at first glance but its not until you actually
trace all the links from other modules and modules its using that you
find issues. We say we keep the model and runtime modules separate so
you that can use them independently but no one does use them that way
and we don't have any tests to verify that its possible - and it it
turns out that its not possible. Having tried tidying up these modules
shows in the end most of the runtime does get dragged in anyway and
that its not really possible to use subsets of the modules like we
expect.
...ant
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
+1 on Mike's proposal. Additionally, I prefer to leave assembly-xml and
policy-xml as is. My bottom line to keep the clean modularity without
over-engineering. Meanwhile, I really don't think merging functionally
decoupled modules into a fat one is going to reduce spaghetti as it just
hides the spaghetti. I would rather get all the dependencies uncovered and
refactor the code to reduce them to a bare minimum. From OSGi's view,
creating a big bundle that contains everything won't get any benefits such
as modularity, isolations, versioning, or dynamicity promised by OSGi.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Wednesday, April 22, 2009 7:43 AM
To: <de...@tuscany.apache.org>
Subject: Re: Merging model and model-xml modules into one
> ant elder wrote:
>>
>>
>> Stepping back, what' s the problem we are trying to solve here ? I
>> kind like the "Don' t fix what ain't broke" phrase [1]...
>>
>>
>> I think it is "broke" :) We could make the runtime simpler if we had more
>> consistent use of fewer more functional modules and had a common
>> understand of when things can be in packages in the one module and when
>> things need to be in a separate module. We've consistently had users
>> saying tuscany looks really complicate as there are so many jars and no
>> clear way to work out what they're for and what they do, we end up with a
>> spaghetti mess of imports exports and dependencies that few understand,
>> even just the build and IDE development gets slower and more unwieldy as
>> the number of modules increases. ...ant
>>
> Folks,
>
> Here is my view on this debate.
>
> I think that Ant makes a fair point that more modules is in itself a
> problem. There is an overhead to each module and I agree that we should
> have as few of them as possible. Having a big mound of them doesn't help
> us or our users.
>
> On the other hand, I can see the point that Luciano is making about useful
> flexibility in some cases.
>
> I take the view that it should be examined on a case by case basis, but
> with a bias to reducing the number of modules if there is no clear benefit
> to having additional ones. I would be particularly suspicious of a module
> consisting of only a few small classes.
>
> For a couple of implementation cases that I understand well, here is my
> analysis:
>
> 1) BPEL
>
> We have implementation-bpel and implementation-bpel-ode.
>
> This is a classic split of Tuscany code vs 3rd party runtime code.
> It should stay.
>
> I note that all processing of XML is in implementation-bpel AND that this
> includes dealing with 3 types of XML - SCA, BPEL and WSDL - AND that it
> includes the handling of multiple versions of these. I don't see the need
> to split out this code.
>
>
> 2) Spring
>
> We have implementation-spring, implementation-spring-xml and
> implementation-spring-runtime
>
> We always had implementation-spring and implementation-spring-xml and we
> created implementation-spring-runtime in going to 2.0.
>
> The implementation-spring-xml is here all about processing the XML of the
> Spring application context, rather than the SCA XML. I suppose it could
> be combined with implementation-spring - since that is what we have done
> in the case of BPEL. So here is a candidate for removal...
>
> The implementation-spring-runtime contains code that gets very intimate
> with the Spring classes (eg. some of our classes extend Spring classes).
> This is like the implementation-bpel-ode module and I think it is
> essential in the 2.0 codebase to support OSGi cleanly. We are having to
> restructure some of the classes to fit nicely and avoid awkward two-way
> cross-package dependencies.
>
> OK, that is my pennyworth. Comments welcome.
>
>
>
> Yours, Mike.
>
Re: Merging model and model-xml modules into one
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
>
>
> Stepping back, what' s the problem we are trying to solve here ? I
> kind like the "Don' t fix what ain't broke" phrase [1]...
>
>
> I think it is "broke" :) We could make the runtime simpler if we had
> more consistent use of fewer more functional modules and had a common
> understand of when things can be in packages in the one module and when
> things need to be in a separate module. We've consistently had users
> saying tuscany looks really complicate as there are so many jars and no
> clear way to work out what they're for and what they do, we end up with
> a spaghetti mess of imports exports and dependencies that few
> understand, even just the build and IDE development gets slower and more
> unwieldy as the number of modules increases.
>
> ...ant
>
Folks,
Here is my view on this debate.
I think that Ant makes a fair point that more modules is in itself a problem. There is an overhead
to each module and I agree that we should have as few of them as possible. Having a big mound of
them doesn't help us or our users.
On the other hand, I can see the point that Luciano is making about useful flexibility in some cases.
I take the view that it should be examined on a case by case basis, but with a bias to reducing the
number of modules if there is no clear benefit to having additional ones. I would be particularly
suspicious of a module consisting of only a few small classes.
For a couple of implementation cases that I understand well, here is my analysis:
1) BPEL
We have implementation-bpel and implementation-bpel-ode.
This is a classic split of Tuscany code vs 3rd party runtime code.
It should stay.
I note that all processing of XML is in implementation-bpel AND that this includes dealing with 3
types of XML - SCA, BPEL and WSDL - AND that it includes the handling of multiple versions of these.
I don't see the need to split out this code.
2) Spring
We have implementation-spring, implementation-spring-xml and implementation-spring-runtime
We always had implementation-spring and implementation-spring-xml and we created
implementation-spring-runtime in going to 2.0.
The implementation-spring-xml is here all about processing the XML of the Spring application
context, rather than the SCA XML. I suppose it could be combined with implementation-spring - since
that is what we have done in the case of BPEL. So here is a candidate for removal...
The implementation-spring-runtime contains code that gets very intimate with the Spring classes (eg.
some of our classes extend Spring classes). This is like the implementation-bpel-ode module and I
think it is essential in the 2.0 codebase to support OSGi cleanly. We are having to restructure
some of the classes to fit nicely and avoid awkward two-way cross-package dependencies.
OK, that is my pennyworth. Comments welcome.
Yours, Mike.
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 9:01 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, Apr 22, 2009 at 12:56 AM, ant elder <an...@apache.org> wrote:
> >
> >
> > Ok and thats the same as what Luciano just mentioned in another post to
> this
> > thread. So...if we had a way to enable/disable support for either
> namespace
> > independent of pulling modules in/out of the classpath would that address
> > this concern and then we would be ok to merge these modules?
> >
>
> Stepping back, what' s the problem we are trying to solve here ? I
> kind like the "Don' t fix what ain't broke" phrase [1]...
>
> [1] http://en.wikipedia.org/wiki/Wikipedia:AINT
>
>
>
I think it is "broke" :) We could make the runtime simpler if we had more
consistent use of fewer more functional modules and had a common understand
of when things can be in packages in the one module and when things need to
be in a separate module. We've consistently had users saying tuscany looks
really complicate as there are so many jars and no clear way to work out
what they're for and what they do, we end up with a spaghetti mess of
imports exports and dependencies that few understand, even just the build
and IDE development gets slower and more unwieldy as the number of modules
increases.
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 22, 2009 at 12:56 AM, ant elder <an...@apache.org> wrote:
>
>
> Ok and thats the same as what Luciano just mentioned in another post to this
> thread. So...if we had a way to enable/disable support for either namespace
> independent of pulling modules in/out of the classpath would that address
> this concern and then we would be ok to merge these modules?
>
Stepping back, what' s the problem we are trying to solve here ? I
kind like the "Don' t fix what ain't broke" phrase [1]...
[1] http://en.wikipedia.org/wiki/Wikipedia:AINT
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 22, 2009 at 8:56 AM, ant elder <an...@apache.org> wrote:
>
>
> On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Wed, Apr 22, 2009 at 8:45 AM, ant elder <an...@apache.org> wrote:
>> >
>> >
>> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <lu...@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <an...@apache.org>
>> >> wrote:
>> >> >> Are we talking only about extensions (bindings and implementations)
>> >> >> ?
>> >> >
>> >> > I'm suggesting everything.
>> >> >
>> >> >>
>> >> >> For other modules, I'd suggest we check case by case, as I have the
>> >> >> same concerns expressed by Raymond on this thread.
>> >> >>
>> >> >
>> >> > But what are those concerns? No one has ever given any technical
>> >> > reasons
>> >> > for
>> >> > keeping them separate that makes sense if we're not doing it
>> >> > consistently.
>> >> >
>> >>
>> >> Having the xml processors in a separate module would allow us execute
>> >> the compatibility stuff for 2.x discussed in [1]....
>> >>
>> >> [1] http://markmail.org/message/2cez45rwmj43jxwa
>> >>
>> >
>> > What specifically in there could we not do if the code was in a single
>> > module?
>> >
>> > ...ant
>> >
>> >
>> >
>>
>> My concern with this change would be backward compatibility. I had
>> hoped we could use different versions of "?-xml" to loaded different
>> spec namespaces into a single consistent model. Have been trying to
>> finish up some other things to haven't got to doing any of this in 2.x
>> other than I think Luciano created separate assembly-xml and
>> assembly-xml-osoa modules.
>>
>> Simon
>
> Ok and thats the same as what Luciano just mentioned in another post to this
> thread. So...if we had a way to enable/disable support for either namespace
> independent of pulling modules in/out of the classpath would that address
> this concern and then we would be ok to merge these modules?
>
> ...ant
>
Let me just be clear here. There is no technical requirement to have
separate -xml modules assuming that the processor classes are in
unique packages. Even to support backward compatibility. The switch is
made by the entries in META-INF/services and it doesn't matter if
those entries are in one module or three. This is a question of
clarity and, as you point out, the ability to enable/disable features
by adjusting the classpath. I think it's clearer to have these modules
separate. Certainly at the moment while we are not so advanced on the
backward compatibility issue.
Simon
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws <si...@googlemail.com>wrote:
> On Wed, Apr 22, 2009 at 8:45 AM, ant elder <an...@apache.org> wrote:
> >
> >
> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <lu...@gmail.com>
> > wrote:
> >>
> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <an...@apache.org>
> wrote:
> >> >> Are we talking only about extensions (bindings and implementations) ?
> >> >
> >> > I'm suggesting everything.
> >> >
> >> >>
> >> >> For other modules, I'd suggest we check case by case, as I have the
> >> >> same concerns expressed by Raymond on this thread.
> >> >>
> >> >
> >> > But what are those concerns? No one has ever given any technical
> reasons
> >> > for
> >> > keeping them separate that makes sense if we're not doing it
> >> > consistently.
> >> >
> >>
> >> Having the xml processors in a separate module would allow us execute
> >> the compatibility stuff for 2.x discussed in [1]....
> >>
> >> [1] http://markmail.org/message/2cez45rwmj43jxwa
> >>
> >
> > What specifically in there could we not do if the code was in a single
> > module?
> >
> > ...ant
> >
> >
> >
>
> My concern with this change would be backward compatibility. I had
> hoped we could use different versions of "?-xml" to loaded different
> spec namespaces into a single consistent model. Have been trying to
> finish up some other things to haven't got to doing any of this in 2.x
> other than I think Luciano created separate assembly-xml and
> assembly-xml-osoa modules.
>
> Simon
>
Ok and thats the same as what Luciano just mentioned in another post to this
thread. So...if we had a way to enable/disable support for either namespace
independent of pulling modules in/out of the classpath would that address
this concern and then we would be ok to merge these modules?
...ant
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 22, 2009 at 8:45 AM, ant elder <an...@apache.org> wrote:
>
>
> On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <lu...@gmail.com>
> wrote:
>>
>> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <an...@apache.org> wrote:
>> >> Are we talking only about extensions (bindings and implementations) ?
>> >
>> > I'm suggesting everything.
>> >
>> >>
>> >> For other modules, I'd suggest we check case by case, as I have the
>> >> same concerns expressed by Raymond on this thread.
>> >>
>> >
>> > But what are those concerns? No one has ever given any technical reasons
>> > for
>> > keeping them separate that makes sense if we're not doing it
>> > consistently.
>> >
>>
>> Having the xml processors in a separate module would allow us execute
>> the compatibility stuff for 2.x discussed in [1]....
>>
>> [1] http://markmail.org/message/2cez45rwmj43jxwa
>>
>
> What specifically in there could we not do if the code was in a single
> module?
>
> ...ant
>
>
>
My concern with this change would be backward compatibility. I had
hoped we could use different versions of "?-xml" to loaded different
spec namespaces into a single consistent model. Have been trying to
finish up some other things to haven't got to doing any of this in 2.x
other than I think Luciano created separate assembly-xml and
assembly-xml-osoa modules.
Simon
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <an...@apache.org> wrote:
> >> Are we talking only about extensions (bindings and implementations) ?
> >
> > I'm suggesting everything.
> >
> >>
> >> For other modules, I'd suggest we check case by case, as I have the
> >> same concerns expressed by Raymond on this thread.
> >>
> >
> > But what are those concerns? No one has ever given any technical reasons
> for
> > keeping them separate that makes sense if we're not doing it
> consistently.
> >
>
> Having the xml processors in a separate module would allow us execute
> the compatibility stuff for 2.x discussed in [1]....
>
> [1] http://markmail.org/message/2cez45rwmj43jxwa
>
>
What specifically in there could we not do if the code was in a single
module?
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 22, 2009 at 12:29 AM, ant elder <an...@apache.org> wrote:
>> Are we talking only about extensions (bindings and implementations) ?
>
> I'm suggesting everything.
>
>>
>> For other modules, I'd suggest we check case by case, as I have the
>> same concerns expressed by Raymond on this thread.
>>
>
> But what are those concerns? No one has ever given any technical reasons for
> keeping them separate that makes sense if we're not doing it consistently.
>
Having the xml processors in a separate module would allow us execute
the compatibility stuff for 2.x discussed in [1]....
[1] http://markmail.org/message/2cez45rwmj43jxwa
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 8:26 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, Apr 22, 2009 at 12:13 AM, ant elder <an...@gmail.com> wrote:
> >
> >
> > On Tue, Apr 21, 2009 at 1:35 PM, ant elder <an...@gmail.com> wrote:
> >>
> >> I think we've consensus now that instead of having three maven modules
> >> (model/model-xml/model-runtime) its ok to have the model and model-xml
> in a
> >> single module
> >
> > It seems that statement may not be true :(
> >
> > I think it would be good to be consistent on this across all the Tuscany
> > modules, right now its an arbitrary mix.
> >
> > I'd prefer not keeping the *-xml ones and think thats what we decided
> back
> > ages ago (Sebastien's idea i recall though i can't find the emails right
> > now). Are there any good reasons for not being consistent? or for keeping
> > any of the *-xml modules?
> >
> > You can't use Tuscany without stax. There are no external users I know of
> > that attempt to use the model modules without the -xml modules, we've
> always
> > had some of the xml code in the one module in some of the extensions so
> if
> > there are any users doing this then they're handling themselves ok
> anyway,
> > and thats probable quite easy as you just need to exclude stax (though
> this
> > seems like an obscure usecase to me), so whats the problem?
> >
>
> Are we talking only about extensions (bindings and implementations) ?
>
I'm suggesting everything.
>
> For other modules, I'd suggest we check case by case, as I have the
> same concerns expressed by Raymond on this thread.
>
>
But what are those concerns? No one has ever given any technical reasons for
keeping them separate that makes sense if we're not doing it consistently.
...ant
Re: Merging model and model-xml modules into one
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 22, 2009 at 12:13 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Apr 21, 2009 at 1:35 PM, ant elder <an...@gmail.com> wrote:
>>
>> I think we've consensus now that instead of having three maven modules
>> (model/model-xml/model-runtime) its ok to have the model and model-xml in a
>> single module
>
> It seems that statement may not be true :(
>
> I think it would be good to be consistent on this across all the Tuscany
> modules, right now its an arbitrary mix.
>
> I'd prefer not keeping the *-xml ones and think thats what we decided back
> ages ago (Sebastien's idea i recall though i can't find the emails right
> now). Are there any good reasons for not being consistent? or for keeping
> any of the *-xml modules?
>
> You can't use Tuscany without stax. There are no external users I know of
> that attempt to use the model modules without the -xml modules, we've always
> had some of the xml code in the one module in some of the extensions so if
> there are any users doing this then they're handling themselves ok anyway,
> and thats probable quite easy as you just need to exclude stax (though this
> seems like an obscure usecase to me), so whats the problem?
>
Are we talking only about extensions (bindings and implementations) ?
For other modules, I'd suggest we check case by case, as I have the
same concerns expressed by Raymond on this thread.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Tue, Apr 21, 2009 at 1:35 PM, ant elder <an...@gmail.com> wrote:
> I think we've consensus now that instead of having three maven modules
> (model/model-xml/model-runtime) its ok to have the model and model-xml in a
> single module
It seems that statement may not be true :(
I think it would be good to be consistent on this across all the Tuscany
modules, right now its an arbitrary mix.
I'd prefer not keeping the *-xml ones and think thats what we decided back
ages ago (Sebastien's idea i recall though i can't find the emails right
now). Are there any good reasons for not being consistent? or for keeping
any of the *-xml modules?
You can't use Tuscany without stax. There are no external users I know of
that attempt to use the model modules without the -xml modules, we've always
had some of the xml code in the one module in some of the extensions so if
there are any users doing this then they're handling themselves ok anyway,
and thats probable quite easy as you just need to exclude stax (though this
seems like an obscure usecase to me), so whats the problem?
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Tue, Apr 21, 2009 at 4:21 PM, Raymond Feng <en...@gmail.com> wrote:
> Why do we want to merge the model (xyz) with the model processing code
> (xyz-xml)? For simple extensions, it's fine to have the model and model-xml
> in the same maven module, but complex ones, such as assembly-xml,
> implementation-java-xml, I would rather leave them as separate modules. The
> model module can be used independent of the model-xml.
>
> Can you explain a bit the benefit to have them merged into one?
>
>
Because its simpler and more consistent, and i'm fairly sure the ones that
still exist aren't they for a specific reason they just remain as no one has
ever got around to merging them yet as has slowly been happening over time
with the ones that have already been merged. Why have them separate?
...ant
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
Why do we want to merge the model (xyz) with the model processing code (xyz-xml)? For simple extensions, it's fine to have the model and model-xml in the same maven module, but complex ones, such as assembly-xml, implementation-java-xml, I would rather leave them as separate modules. The model module can be used independent of the model-xml.
Can you explain a bit the benefit to have them merged into one?
Thanks,
Raymond
From: ant elder
Sent: Tuesday, April 21, 2009 5:35 AM
To: dev@tuscany.apache.org
Subject: Merging model and model-xml modules into one
I think we've consensus now that instead of having three maven modules (model/model-xml/model-runtime) its ok to have the model and model-xml in a single module, but we've still some model-xml modules in 2.x so i'd like to merge them into the associated model module. Please say if you've any objections.
...ant