[
https://issues.apache.org/jira/browse/JAMES-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-2129:
--
Labels: windows (was: )
> Mails in file repositories cannot be remo
On 20/08/2020 11:23, Rene Cordier wrote:
Based on Eugen comments in the INFRA ticket, I did this:
https://github.com/apache/james-project/pull/244 for redirecting
notifications to the new ML for this.
However I don't think as a commiter I can create the ML, so if a PMC
could manage that :)
On 19/08/2020 17:49, Eugen Stan wrote:
I've created an issue to make the ML changes:
https://issues.apache.org/jira/browse/INFRA-20735
--
Please add:
- notificati...@james.apache.org
Please remove:
- site-...@james.apache.org
- mailet-...@james.apache.org
Based on Eugen comments in the INFR
La 19.08.2020 09:59, Rene Cordier a scris:
>> I think we should have separate channels for:
>> - development: how we implement features and what features we work on
>> - users: how to use James:deploy it, create back-ups, etc.
>
> Those 2 mailing lists exist already I believe. We have `server-dev`
I think we should have separate channels for:
- development: how we implement features and what features we work on
- users: how to use James:deploy it, create back-ups, etc.
Those 2 mailing lists exist already I believe. We have `server-dev` for
development related things and `server-user` for
La 17.08.2020 07:45, David Leangen a scris:
I do think we might want to leverage this opportunity to close
low-traffic unused mailing lists. This includes:
My 2 cents:
From the user perspective, I think it would be desirable to trim down the
number of mailing lists. 😀
Thank you for ta
> I do think we might want to leverage this opportunity to close
> low-traffic unused mailing lists. This includes:
My 2 cents:
From the user perspective, I think it would be desirable to trim down the
number of mailing lists. 😀
Hi René
I did a quick review.
As such, given the limited content, I mostly agree with it.
I do think we might want to leverage this opportunity to close
low-traffic unused mailing lists. This includes:
 -site-...@james.apache.org : site discussions happens on server-dev and
