Robert Burrell Donkin ha scritto:
On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <[EMAIL PROTECTED]> 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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
