Re: [Users] Split into components

[Robert Burrell Donkin <ro...@gmail.com>]

On Nov 30, 2007 7:52 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Nov 25, 2007 6:34 PM, Robert Burrell Donkin
> > <ro...@gmail.com> wrote:
> >> On Nov 25, 2007 6:06 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >>> Robert Burrell Donkin ha scritto:
> >
> > <snip>
> >
> >>>> 5 unsure about the granularity of avalon-user-function and
> >>>> jdbc-user-function. lots of small components allows precision but
> >>>> perhaps might be better to aggregate into large units including all
> >>>> backend implementation of the same type. for example,
> >>>> avalon-backend-function including all the avalon* implementations
> >>>> (AvalonRepository and so on).
> >>>>
> >>>> opinions?
> >>> IMO it's better to aggregate jdbc-user-function to avalon-user-function.
> >> why?
> >
> > i've adopted stefano's suggestion but a longer explanation would be appreciated
> >
> > - robert
>
> My main motivation was about having a limited number of modules.

ok - so this is where the arguments about component granularity kick off ;-)

> IMHO we should keep the number of modules under the 20, otherwise it
> will become worse than the old all-in-one structure.

setting an arbitrary number defeats the whole purpose of the process :-)

separating JAMES out into logical components reveals and expresses the
coupling within the system. a finely grained component structure will
make dependencies more obvious.

it should be possible to assemble smaller, lighter applications from
the JAMES components. many users seem to want this. ATM it's not
really possible to do this safely.

it should be possible to retain a much more diverse, interesting and
useful codebase if a standard, lightweight JAMES can be cut by
removing components. users wanting optional or non-standard modules
would need to build from source.

> IMHO having modules with very few classes in there does not make too
> much sense: I prefer to use java packages for that.

the packaging in JAMES is very coursely grained and cuts across
functional devisions. for example, APIs for every sort of service are
packaged in org.apache.james.services and so if you want POP3 then you
have to take IMAP. i would like to fix the packaging but i understand
why people want to preserve config files. separating the codebase into
a finely grained component structure is a reasonable substitute and
can be done immediately.

this process will inevitably go too far. (IMAP has too many modules.)
but this is an exercise in comprehension. once the code has been
broken down and the dependencies fixed then we can reaggregate.

> IMHO too many modules is an anti pattern.

define too many without selecting an arbitrary numeric value :-)

i think that JAMES needs to move towards finely grained COP ATM. this
will allow the dependencies to be fixed in an evolutionary manner.

IMHO the future for trunk should be pruned releases. experimental and
innovative code should be allowed in trunk without having to convince
people of it's value a priori. first, the APIs are finalised on trunk.
(hence API modules.) before a release, immature modules and general
cruft would be pruned on the release branch. these modules which
didn't make the cut would still be available by compilation of a tag.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [Users] Split into components

[Danny Angus <da...@apache.org>]

On 11/12/2007, Robert Burrell Donkin <ro...@gmail.com> wrote:

> this process will inevitably go too far. (IMAP has too many modules.)

+1 I've seen this at work too, but it is still a useful way to explode
the big ball of mud.

> but this is an exercise in comprehension. once the code has been
> broken down and the dependencies fixed then we can reaggregate.

We can, but I'm betting that by the time we should we won't want to anymore.
If the build-test-release cycle is efficient enough there's no real
incentive, and it helps stop the ball of mud from reforming.

>
> > IMHO too many modules is an anti pattern.
>
> define too many without selecting an arbitrary numeric value :-)

Literally? n+1 where n is the optimum number. ;-) (Sorry!)

>
> i think that JAMES needs to move towards finely grained COP ATM. this
> will allow the dependencies to be fixed in an evolutionary manner.

+1 we need to expose our internal dependencies,  which is where the
pain of making changes comes from, so that we can see them clearly and
manage them effectively.

> IMHO the future for trunk should be pruned releases. experimental and
> innovative code should be allowed in trunk without having to convince
> people of it's value a priori. first, the APIs are finalised on trunk.
> (hence API modules.) before a release, immature modules and general
> cruft would be pruned on the release branch. these modules which
> didn't make the cut would still be available by compilation of a tag.

Sounds like a sensible approach for managing this.

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org