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.
