You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/04/22 21:39:58 UTC
[mailet] split into api and base then release...? [WAS Re: [crypto] Open For Business]
On Tue, Apr 22, 2008 at 9:27 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
<snip>
> > 2. it uses mailet-api-3.0-SNAPSHOT. i would prefer to use the last
> > mailet release.
> >
>
> +1
> Furthermore IIRC current mailet-api trunk is really similar to mailet 2.3.
> So maybe a mailet-api 2.3.1 (should be backward compatible) should be made,
> too, before moving to 3.0-SNAPSHOT.
there are some small changes made before the mailet project was
separated from james which crypto depends on so a new release will be
necessary. i'm not sure whether there are any api changes.
ATM http://svn.apache.org/repos/asf/james/mailet/api/trunk/ contains
both the API and utility classes. the 2.3.1 release has mailet and
mailet-api jars. IMHO it would make sense to split the mailet-api
product into a similar way: mailet-api (containing just the API) and
mailet-base (containing the utility classes currently in mailet/api.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailet] split into api and base then release...?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Apr 22, 2008 at 9:24 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> > ATM http://svn.apache.org/repos/asf/james/mailet/api/trunk/ contains
> > both the API and utility classes. the 2.3.1 release has mailet and
> > mailet-api jars. IMHO it would make sense to split the mailet-api
> > product into a similar way: mailet-api (containing just the API) and
> > mailet-base (containing the utility classes currently in mailet/api.
> >
> > opinions?
> >
>
> IIRC the separation in mailet and mailet-api jar seems a little random ;-)
>
> Mailet class is in mailet-api.jar, Matcher is in the mailet.jar !?
>
> So Matcher, MatcherConfig and MailetException are not in mailet-api, while
> maybe they should be.
i definitely that the existing split is unhelpful
> ATM there are really so many classes that I would be tempted in releasing a
> single jar, on the other hand I know that we'll need an "utility" library to
> be able to move some more mailet from server to a mailet library, so maybe
> "base" will be able to host them too.
yes
there are some which are clearly utility classes:
org.apache.mailet.dates.*
org.apache.mailet.Generic*
org.apache.mailet.RFC2822Headers
IMHO this is a sufficient critical mass to start with. the remainer
should be discussed on the mailet-api list.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailet] split into api and base then release...?
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> ATM http://svn.apache.org/repos/asf/james/mailet/api/trunk/ contains
> both the API and utility classes. the 2.3.1 release has mailet and
> mailet-api jars. IMHO it would make sense to split the mailet-api
> product into a similar way: mailet-api (containing just the API) and
> mailet-base (containing the utility classes currently in mailet/api.
>
> opinions?
IIRC the separation in mailet and mailet-api jar seems a little random ;-)
Mailet class is in mailet-api.jar, Matcher is in the mailet.jar !?
So Matcher, MatcherConfig and MailetException are not in mailet-api,
while maybe they should be.
ATM there are really so many classes that I would be tempted in
releasing a single jar, on the other hand I know that we'll need an
"utility" library to be able to move some more mailet from server to a
mailet library, so maybe "base" will be able to host them too.
In the end.. +1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org