tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: [DISCUSS] Tuscany modularity, composability and usability
Date Mon, 05 Oct 2009 10:05:59 GMT
Thanks Raymond, there's some good points in that. I do think we need
to have the usability aspect a high priority and I mean that for both
Tuscany developers and users. Flexibility is all very good but unless
its done carefully it can make things unnecessarily complicated, so
another principle should be to make common use cases simple while
still supporting customization to allow for less common use cases.
Another point is that while it seems fine to require using Maven for
developing Tuscany it doesn't seem fine to require Maven for using
Tuscany, so we should make it straight forward to use Tuscany with
other build systems.

More comments in line below:

On Fri, Oct 2, 2009 at 10:28 PM, Raymond Feng <enjoyjava@gmail.com> wrote:

> 3) How to justify if two functions should be in the same module or separate
> module?
> 3.1 Are the two functions (A and B) can be used independently?
>  3.1.1 If A depends on B at compile time, then try to find out if another
> function C (inside or outside Tuscany) can use B without A. If such a
> function C exists, then A and B should be separate modules.
>  3.1.2 If A depends on B at runtime, there is a good opportunity that B can
> be replaced by another implementation (like the stax-api and woodstox). We
> should have A and B in separate modules.
>  3.1.3 If A doesn't depend on B, we should have A and B in separate modules
> unless they are both trivial and it won't add dependencies or footprint to
> have them in the same module.

I would change the wording in those three (which probably shows our
different points of view):

3.1.1 ...then A and B could be separate modules
3.1.2 ...then we should have the function B pluggable
3.1.3 ...then B could be in a separate module, for example if it
including it in an existing module adds significant extra dependencies
or overheads

and I'd add a another to that list:

3.1.4 when considering adding a new separate module first look at the
dependency hierarchy to see if there is another module that is already
shared by all uses of the new function where the function could
reasonably go


View raw message