+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" <[email protected]>
Sent: Wednesday, April 22, 2009 7:43 AM
To: <[email protected]>
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.
