james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mailets] Regex Mailets [WAS Re: Mailets and dependencies (Was: [PLANNING] Road map)]
Date Mon, 05 May 2008 10:23:15 GMT
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.

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

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.

> (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.

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.


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

View raw message