+1
On Sunday 03 February 2008 01:09, Danny Angus wrote:
> Hi,
>
> I just want to get this recorded, Jukka is a commiter on this project
> but has agreed to limit his contribution to the sandbox.
>
> If you agree that Jukka's limited agreement to commit only to the
> sandbox be lifted and it be unde
.. and FWIW my vote...
On Feb 3, 2008 12:09 AM, Danny Angus <[EMAIL PROTECTED]> wrote:
[X] +1 I agree that Jukka should be allowed to commit anywhere in
James codebase
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
Hi,
I just want to get this recorded, Jukka is a commiter on this project
but has agreed to limit his contribution to the sandbox.
If you agree that Jukka's limited agreement to commit only to the
sandbox be lifted and it be understood that Jukka is now trusted to
commit wherever he feels appropr
I did the "v3" stuff and the sandbox stuff isn't very different, look
at it, I can do it all again.
The problems are really only...
1/ some of the interfaces that you need to move to mailet aren't
totally normalised, IOW they are a bit hacked to make them work in
James not the way you would design
On Feb 2, 2008 4:51 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > i agree in principle but trunk has a lot of JAMES-specific mailets
> > (but i suspect that many of these could be decoupled)
>
> I would say "some" instead of "many" ;-)
:-P
> > the problem
On Feb 2, 2008 6:39 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > i now wonder whether it might be better to aggregate backend classes
> > according to the technologies they use. so (for example) any backend
> > code that uses torque would be in a torque-bac
On Feb 2, 2008 8:04 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> On Feb 2, 2008 11:13 AM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
>
> > i now wonder whether it might be better to aggregate backend classes
> > according to the technologies they use. so (for example) any backend
> > code t
On Feb 2, 2008 6:39 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > i now wonder whether it might be better to aggregate backend classes
> > according to the technologies they use. so (for example) any backend
> > code that uses torque would be in a torque-bac
On Feb 2, 2008 8:24 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann ha scritto:
> > Hi,
> >
> > with the release of the OSGi extension to Spring[1], it seems to be
> > reasonably easy to turn any spring app into an OSGi deployment ('bundle').
> >
> > I'd like to try and make the s
Bernd Fondermann ha scritto:
Hi,
with the release of the OSGi extension to Spring[1], it seems to be
reasonably easy to turn any spring app into an OSGi deployment ('bundle').
I'd like to try and make the spring deployment OSGi-deployable this way.
In a first step, this would only mean 'depl
Jukka Zitting ha scritto:
On Feb 2, 2008 5:42 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
i'd like to copy james-jcr into trunk and add some example
configurations. development can continue in the sandbox (or not) and
merged in later (if necessary).
You'll
On Feb 2, 2008 11:13 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> i now wonder whether it might be better to aggregate backend classes
> according to the technologies they use. so (for example) any backend
> code that uses torque would be in a torque-backend module, any code
> that uses
Hi,
On Feb 2, 2008 5:42 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > i'd like to copy james-jcr into trunk and add some example
> > configurations. development can continue in the sandbox (or not) and
> > merged in later (if necessary).
You'll likely need
Robert Burrell Donkin ha scritto:
i now wonder whether it might be better to aggregate backend classes
according to the technologies they use. so (for example) any backend
code that uses torque would be in a torque-backend module, any code
that uses avalon to store data in a avalon-backend module
On Feb 2, 2008 2:14 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> i'd like to copy james-jcr into trunk and add some example
> configurations. development can continue in the sandbox (or not) and
> merged in later (if necessary).
+1
Bernd
--
Robert Burrell Donkin ha scritto:
i agree in principle but trunk has a lot of JAMES-specific mailets
(but i suspect that many of these could be decoupled)
I would say "some" instead of "many" ;-)
the problem is that many common problems solved by mailets require
access to basic services which
+1 jcr has some drawbacks (afaik there's still a jackrabbit hard limit
of a few thousand docs per node which is too few for a big mail
deployment) but IMHO is well worth having in trunk to allow people to
experiment. Its an area that has a lot of current interest (with the
resurgence of CRM, and al
On Feb 2, 2008 12:57 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> i agree in principle but trunk has a lot of JAMES-specific mailets
> (but i suspect that many of these could be decoupled)
Very many of them can.
>
> i think that it would be a good plan to pull out those mailets which
>
Robert Burrell Donkin ha scritto:
i'd like to copy james-jcr into trunk and add some example
configurations. development can continue in the sandbox (or not) and
merged in later (if necessary).
any objections?
- robert
+1
And I would prefer if development will continue in trunk. If it does no
Robert Burrell Donkin ha scritto:
since the mailbox manager APIs are not ready for release, i'd like to
move the code out from core and into separate modules
any objections?
+1
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTEC
Author: rdonkin
Date: Sat Feb 2 06:02:40 2008
New Revision: 617799
URL: http://svn.apache.org/viewvc?rev=617799&view=rev
Log:
Unused
Removed:
james/server/trunk/imap-api/src/main/java/org/apache/james/api/imap/message/response/imap4rev1/messagedata/Body.java
james/server/trunk/imap-api
since the mailbox manager APIs are not ready for release, i'd like to
move the code out from core and into separate modules
any objections?
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E
i'd like to copy james-jcr into trunk and add some example
configurations. development can continue in the sandbox (or not) and
merged in later (if necessary).
any objections?
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
On Jan 30, 2008 10:53 PM, Steve Brewin <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote on 29 January 2008 21:28:
>
>
> > On Jan 28, 2008 2:37 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > >
> > > Robert Burrell Donkin ha scritto:
> > > > On Jan 26, 2008 4:48 PM, Stefano Bagnara <[EMAI
On Feb 2, 2008 10:36 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Jan 31, 2008 8:51 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> > Jukka Zitting wrote:
> > > I was trying to build the current James server trunk and set it up as
> > > a simple dependency that I could just start
i've been thinking on the recent threads on modules eg [1]
i think that the current system is ok for protocol integration (SMTP,
POP3, etc) but backends don't really fit very well. for example,
avalon-user-function, torque-mailboxmanagerfunction etc don't make as
much sense. i am still convinced t
On Jan 31, 2008 8:51 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> Jukka Zitting wrote:
> > Hi all,
> >
> > As you may have noticed, in the past few days I've again committed
> > some updates to the james-jcr sandbox component. The main changes are
> > about extracting the Message->JCR storage
Author: rdonkin
Date: Sat Feb 2 02:02:46 2008
New Revision: 617776
URL: http://svn.apache.org/viewvc?rev=617776&view=rev
Log:
Subscription implementation complete
Modified:
james/server/trunk/experimental-seda-imap-function/src/test/resources/org/apache/james/test/functional/imap/scripts/Su
An automated nightly build of JAMES has been posted to
http://people.apache.org/builds/james/nightly/
Any unit test errors from the build should be reported below:
-
29 matches
Mail list logo
