james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [mailets] Regex Mailets [WAS Re: Mailets and dependencies (Was: [PLANNING] Road map)]
Date Mon, 05 May 2008 15:36:21 GMT
On Mon, May 5, 2008 at 11:23 AM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> >
> > On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <apache@bago.org> wrote:
> >
> > >  matchers/FetchedFrom
> > >  [ ...dozens of matcher/mailets... ]
> > >  mailets/AddHabeasWarrantMark
> > >
> >
> >
> > a number of these mailets are coupled to apache oro. i wanted to avoid
> > introducing a dependency between standard-mailets and oro. i would
> > prefer to create a new micro-library product (regex-mailets) to factor
> > the dependency accurately.
> >
> > opinions?
> >
>  I will probably move to +1 once I see we are able to release at least a
> first version of mailet-api, mailet-base, mailet-crypto, mailet-standard,
> update the website according to this and being succesfull in this action.
>  In the mean time I *fear* creating so many micro libraries, so -0.

it's a train: mailet-api will have to be released first and that will
take a while but there's no reason to wait

micro-libraries are justifiably popular in the open source world.
JAMES has lots of good stuff in but it doesn't allow me to pick and
mix and comes with a huge number of dependencies.

>  Since the last public release we moved from 1 monolithic project to 2
> projects (mailet+server) having 4 and 25 modules respectively. This is
> already a big step,

it's not a big step: it's just moving the code around. easy enough to
move it back again.

> why don't we test this approach with a real release
> process and collect feedback before moving to a 1-module-per-class
> structure? ;-)

that's your itch: stratch it

>  You think that being monolithic was the main issue why we are not able to
> release trunk, but we now have jsieve, mime4j, mailet-api that are not
> monolithic and could be released but we're not releasing them, so it is not
> so obvious to me.

that's mistating my position

releasing trunk requires attracting enough developers who are
interested in trunk. at the moment, there are too few developers who
are interested in trunk and too many that are concerned about quality.
this breaks down into encouraging developers to work together on the
same code (rather than in branches) and recruiting new developers.

the modular build allows developers to work in new modules rather than
forking the complete codebase on a branch. what development is
happening, is now at least happening on trunk.

factoring out stuff into independent libraries allows the code to be
shared between the 2.3.x and 3.x codebases without the need for
backports. so developers more interested in the stable release can
indirectly contribute to trunk by changing these libraries.

JAMES has consistently failed to convert prospective developers into
committers. i accept the argument about encouraging more users but
converting users into developers but this is typically a very
inefficient process. we lack the energy to maintain a buggy codebase
and push development forward.

more components can help here too: it's much easier and quick to learn
a microlibrary than a large monolithic codebase.

> > (as might be expected from my background, i believe that
> > micro-libraries are good for developers and good for users. they are
> > quick and easy for new developers to understand since the codebase is
> > small, have limited dependencies and have a clear aim. tight
> > dependencies and a small codebase means that they can grab just what
> > they need, and a clear aim makes it easy to find what they are looking
> > for. the down side is that it makes it harder to grab everything. one
> > solution is to ship an product which contains abolutely everything.)
> >
> > - robert
> >
>  I already find it more difficult to find code in the current multi module,
> multi project structure.
>  Now, often it takes me a "find" when I look for a given class, while when
> we had the monolithic structure I always knew where to find each class at my
> first attempt. It was easier to find references to each functions, to build
> call trees and to find unused public methods.

that's because you knew the codebase well

from an outsiders perspective, JAMES is too big and the packages are
too often illconceived. it takes too long to learn.

but if it offends you, stop whinging and do something about it: post a
concrete proposal.

>  Furthermore (not for mailets, but about the generic micro-libraries issue)
> once you extract some code to a library you "implicitly" declare a public
> api, so this would mean that we are making "public" something that
> previously was internal interface, so we must be ready to support that api
> and its versioning.

it matters not whether the code is in a library or not. JAMES does a
very poor job in communication which interfaces will be retained
between versions and which are likely to be modified. this encourages

- robert

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

View raw message