[
https://issues.apache.org/jira/browse/JAMES-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-4067:
--
Component/s: Documentation
> Homepage: Roadmap upd
[
https://issues.apache.org/jira/browse/JAMES-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier reassigned JAMES-4067:
-
Assignee: René Cordier
> Homepage: Roadmap upd
Thanks for the feedback, Ic reated a JIRA issue resuming all of this:
https://issues.apache.org/jira/browse/JAMES-4067\
Cheers,
Rene.
On 8/28/24 2:50 PM, btell...@linagora.com wrote:
Hello,
Thanks for bringing the roadmap refresher topic up!
Should we add as well a roadmap section in
keep improving / add missing bits to it/
Also, linking those items to EPIC/Jira existing (or need to create if not)
issues
> Homepage: Roadmap update
>
>
> Key: JAMES-4067
> URL: https://issues.apache.org/jira/browse/JAM
René Cordier created JAMES-4067:
---
Summary: Homepage: Roadmap update
Key: JAMES-4067
URL: https://issues.apache.org/jira/browse/JAMES-4067
Project: James Server
Issue Type: Improvement
Hello,
Thanks for bringing the roadmap refresher topic up!
Should we add as well a roadmap section in Antora doc for example?
Duplicated information is a recipe for partial updates and consistency
issues.
(True with Cassandra, even more with humans)
So IMO -1.
On 28/08/2024 08:20
here are Epics/Parent Jira issues for the various
items could it be worth linking to them from the roadmap ?
- Guice based applications: been promoted, just still need the removal
> step on James 4.0.0
>
I think the deprecation notice should remain on the roadmap
> - anything else worth men
Hello guys,
As I saw stated on the gitter channel, our roadmap documentation part on
the homepage: https://james.apache.org/ seems a bit outdated.
Should we change that?
I would think regarding main goals that:
- the distributed mail server is already stable and might not need to
keep
Hello,
On 21/09/2021 12:00, btell...@apache.org wrote:
> [...]
>
> * * Spring upcoming deprecation.*
>
> -> What we should really do beforehand is promote Guice artifacts.
> -> I think it would benefit from being a standalone item.
>
> Some work had been done on that topic:
>
> -> Have a ZIP
Hello all,
I have the impression that the roadmap we advertise on our website is
slightly out of date.
Refreshing and challenging the items part of it would be beneficial.
* * Antora migration*
-> I believe this should keep on being on our goal.
-> I think we should further split
eased.
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
> Project: James Server
> Issue Type: Wish
>
Document publicly and publish our roadmap
---
src/homepage/index.html | 38 ++
1 file changed, 38 insertions(+)
diff --git a/src/homepage/index.html b/src/homepage/index.html
index b10c01d..8c24357 100644
--- a/src/homepage/index.html
+++ b/src/homepage
Repository: james-project
Updated Branches:
refs/heads/master 6d72e4d20 -> 42c50f2c6
Remove James 3.0 roadmap progress
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/42c50f2c
Tree: http://git-
Hi everyone,
As part of our work on James 3.0, we introduced a graph showing our
advancement.
You can consult it here :
https://rawgit.com/linagora/james-project/master/james3-roadmap-progress/index.html
We will update this graph after each of our Kanban review (~ every 2 weeks).
Regards
Repository: james-project
Updated Branches:
refs/heads/master 43267e06c -> 8bba513c3
Update James 3.0 roadmap
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/8bba513c
Tree: http://git-wip-us.apache.
y be some OSGI support (haven't found any James related info on this)
P.S. It would be great to update jaxb ;)
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issue
lean-up and upgrade some of the old libs to
newer versions (spring, etc).
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
>
what that mailetcontainer.xml is all about.
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
> Project: JAMES Server
ttps://svn.apache.org/repos/asf/james/project/branches/server_docs_3-alpha_and_2.2.0/src/site/xdoc/todo.xml
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jir
e to vote for this feature.
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
> Project: JAMES Server
> Issue Type: Wish
&g
04
]
SuoNayi Wang commented on JAMES-1272:
-
Eric, what's time to release candidate of james 3.0?
I'm waiting for its release to use it in the product environment.
Roadmap for Apache James Server 3.1
---
didate of james 3.0?
I'm waiting for its release to use it in the product environment.
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
>
See http://wiki.apache.org/james/Server3ClientCompatibility
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
> URL: https://issues.apache.org/jira/browse/JAMES-1272
> Project: JAMES Server
t enhancements
[2] formal support for multiple ports
[3] Web mail modules (if it doesn't already exist), and
[4] additional support for customized mail handling
> Roadmap for Apache James Server 3.1
> ---
>
> Key: JAMES-1272
>
Roadmap for Apache James Server 3.1
---
Key: JAMES-1272
URL: https://issues.apache.org/jira/browse/JAMES-1272
Project: JAMES Server
Issue Type: Wish
Reporter: Eric Charles
This JIRA collects the
On Fri, Sep 25, 2009 at 4:55 AM, Noel J. Bergman wrote:
> I will help with the release.
cool
- robert
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apac
I will help with the release.
--- Noel
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
On Wed, Sep 23, 2009 at 8:58 AM, Norman Maurer wrote:
> Comments inline...
>
> 2009/9/22 Robert Burrell Donkin :
>> On Mon, Sep 21, 2009 at 6:54 PM, Norman Maurer wrote:
>>> So what about trying to write a list with all stuff which should get
>>> into the milestone ?
>>
>> IMAP works ok
>>
>> it'
Comments inline...
2009/9/22 Robert Burrell Donkin :
> On Mon, Sep 21, 2009 at 6:54 PM, Norman Maurer wrote:
>> So what about trying to write a list with all stuff which should get
>> into the milestone ?
>
> IMAP works ok
>
> it's just missing StartTLS to be a reasonable implementation of the
>
On Mon, Sep 21, 2009 at 6:54 PM, Norman Maurer wrote:
> So what about trying to write a list with all stuff which should get
> into the milestone ?
IMAP works ok
it's just missing StartTLS to be a reasonable implementation of the
latest specification
> Anyone ?
IMHO we need to cut releases for
Wed, Sep 16, 2009 at 12:57 PM, Norman Maurer wrote:
>>> Hi all,
>>>
>>> I think we should define a Roadmap for a new JAMES release and then
>>> cut a Milestone. We will never get more feedback if we do no release
>>> of trunk. So what do you think ?
>&
I don't care to much which build tool is used to cut the milestone..
Bye,
Norman
2009/9/16 Robert Burrell Donkin :
> On Wed, Sep 16, 2009 at 12:57 PM, Norman Maurer wrote:
>> Hi all,
>>
>> I think we should define a Roadmap for a new JAMES release and then
>> cu
On Wed, Sep 16, 2009 at 12:57 PM, Norman Maurer wrote:
> Hi all,
>
> I think we should define a Roadmap for a new JAMES release and then
> cut a Milestone. We will never get more feedback if we do no release
> of trunk. So what do you think ?
+1
it would need to be with ant sinc
Hi all,
I think we should define a Roadmap for a new JAMES release and then
cut a Milestone. We will never get more feedback if we do no release
of trunk. So what do you think ?
-
To unsubscribe, e-mail: server-dev-unsubscr
On Sat, Jun 6, 2009 at 6:22 AM, Eric MacAdie wrote:
> Robert Burrell Donkin wrote:
>>
>> it's arrived and been registered (Eric Keith MacAdie has now been
>> added to the CLAs section of
>> http://people.apache.org/~jim/committers.html)
>>
>> now we just need to know your confluence user name. if y
Robert Burrell Donkin wrote:
it's arrived and been registered (Eric Keith MacAdie has now been
added to the CLAs section of
http://people.apache.org/~jim/committers.html)
now we just need to know your confluence user name. if you haven't
signed up yet, it's linked from (for example)
http://cwik
On Tue, Jun 2, 2009 at 5:00 AM, Eric MacAdie wrote:
> Robert Burrell Donkin wrote:
>>
>> On Mon, Jun 1, 2009 at 8:36 AM, Eric MacAdie wrote:
>>
>>>
>>> What is the ETA to hear back from the Apache Foundation about my CLA? Or
>>> can
>>> I just start contributing without hearing back from them?
>>
Robert Burrell Donkin wrote:
On Mon, Jun 1, 2009 at 8:36 AM, Eric MacAdie wrote:
What is the ETA to hear back from the Apache Foundation about my CLA? Or can
I just start contributing without hearing back from them?
we just wait until it's been officially recorded. i checked, and i
ca
On Mon, Jun 1, 2009 at 8:36 AM, Eric MacAdie wrote:
> Robert Burrell Donkin wrote:
>>
>> On Thu, May 21, 2009 at 10:14 PM, Eric MacAdie wrote:
>>
>>>
>>> I printed out the Apache CLA, and will mail it off later today or
>>> tomorrow.
>>> So I should be able to contribute some docs real soon now.
Robert Burrell Donkin wrote:
On Thu, May 21, 2009 at 10:14 PM, Eric MacAdie wrote:
I printed out the Apache CLA, and will mail it off later today or tomorrow.
So I should be able to contribute some docs real soon now.
Not to sound conceited, but I have gotten a lot of good feedback on my Ja
On Thu, May 21, 2009 at 10:14 PM, Eric MacAdie wrote:
> Robert Burrell Donkin wrote:
>>
>> unless you change your mind or figure out some other way forward, then
>> james server will die
>>
>> i was hopeful that a 3.x would be possible but we're too short of
>> testers and documentors
>>
>> a grad
On Wed, May 20, 2009 at 4:31 PM, David Jencks wrote:
>
> On May 20, 2009, at 7:44 AM, Robert Burrell Donkin wrote:
>
>> On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
On Wed, May 20, 2009 at 11:52 AM, Stefano Bagnara
wrote:
>
Robert Burrell Donkin wrote:
unless you change your mind or figure out some other way forward, then
james server will die
i was hopeful that a 3.x would be possible but we're too short of
testers and documentors
a gradualist approach would mean that 2.x users could contribute to
testing and doc
On Wed, May 20, 2009 at 5:19 PM, Stefano Bagnara wrote:
> Robert Burrell Donkin ha scritto:
>>>>> The only real features for end users in that roadmap is jSPF and this
>>>>> could be released as a mailet anyway. jSPF as it is in trunk cannot be
>>>>
rver installation and tell
>> everyone to put their file based data somewhere inside that, rather than
>> trying to store it inside the application itself somehow (as people seem
>> to like to do with web apps) There may be a built in or easy solution
>> to this but I don'
ver installation and tell
> everyone to put their file based data somewhere inside that, rather than
> trying to store it inside the application itself somehow (as people seem
> to like to do with web apps) There may be a built in or easy solution
> to this but I don't know wh
JAMES-693, JAMES-816). The remaining
JIRAs are Won't fix or documentation or other trivial fixes.
>>>>> * The recent threads from users are telling us that we really need to
>>>>> have a 2.x roadmap for mail server users (as opposed to mail
>>>>> ap
e we now
come up very short.
I agree. I would probably test and review an RC from trunk but not
any
build from v2.3.
so: you wouldn't be willing to review a 2.3.2 RC?
* The recent threads from users are telling us that we really
need to
have a 2.x roadmap for mail server users (as oppo
elease we won't see a release.
>>
>> building a release candidate is a complete waste of time unless there
>> are people who are willing and able to test it. this is where we now
>> come up very short.
>
> I agree. I would probably test and review an RC from trunk but
unless there
> are people who are willing and able to test it. this is where we now
> come up very short.
I agree. I would probably test and review an RC from trunk but not any
build from v2.3.
>>> * The recent threads from users are telling us that we really need to
>>> have
e to test it. this is where we now
come up very short.
>> * The recent threads from users are telling us that we really need to
>> have a 2.x roadmap for mail server users (as opposed to mail
>> application developers)
>
> they don't care about 2.x or 3.x. IMO they s
so hard. This require the same effort as any release of
james-server: until no one will need a release and will take the time to
build some test release we won't see a release.
> * The recent threads from users are telling us that we really need to
> have a 2.x roadmap for mail server u
ing harder and harder...
* The recent threads from users are telling us that we really need to
have a 2.x roadmap for mail server users (as opposed to mail
application developers)
Proposal:
* Use 2.x for mature, stable releases aimed at mail server users
retaining pheonix as the container
* Tar
Norman Maurer ha scritto:
> I think 1.1 for java 1.5 is ok.
+1
Stefano
> Bye,
> Norman
>
> 2009/5/14 Robert Burrell Donkin :
>> 1.0 has been cut :-)
>>
>> this shipped with an old version of bouncycastle targetted at (the now
>> obsolete) Java 1.4
>>
>> i suppose we should really upgrade to Jav
I think 1.1 for java 1.5 is ok.
Bye,
Norman
2009/5/14 Robert Burrell Donkin :
> 1.0 has been cut :-)
>
> this shipped with an old version of bouncycastle targetted at (the now
> obsolete) Java 1.4
>
> i suppose we should really upgrade to Java 1.5 for the next version
> (1.1 or 2.0?)
>
> opinions
1.0 has been cut :-)
this shipped with an old version of bouncycastle targetted at (the now
obsolete) Java 1.4
i suppose we should really upgrade to Java 1.5 for the next version
(1.1 or 2.0?)
opinions?
- robert
-
To unsubscri
On Mon, Jul 7, 2008 at 5:06 AM, James D Carroll <[EMAIL PROTECTED]> wrote:
> I've been following this list with some interest, especially the notions
> of Geronimo, Spring, Java 1.5 etc and the future of James. Is there a
> roadmap for the future forming?
If you replace &
On Mon, Jul 7, 2008 at 4:06 AM, James D Carroll <[EMAIL PROTECTED]> wrote:
> I've been following this list with some interest, especially the notions
> of Geronimo, Spring, Java 1.5 etc and the future of James. Is there a
> roadmap for the future forming?
roadmaps have
I've been following this list with some interest, especially the notions
of Geronimo, Spring, Java 1.5 etc and the future of James. Is there a
roadmap for the future forming?
Thanks,
James
-
To unsubscribe, e-mail: [
On Sat, May 10, 2008 at 10:38 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> i plan to post a mailet roadmap to the mailet-api list. so i've
>> drafted a strawman on the wiki
>> http://wiki.apache.org/james/MailetR
Robert Burrell Donkin ha scritto:
i plan to post a mailet roadmap to the mailet-api list. so i've
drafted a strawman on the wiki
http://wiki.apache.org/james/MailetRoadMap. take a look and either
post comments to the list or just dive in and edit.
- robert
+1
You know my only concern is
i plan to post a mailet roadmap to the mailet-api list. so i've
drafted a strawman on the wiki
http://wiki.apache.org/james/MailetRoadMap. take a look and either
post comments to the list or just dive in and edit.
- robert
---
On 8/2/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Danny Angus ha scritto:
> I don't remember anyone suggesting the modularisation as a solution to
> our problems (at least since I joined JAMES, that is before the problems
> started anyway ;-) ).
I don't think anyone did, but there was an un
Danny Angus ha scritto:
> On 8/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> You seems so secure about what happened and what was the problem.
>> There has never been stealth in my behaviour. NEVER: I'd like to know
>> how did you created such opinion (hope not talking with Noel or Danny,
>>
On 8/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > you wanted a revolution but ended up evolving the existing code base.
> > architecture by stealth typically creates community issues and so is
> > best avoided.
...
> You seems so secure about what happened and what was the problem.
> The
On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> ok. What I mean is that one question could be: is a new mailet api still
> in a roadmap for 3.0 ? It was one of the main point in past (not in my
> roadmap). Danny: if you are tuned what's your idea about this?
The e
Robert Burrell Donkin ha scritto:
> On 8/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Btw I think we already have much simpler tasks to be solved first, like
>> removing the User from the imap-api module so to not have core-library
>> to depend on imap-api, then we can see how other refactor
On 8/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Btw I think we already have much simpler tasks to be solved first, like
> removing the User from the imap-api module so to not have core-library
> to depend on imap-api, then we can see how other refactorings will
> impact on this multi mod
Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>>> On 8/1/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
this is a classic case of evolution verses revolution
you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically cre
Stefano Bagnara wrote:
On 8/1/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
this is a classic case of evolution verses revolution
you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically creates community issues and so is
best avoided.
Ber
> On 8/1/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
>> this is a classic case of evolution verses revolution
>>
>> you wanted a revolution but ended up evolving the existing code base.
>> architecture by stealth typically creates community issues and so is
>> best avoided.
Bernd Fonderma
Robert Burrell Donkin ha scritto:
>> The same happened from 2.2 to 2.3 when I had to brake config.xml
>> compatibility so to have a better architecture in 2.3. Currently the
>> "goal" was even more ambitious than the 2.3 as we wanted to introduce
>> much more new things but without braking config.x
ities.
> > >> - One of them is mailet api changes: when you change the mailet api you
> > >> probably need to change a lot of code in james.
> > >
> > > IMHO this is now a matter for the mailet subproject. once a new API
> > > has been agreed and released
the mailet subproject. once a new API
> > has been agreed and released, then we can work out what to do about
> > the server.
>
> ok. What I mean is that one question could be: is a new mailet api still
> in a roadmap for 3.0 ? It was one of the main point in past (not in my
&g
e of them is mailet api changes: when you change the mailet api you
>> probably need to change a lot of code in james.
>
> IMHO this is now a matter for the mailet subproject. once a new API
> has been agreed and released, then we can work out what to do about
> the server.
ok. What
why this would necessarily break
storage/configuration compatibility
> - probably there are many more I don't remember now.
>
> Btw, as you pointed out, maybe I'm too much worried about this as it
> seems as no one have this issues in the roadmap anymore.
that's be
robert burrell donkin wrote:
JAMES is a complex, mature application but now contains many youthful
components. perhaps these new components would benefit from a quicker
release cycle than the main application.
perhaps it might be worth considering decoupling the spring support
from the normal ja
Bernd Fondermann wrote:
For the next release I would like to
+ have basic (whatever than means) IMAP stable, perfoming and
functional, and well integrated with the rest of James architecture.
+ have more online management and monitoring features done
+ have a Spring distribution besides the other
On 12/16/06, Norman <[EMAIL PROTECTED]> wrote:
>> + have a Spring distribution besides the other packages
>>
>
> Let's do it! :-)
>
>
If im not wrong then there is allready a sandbox on which joachim is workin.
JAMES is a complex, mature application but now contains many youthful
components
Hi guys,
Joachim Draeger schrieb:
> Hi Bernd,
>
> Am Samstag, den 16.12.2006, 08:50 +0100 schrieb Bernd Fondermann:
>
>
>>> its now about 4 weeks ago when Stefano and me posted a roadmap proposal
>>> to the mailling list. Nothing concrete happen since this pos
Hi Bernd,
Am Samstag, den 16.12.2006, 08:50 +0100 schrieb Bernd Fondermann:
> > its now about 4 weeks ago when Stefano and me posted a roadmap proposal
> > to the mailling list. Nothing concrete happen since this posting. I
> > really whould like to get this odd roadmap stuff
Hi,
On 12/14/06, Norman <[EMAIL PROTECTED]> wrote:
Hi commiters,
its now about 4 weeks ago when Stefano and me posted a roadmap proposal
to the mailling list. Nothing concrete happen since this posting. I
really whould like to get this odd roadmap stuff done now to focus on
working on th
Hi commiters,
its now about 4 weeks ago when Stefano and me posted a roadmap proposal
to the mailling list. Nothing concrete happen since this posting. I
really whould like to get this odd roadmap stuff done now to focus on
working on the next release. Without the roadmap it is impossible for
Hi Joachim,
nice Roadmap so far.. i have notime to write a large answer now ( Will
do this tomorrow). But i think you did a really good job with that and
all sounds logic to me..
bye
Norman
Am Samstag, den 01.07.2006, 18:20 +0200 schrieb Joachim Draeger:
> Hi!
>
>
> Joachim
>
Hi!
The weather is just to hot here to work on the computer! Of course I
wanted to write a few words for introduction :-) This is the first
draft of a roadmap for imap. I'm looking forward to your input!
You find the html version here: http://www.joachim-draeger.de/JamesImap/
And the s
development. Design limitations we introduce today could be hard to
overcome tomorrow.
Having a structured, ordered and valued roadmap of what ever is
desireable/imaginable helps on making decisions.
Being pragmatic may mean discarding some goals, but we should at
least
be aware of
Norman Maurer wrote:
Hi,
what you guys think about a new roadmap for features which should add
and which are more importend that other ?
IMAP support is one of the important thing in our roadmap and that I
won't assign to me anytime soon.
Most of the new feature we have in roadmap ne
Hi,
what you guys think about a new roadmap for features which should add
and which are more importend that other ?
bye
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
> > General to all code developed and/or exported from the USA that
> > contains any crypto code. Adding S/MIME support to JAMES
> created the problem.
>
> Well the problem is not the S/MIME code itself, as it merely
> leverages on the BouncyCastle api for the crypto-routines.
> The fact that
On Sunday 07 August 2005 19:32, Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> > BXA issues? Are they specific to James or a new issue
> > regarding all ASF projects?
>
> General to all code developed and/or exported from the USA that contains
> any crypto code. Adding S/MIME support to JAMES
Steve Brewin wrote:
Noel J. Bergman wrote:
At this point, my preference would be to look at OSGi for the
container.
That should provide a range of benefits, including ease to
integrate with
other components such as Derby for database and ApacheDS for directory
services.""
Noel, why O
> > BXA issues? Are they specific to James or a new issue regarding all
> > ASF projects?
>
> General to all code developed and/or exported from the USA
> that contains any crypto code. Adding S/MIME support to
> JAMES created the problem.
SMIME support currently in svn has been committed by
Noel J. Bergman wrote:
> At this point, my preference would be to look at OSGi for the
> container.
> That should provide a range of benefits, including ease to
> integrate with
> other components such as Derby for database and ApacheDS for directory
> services.""
Noel, why OSGi?
What "range of
Stefano Bagnara wrote:
> BXA issues? Are they specific to James or a new issue
> regarding all ASF projects?
General to all code developed and/or exported from the USA that contains any
crypto code. Adding S/MIME support to JAMES created the problem.
> > I'd rather see us get what we've got rea
> I don't particularly care what we call it, so long as we can
> get it shipped soon/now.
> [...]
> The current "problem" is that we need to address BXA issues,
> else I would have already posted candidates. I'm hoping that
> we can get this resolved soon.
BXA issues? Are they specific to Jame
get this resolved
soon.
> If you agree I merge 2.2.1 to 3.0 in JIRA so we'll have a better
> overview on what's fixed and what's not fixed and the current
> roadmap.
Some things might then get moved further out, but ... <>
> IMHO phoenix dependency removal and r
If I understood correctly the next release will be 3.0.
If you agree I merge 2.2.1 to 3.0 in JIRA so we'll have a better overview on
what's fixed and what's not fixed and the current roadmap.
I also think that we should discuss what we want to include in 3.0 so I can
organize th
Mark Livingstone wrote:
Noel J. Bergman wrote:
I hope to play with IBM's Cloudscape for another project
The idea of Cloudscape is interesting, but it might be best to look at
axion
Maybe we can now revisit this idea ;-)
http://www.eweek.com/article2/0,1759,1630856,00.asp
MarkL
Yes, this is one o
Noel J. Bergman wrote:
I hope to play with IBM's Cloudscape for another project
The idea of Cloudscape is interesting, but it might be best to look at axion
Maybe we can now revisit this idea ;-)
http://www.eweek.com/article2/0,1759,1630856,00.asp
MarkL
-
Noel J. Bergman wrote:
> > While I agree that we should be container neutral, it would
> be good to
> > accomodate the extended, but optional, Avalon lifecycles
> into a reworked
> > Mailet API so that it can be leveraged when available.
>
> I would be -1 regarding any contamination of the Mailet A
1 - 100 of 135 matches
Mail list logo