not there, it is low
Hello,
There are things that need to me documented that are not technical:
- what / where are the project resources (website, CI, git repos,
mailing list)
- how to contribute, engage with the community
- etc.
Just to say I started migrating and writing this part of the
documentation here: h
> Migrating is not sexy work but is easier than writing new documentation.
Conditional on the structure and content being in a desirable state, I would
agree with this generalization. In this case, though, I don’t feel the
condition is me, so I think we’ll have to agree to disagree.
> I've add
La 31.07.2020 03:13, David Leangen a scris:
I've decided to add docs stubs to all repositories.
I'm going to start migrating the documentation for the popular libraries and
then decide what to do with the others (start the retiring process most likely).
Awesome! Nice initiati
> I've decided to add docs stubs to all repositories.
> I'm going to start migrating the documentation for the popular libraries and
> then decide what to do with the others (start the retiring process most
> likely).
Awesome! Nice initiative. Thanks!!
> Anyo
!
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
I've decided to add docs stubs to all repositories.
I'm going to start migrating the documentation for the popular libraries
and then deci
>> While working on the documentation website
I have been distracted by other work the past 2 weeks. I hope to get back to
this project within this week.
Thanks for helping to push it forward!
-
To unsubscribe, e-mail: serve
Le 20/07/2020 à 18:00, Eugen Stan a écrit :
> Hello,
>
> While working on the documentation website I ran into the question of:
> What parts to document?
>
> 1. What are the repositories we still use in James - some like jdkim
> have merged in james-project - others ?
No.
Th
Hello,
While working on the documentation website I ran into the question of:
What parts to document?
1. What are the repositories we still use in James - some like jdkim
have merged in james-project - others ?
2. Which ones we don't use?
3. Which projects we wish to retire - if an
JAMES-3006 Use Task factory in mail repositories routes
---
.../webadmin/routes/MailRepositoriesRoutes.java| 71 +++---
.../routes/MailRepositoriesRoutesTest.java | 12 ++--
2 files changed, 43 insertions(+), 40 deletions(-)
diff --git
a/server/protocols/webadmin
JAMES-2726 remove file repositories from cassandra mpt test
---
.../src/test/resources/mailetcontainer.xml | 6 +++---
.../src/test/resources/mailrepositorystore.xml | 5 ++---
mpt/impl/smtp/cassandra/src/test/resources/mailetcontainer.xml | 6
JAMES-2726 remove file mail repositories from cassandra projects
---
.../cassandra-ldap-guice/src/test/resources/mailetcontainer.xml | 6 +++---
.../cassandra-ldap-guice/src/test/resources/mailrepositorystore.xml | 5 ++---
.../cassandra-rabbitmq-guice/src/test/resources/mailetcontainer.xml | 6
JAMES-2726 Remove file repositories from guice/cassandra product tests
---
.../guice/cassandra-guice/src/test/resources/mailetcontainer.xml| 6 +++---
.../cassandra-guice/src/test/resources/mailrepositorystore.xml | 6 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git
3.3.0 Release: Remove 'MBox Repositories' documentation
---
src/site/xdoc/server/config-mailrepositorystore.xml | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/site/xdoc/server/config-mailrepositorystore.xml
b/src/site/xdoc/server/config-mailrepositorystore.xml
ind
JAMES-2665 Default vault path was incompatible with file repositories
Incriminated: the / prefix, trying to access the root of the file system
---
.../java/org/apache/james/modules/vault/DeletedMessageVaultModule.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a
[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
Hello Apache projects,
I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
JAMES-2556 Fix reprocessing when several repositories with same path
We need to aggregate repositories to check for mail existence before
reprocessing
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/9d52d569
MAILBOX-342 Use CassandraModule.Builder for Cassandra mail repositories
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/b100add1
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/b100add1
Diff
.com/linagora/james-project/pull/1270
> Webadmin CRUD for mail repositories
> ---
>
> Key: JAMES-2293
> URL: https://issues.apache.org/jira/browse/JAMES-2293
> Project: James Server
>
JAMES-2291 Introduce Mail repositories keys DAO
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/203b3d21
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/203b3d21
Diff: http://git-wip
JAMES-2291 Introduce Mail repositories count DAO
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/d4d0c8fd
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/d4d0c8fd
Diff: http://git-wip
implemented
here.
> Webadmin CRUD for mail repositories
> ---
>
> Key: JAMES-2293
> URL: https://issues.apache.org/jira/browse/JAMES-2293
> Project: James Server
> Issue Type: New Feature
>
[
https://issues.apache.org/jira/browse/JAMES-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tellier Benoit closed JAMES-2293.
-
> Webadmin CRUD for mail repositories
> ---
>
>
JAMES-2293 Introduce route for mail repositories
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/6b2d54fa
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/6b2d54fa
Diff: http://git-wip
JAMES-2293 Webadmin should allow to list mail in repositories
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/d423ef05
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/d423ef05
Diff: http://git
Tellier Benoit created JAMES-2293:
-
Summary: Webadmin CRUD for mail repositories
Key: JAMES-2293
URL: https://issues.apache.org/jira/browse/JAMES-2293
Project: James Server
Issue Type: New
letProcessor.java:82)
at java.lang.Thread.run(Thread.java:745)
The java process still holds a file handle to the FileStreamStore file.
> Mails in file repositories cannot be removed
>
>
> Key: JAMES-2129
>
Markus Moeller created JAMES-2129:
-
Summary: Mails in file repositories cannot be removed
Key: JAMES-2129
URL: https://issues.apache.org/jira/browse/JAMES-2129
Project: James Server
Issue
On 2015-09-07 14:53, Matthieu Baechler wrote:
Hi,
Following my proposal about James modules merge, I'm looking at how
exactly this merge can be done.
I didn't find a good way to merge things using svn tools (in theory, it
can be done with svnadmin dump / svnadmin load but these tools are not
m
On 07/09/2015 15:14, Stefano Bagnara wrote:
What about creating the merge tree in svn and then clone on git the
resulting svn repository?
In SVN the merge can be done with a simple "svn cp" and it keeps history.
Stefano
Oh yes, I just forgot it's actually a single svn repository, not several
What about creating the merge tree in svn and then clone on git the
resulting svn repository?
In SVN the merge can be done with a simple "svn cp" and it keeps history.
Stefano
On 7 September 2015 at 14:53, Matthieu Baechler wrote:
> Hi,
>
> Following my proposal about James modules merge, I'm lo
Hi,
Following my proposal about James modules merge, I'm looking at how
exactly this merge can be done.
I didn't find a good way to merge things using svn tools (in theory, it
can be done with svnadmin dump / svnadmin load but these tools are not
made for remote experiments).
I managed to
back into apache repositories.
We are working toward using github for our developments to add
transparency to our process and have others people join our code reviews.
We are doing the switch right now but we discovered that there's two
repositories missing from git.apache.org : james-mp
Hi,
Now that Benoit Tellier is Commiter on James, we (Antoine, Benoit and
me) managed to merge most of our work back into apache repositories.
We are working toward using github for our developments to add
transparency to our process and have others people join our code reviews.
We are
cle javamail so that
> we don't need "repositories" entry in pom.
> ---
>
> Key: PROTOCOLS-40
> URL: https://issues.ap
s a dependency for javamail instead of oracle javamail so that
> we don't need "repositories" entry in pom.
> ---
>
> Key: PROTOCOLS-4
ncy for javamail instead of oracle javamail so that
> we don't need "repositories" entry in pom.
> ---
>
> Key: PROTOCOLS-4
Use geronimo as a dependency for javamail instead of oracle javamail so that we
don't need "repositories" entry in pom.
---
Key: PROTOCOLS-40
ng it;
> Provide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
> Project: JAMES
opy user repositories
>
>
> Key: JAMES-1090
> URL: https://issues.apache.org/jira/browse/JAMES-1090
> Project: JAMES Server
> Issue Type: Improvement
> Components: UsersStore &
close it
> Provide a tool to copy user repositories
>
>
> Key: JAMES-1090
> URL: https://issues.apache.org/jira/browse/JAMES-1090
> Project: JAMES Server
> Issue Type: Improvement
>
3.0).
> Provide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
> Project: JAMES S
?
In JAMES-1052, to copy the mails from 2.3 to 3.0, we first need to create the
users.
So, copying the mails, we copy the users.
Do we need a separate tool to copy users? I don't think so...
> Provide a tool to copy user repositories
>
>
>
opy user repositories
>
>
> Key: JAMES-1090
> URL: https://issues.apache.org/jira/browse/JAMES-1090
> Project: JAMES Server
> Issue Type: Improvement
> Components: User
Provide a tool to copy user repositories
Key: JAMES-1090
URL: https://issues.apache.org/jira/browse/JAMES-1090
Project: JAMES Server
Issue Type: Improvement
Components: UsersStore
ate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
> Project: JAMES Server
> Is
r M1)
> Provide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
> Project: JAMES S
ovide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
> Project: JAMES Server
>
, we cover all needed data.
WDYT ?
> Provide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
> -
>
> Key: JAMES-1052
> URL: https://issues.apache.org/jira/browse/JAMES-1052
Provide a tool to migrate 2.3 mail-repositories to 3.0 mailbox-stores
-
Key: JAMES-1052
URL: https://issues.apache.org/jira/browse/JAMES-1052
Project: JAMES Server
Issue
rk on this in the near
future.
> Mail/Spool/Message repositories refactoring
> ---
>
> Key: JAMES-521
> URL: https://issues.apache.org/jira/browse/JAMES-521
> Project: James
>
Noel J. Bergman ha scritto:
>> It would still be cool to have the artifacts on the repository
>
> Define "artifacts."
>
> --- Noel
All of the JARs we create are artifacts.
The james.sar is an artifact.
A javadoc jar is an artifact
A sources jar is an artifact
Imho every redistributable pa
Hi,
On 5/3/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> It would still be cool to have the artifacts on the repository
Define "artifacts."
The James jar files and associated pom metadata. For example having
mailet-api-2.3.jar and mailet-api-2.3.pom on the repository would be
great.
BR,
> It would still be cool to have the artifacts on the repository
Define "artifacts."
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
y nice if the artifacts were readily available
> for Maven projects.
>
> BR,
>
> Jukka Zitting
The last cause that we never published artifacts to maven repositories
is because we are trying to not use remote repositories for our
products, so we never had a real need for this.
Y
Jukka Zitting ha scritto:
> Hi,
>
> On 5/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Unfortunately, even in you find a pom.xml in the James SERVER root,
>> James SERVER is not a maven2 application. We use ant/build.xml to
>> build the application. The pom is there mainly for the website
>>
Hi,
On 5/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Unfortunately, even in you find a pom.xml in the James SERVER root,
James SERVER is not a maven2 application. We use ant/build.xml to
build the application. The pom is there mainly for the website generation.
It would still be cool to h
Stefano Bagnara ha scritto:
> Jukka Zitting ha scritto:
>> Hi,
>>
>> I wanted to experiment writing custom mailets, but found out that none
>> of the James artifacts are available on the central Maven repository.
>> I installed them locally so it's not a direct problem for me, but I
>> think it wou
Jukka Zitting ha scritto:
> Hi,
>
> I wanted to experiment writing custom mailets, but found out that none
> of the James artifacts are available on the central Maven repository.
> I installed them locally so it's not a direct problem for me, but I
> think it would be very nice if the artifacts we
Hi,
I wanted to experiment writing custom mailets, but found out that none
of the James artifacts are available on the central Maven repository.
I installed them locally so it's not a direct problem for me, but I
think it would be very nice if the artifacts were readily available
for Maven projec
Noel J. Bergman wrote:
http://people.apache.org/repo/m2-ibiblio-rsync-repository
http://people.apache.org/repo/m1-ibiblio-rsync-repository
Uh ... are we supposed to publish a POM containing those URLs? Doesn't that
drive the traffic to our non-mirrored server?
3) retrieve any missing *m2
uld be ${inboxrepository}/${localpart}.
Please note that the ${variable} is only an example and we may use any
other way to dynamically declare the final repository.
(See comments in JAMES-414 about this)
Mail/Spool/Message repositories refactoring
-
epository@, when
they spoke against using the download mechanism and said to use local,
file-based, repositories because of problems with Maven-driven traffic and
security issues that was different?
I'm not sure I fully understant the maven-driven traffic.
A developer that download sources f
or difference).
Which words? What did you read from any of the folks on repository@, when
they spoke against using the download mechanism and said to use local,
file-based, repositories because of problems with Maven-driven traffic and
security issues that was different?
> Yes, project has now
n JAMES-414 about this)
Mail/Spool/Message repositories refactoring
---
Key: JAMES-521
URL: http://issues.apache.org/jira/browse/JAMES-521
Project: James
Issue Type: Task
Components: James Co
> http://people.apache.org/repo/m2-ibiblio-rsync-repository
> http://people.apache.org/repo/m1-ibiblio-rsync-repository
Uh ... are we supposed to publish a POM containing those URLs? Doesn't that
drive the traffic to our non-mirrored server?
> 3) retrieve any missing *m2* *plugin* from ibibl
On 10/1/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I use minotaur for the distribution management: in fact we are not using
>> that part now because we don't use site deployment by maven.
>
> i'm think that you might find that it's now broken. AIUI minotaur is
quot;file://var/incoming/${currentyear}${currentmonth}". By default it would be
${inboxrepository}/${localpart}.
Please note that the ${variable} is only an example and we may use any other
way to dynamically declare the final repository.
(See comments in JAMES-414 about this)
> Mail/Spo
robert burrell donkin wrote:
I use minotaur for the distribution management: in fact we are not using
that part now because we don't use site deployment by maven.
i'm think that you might find that it's now broken. AIUI minotaur is
not accessible for site deployment any more.
Well, we never u
On 10/1/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> BTW using minotaur.apache.org in a pom is not recommended. please use
> an appropriate virtual host (for example people.apache.org).
>
> - robert
I use minotaur for the distribution management: in fact we
.
Actually we touch ASF servers: in our james-project (parent pom) we
define this repositories:
central
Apache Main M2 Repository
http://people.apache.org/repo/m2-ibiblio-rsync-repository
true
true
central-m1
Apache Main M1 Repository
http://people.apache.org/repo/m1-ibiblio-rsync
On 10/1/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Noel J. Bergman wrote:
> Dims, Steve and Henri did reply to you with very consistent responses. As I
> understood the suggestion, it is the same as Norman uses, or at least
> similar: define a local, file-based, repository. Dims, Steve
ntained trees,
with the common site related information factored out, what does projects/
do for us? It has a {ttb} structure, so what is project/ as a separately
versioned entity?
Postage already depends on james-server: so we already have this
dependency between products in our repositor
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
>>> It contains the commons informations for the James project (website,
>>> repositories, developers, licenses). Think at it as the AbstractPOM
>>> for our POMs (m2 has many Object Oriented things in its architectu
I'm just writing this because when we'll refactor Mail repositories (or
better introduce Message repositories) there are 2 things that would
help performace and allow us to "reactivate" this optimisations:
1) Keep headers and body in 2 different resources (this allow us to
e
[ http://issues.apache.org/jira/browse/JAMES-521?page=all ]
Norman Maurer updated JAMES-521:
Fix Version: 3.0
(was: 2.4.0)
> Mail/Spool/Message repositories refactoring
> ---
>
>
vn.joachim-draeger.de/repos/james/imap/src/site/xdocs/
Named Repositories
Internally ImapMailboxRepository deals with named repositories that
could have different implementations. E.g. JDBC connections to different
hosts or Maildir / Mbox like stores.
This repositories are identified by its names and
Stefano Bagnara wrote:
An alternative is (if we really care about switching implementations)
is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl
we could code share (as you say), or whatever's appropriate.
There could be intersections. There are algorithms needed for IMAP
Joachim Draeger wrote:
- MessageKey created while storing, and not userprovided.
This would make implementation of existing standard a lot easier. Are
there disadvantages? When I store the same message into different
repositories I've to care about the repository keys myself when I
Joachim Draeger wrote:
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfac
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfaces that
mirror the metho
On 6/2/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
The biggest design deficiency of Javamail is the lack of interfaces. That's why
using javamail means being limited in hierarchy, and being unable to completely
replace implementations.
This is an interesting point... should we create interfa
geKey created while storing, and not userprovided.
This would make implementation of existing standard a lot easier. Are there
disadvantages? When I store the same message into different repositories I've to
care about the repository keys myself when I want to access them again. Instead
o
Mail/Spool/Message repositories refactoring
---
Key: JAMES-521
URL: http://issues.apache.org/jira/browse/JAMES-521
Project: James
Type: Task
Components: James Core, MailStore & MailRepository
Reporter: Stefano Bag
- Original Message -
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Monday, May 22, 2006 1:37 AM
Subject: Re: James 2.4 and repositories...
Markus Kühn wrote:
My motivation is that if I want to add or change something in the f
Markus Kühn wrote:
My motivation is that if I want to add or change something in the future
it is easier for me if I don't have to catch up big changes resulting
from many different changes like refactoring or splitting on method into
2 and so on.
Refactoring is the heart of programming. If y
- Original Message -
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Monday, May 22, 2006 12:59 AM
Subject: Re: James 2.4 and repositories...
I don't consider myself a new coder on James, but I think that merging 2
interf
Markus Kühn wrote:
- Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Monday, May 22, 2006 12:35 AM
Subject: Re: James 2.4 and repositories...
Sorry, I don't understand your points.
In fact I'm
- Original Message -
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Monday, May 22, 2006 12:35 AM
Subject: Re: James 2.4 and repositories...
Sorry, I don't understand your points.
In fact I'm talking of changes to imp
Markus Kühn wrote:
- Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Sunday, May 21, 2006 4:18 PM
Subject: Re: James 2.4 and repositories...
The reasoning behind the choice to merge MailRepository to
SpoolRepo
- Original Message -
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Sunday, May 21, 2006 4:18 PM
Subject: Re: James 2.4 and repositories...
The reasoning behind the choice to merge MailRepository to SpoolRepository
and introdu
Noel J. Bergman wrote:
Stefano Bagnara wrote:
This is way past 2.4, but other than that ... :-)
1) Remove the MailRepository interface and up-merge MailRepositories in
SpoolRepositories.
Although today the SpoolRepository is a specialized MailRepository, they are
actually quite different, an
Stefano Bagnara wrote:
1) Remove the MailRepository interface and up-merge MailRepositories in
SpoolRepositories. SpoolRepository is a superset of MailRepository, they
share the same storage formats, there's no need to keep them both: we
always can provide SpoolRepositories when people asks fo
1 - 100 of 157 matches
Mail list logo
