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 "Amichai Rothman (JIRA)" <se...@james.apache.org> on 2009/05/08 00:10:45 UTC
[jira] Created: (JAMES-902) Upgrade to JavaMail 1.4.2
Upgrade to JavaMail 1.4.2
-------------------------
Key: JAMES-902
URL: https://issues.apache.org/jira/browse/JAMES-902
Project: JAMES Server
Issue Type: Improvement
Affects Versions: 2.3.1
Reporter: Amichai Rothman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707668#action_12707668 ]
Amichai Rothman commented on JAMES-902:
---------------------------------------
c'mon, it'll take me longer to even just do an svn checkout ;-)
I actually can't even find the repo link on the site - or am I missing it?
anyway, the API hasn't changed, so it's just a matter of replacing the jar and the link from the build script...
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707698#action_12707698 ]
Robert Burrell Donkin commented on JAMES-902:
---------------------------------------------
You're missing it
Details are in the usual place for a maven site (click on link to 2.3.1 documentation then take a look under project information)
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707760#action_12707760 ]
Robert Burrell Donkin commented on JAMES-902:
---------------------------------------------
Submit a patch ;-)
Seriously - 2.3.1 is short of love and attention
I (and most of the active developers) use the 3.x code base. I know a lot of users want to see more 2.3.1 releases and features but that's not going to happen unless contributors interested in that code base step up.
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, May 12, 2009 at 5:51 PM, Eric MacAdie <er...@macadie.net> wrote:
> Robert Burrell Donkin wrote:
>>
>> On Sun, May 10, 2009 at 8:13 PM, Eric MacAdie <er...@macadie.net> wrote:
>>
>>>
>>> WRT documentation, I have posted a few pages about James on my site. Have
>>> a
>>> look at them and let me know if you think they might be helpful.
>>>
>>>
>>> http://www.MacAdie.net/opencms/opencms/sites/MacAdie.dot.Net/Java/James/index.html
>>>
>>
>> yep :-)
>>
>> and you're (all) right that documentation is scattered around
>>
>> the current wiki has a low barrier to entry (which is good for
>> informal documention) but the content can't be used as official
>> documentation (apache lacks the required license). this limits the
>> usefulness as far as developing consistent user documentation goes.
>>
>> added content to the website means checking out the source and using
>> maven to build it. i try to encourage contributors to do this since
>> it's the first step towards becoming a committer. but as some folks on
>> this thread have noted, it is a little fiddly and has a relatively
>> high barrier to entry.
>>
>> then again, any contributors are going to need to jump through some
>> hoops to ensure that Apache has the required license to use their
>> contributions
>>
>> one option would be to set up a confluence instance (like
>> http://cwiki.apache.org/labs/clouds.html) for an official content -
>> user guide, perhaps. contributors would need to have a CLA on file
>> (this agreement grants apache the license required to distribute with
>> a release). the contents would be exported and included with future
>> releases.
>>
>> would anyone be interested in writing documentation on confluence?
>>
>> - robert
>>
>
> Sure, I would be interested in writing documentation on confluence.
great :-)
if you haven't got a CLA on file for apache then the first step is to
do that (see http://www.apache.org/licenses/#clas)
(i'll take a look at getting the confluence instance sorted out
> I think a good place to start would be a step-by-step guide on getting
> involved with James. The URL for the "Get Involved" link on the James site
> is http://jakarta.apache.org/site/getinvolved.html, which redirects to
> http://www.apache.org/foundation/getinvolved.html. And maybe this is
> redundant, but a few pages/cheat sheets within James about svn and maven
> with a few basic commands to get started would be good. I have little
> experience with svn or maven, so reading that I have to go out and learn
> several other things just to do the one thing I want is a bit off-putting.
> But that is just me.
a cheat sheet sounds like a good idea
and yes, the project level documentation could probably do with
revising (this thread is getting a little long and we're drifting OT
so i'll branch a new one)
> Also: Is maven the preferred way to build James?
the answer's a bit complex :-/
the canonical release build for the server is ant. maven is supported
for 3.0 but for 2.3, maven just builds the web site.
the james libraries are a mixed bag
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Eric MacAdie <er...@MacAdie.net>.
Robert Burrell Donkin wrote:
> On Sun, May 10, 2009 at 8:13 PM, Eric MacAdie <er...@macadie.net> wrote:
>
>> WRT documentation, I have posted a few pages about James on my site. Have a
>> look at them and let me know if you think they might be helpful.
>>
>> http://www.MacAdie.net/opencms/opencms/sites/MacAdie.dot.Net/Java/James/index.html
>>
>
> yep :-)
>
> and you're (all) right that documentation is scattered around
>
> the current wiki has a low barrier to entry (which is good for
> informal documention) but the content can't be used as official
> documentation (apache lacks the required license). this limits the
> usefulness as far as developing consistent user documentation goes.
>
> added content to the website means checking out the source and using
> maven to build it. i try to encourage contributors to do this since
> it's the first step towards becoming a committer. but as some folks on
> this thread have noted, it is a little fiddly and has a relatively
> high barrier to entry.
>
> then again, any contributors are going to need to jump through some
> hoops to ensure that Apache has the required license to use their
> contributions
>
> one option would be to set up a confluence instance (like
> http://cwiki.apache.org/labs/clouds.html) for an official content -
> user guide, perhaps. contributors would need to have a CLA on file
> (this agreement grants apache the license required to distribute with
> a release). the contents would be exported and included with future
> releases.
>
> would anyone be interested in writing documentation on confluence?
>
> - robert
>
Sure, I would be interested in writing documentation on confluence.
I think a good place to start would be a step-by-step guide on getting
involved with James. The URL for the "Get Involved" link on the James
site is http://jakarta.apache.org/site/getinvolved.html, which redirects
to http://www.apache.org/foundation/getinvolved.html. And maybe this is
redundant, but a few pages/cheat sheets within James about svn and maven
with a few basic commands to get started would be good. I have little
experience with svn or maven, so reading that I have to go out and learn
several other things just to do the one thing I want is a bit
off-putting. But that is just me.
Also: Is maven the preferred way to build James?
Eric MacAdie
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, May 10, 2009 at 8:13 PM, Eric MacAdie <er...@macadie.net> wrote:
> Robert Burrell Donkin wrote:
>>
>> contributions take many forms. for example, as pointed out about the
>> documentation is old.
>>
>
> WRT documentation, I have posted a few pages about James on my site. Have a
> look at them and let me know if you think they might be helpful.
>
> http://www.MacAdie.net/opencms/opencms/sites/MacAdie.dot.Net/Java/James/index.html
yep :-)
and you're (all) right that documentation is scattered around
the current wiki has a low barrier to entry (which is good for
informal documention) but the content can't be used as official
documentation (apache lacks the required license). this limits the
usefulness as far as developing consistent user documentation goes.
added content to the website means checking out the source and using
maven to build it. i try to encourage contributors to do this since
it's the first step towards becoming a committer. but as some folks on
this thread have noted, it is a little fiddly and has a relatively
high barrier to entry.
then again, any contributors are going to need to jump through some
hoops to ensure that Apache has the required license to use their
contributions
one option would be to set up a confluence instance (like
http://cwiki.apache.org/labs/clouds.html) for an official content -
user guide, perhaps. contributors would need to have a CLA on file
(this agreement grants apache the license required to distribute with
a release). the contents would be exported and included with future
releases.
would anyone be interested in writing documentation on confluence?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Eric MacAdie <er...@MacAdie.net>.
Robert Burrell Donkin wrote:
> contributions take many forms. for example, as pointed out about the
> documentation is old.
>
WRT documentation, I have posted a few pages about James on my site.
Have a look at them and let me know if you think they might be helpful.
http://www.MacAdie.net/opencms/opencms/sites/MacAdie.dot.Net/Java/James/index.html
Eric MacAdie
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, May 10, 2009 at 2:55 PM, Demetrios Kyriakis
<de...@gmail.com> wrote:
>> haven't seen any movement there in months, years... why
>>
>> not work on that other well-supported project instead?' Or to paraphrase
>> the well known quote - "contributors contribute to those projects who help
>> themselves"...
>>
>> ...is it just me?
>
> No, it's not just you.
> To me this project looks quite abandoned, and to express it more plastically
> , it's "movements" are of a "chicken without a head" , and it doesn't have
> much until it's over either.
apache projects don't use a dictatorial model
until the community decides on a direction, development just happens
which begs the question: what do people want from james?
> One could say that this shouldn't be such a big problem, since it's open
> source, (there's source code and stuff), right?
> Well for me it is, and mainly because it's too complicated for me to be able
> to be useful somehow, or "fix it myself".
contributions take many forms. for example, as pointed out about the
documentation is old.
if you're happier with a pay for model, then RedHat have a
professionally developed email server which is of comparable
sophistication to james
> This is why I switched most of my email server installations to JES:
> http://sourceforge.net/projects/javaemailserver
>
> An extremely simple (one could say quite primitive cause it doesn't do too
> much) mail server that seem to just work.
> It has even a few things 2.3.1 does not have (or are not simple to setup):
> - setup in a few minutes even by a non-developer
> - very small - only a few KB (also consumes few resources)
> - multi-domain support out of the box (just enumerate them)
> - settings changes on the fly (without restarting the server)
>
> The biggest advantage for me however is that it is *very* small and
> "non-abstract" so I can quickly understand it and "fix it myself".
> The loading tests I've made also shown me that it can handle without
> problems what most small and medium companies need.
best of luck :-)
one of the hardest decisions to take is whether to start writing from
scratch a replacement for a mature product. it's hard to know whether
enough new developers can be attracted to gain the momentum you need
to overtake more mature projects. then there's the problem that as
more functions are added, any problems with the original designs are
revealed.
fully featured email servers are non-trivial. it takes time to prove
them in production. 2.3.x has been proved and is mature (which is why
it's not longer actively developed).
but there's a tradeoff. lots of features means lots more code and a
much bigger footprint. so james is big and complex. servers with
comparable features tend also to be big and complex.
my personal preferance is for an OSGi based mail server with
development switching mostly to libraries. this would allow users to
mix and match.
if people are interested in pushing james for the SME market then the
OfBiz project are the people to talk to. a stripped down version of
james 3.0 with easy configuration may well be of interest to them.
they have developers and a lot of knowledge of that sector. so, if
someone wanted to jump in and arrange collaborations, i think it might
work out well.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Demetrios Kyriakis <de...@gmail.com>.
> haven't seen any movement there in months, years... why
> not work on that other well-supported project instead?' Or to paraphrase
> the well known quote - "contributors contribute to those projects who
> help themselves"...
>
> ...is it just me?
No, it's not just you.
To me this project looks quite abandoned, and to express it more
plastically , it's "movements" are of a "chicken without a head" , and
it doesn't have much until it's over either.
One could say that this shouldn't be such a big problem, since it's open
source, (there's source code and stuff), right?
Well for me it is, and mainly because it's too complicated for me to be
able to be useful somehow, or "fix it myself".
This is why I switched most of my email server installations to JES:
http://sourceforge.net/projects/javaemailserver
An extremely simple (one could say quite primitive cause it doesn't do
too much) mail server that seem to just work.
It has even a few things 2.3.1 does not have (or are not simple to setup):
- setup in a few minutes even by a non-developer
- very small - only a few KB (also consumes few resources)
- multi-domain support out of the box (just enumerate them)
- settings changes on the fly (without restarting the server)
The biggest advantage for me however is that it is *very* small and
"non-abstract" so I can quickly understand it and "fix it myself".
The loading tests I've made also shown me that it can handle without
problems what most small and medium companies need.
Of course, I'm still hoping that JAMES would take off, but with each day
it looks less and less probable :(.
Demetrios.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, May 10, 2009 at 1:58 PM, A. Rothman <am...@amichais.net> wrote:
> Hi all,
>
> Here's a thought/feeling I've been having for a while regarding JAMES, as a
> user of many years (both at work and at home). It's not at all meant as a
> rant, but as the personal experience of a long time user who really wants to
> see this project thrive - this is how it looks from the 'outside'. [reposted
> from elsewhere - oops :-) ]
it's good to talk :-)
> Speaking for myself, I can't exactly say that I'm interested in more
> releases and features from a 2.x codebase with no active developers,
> targeted at Java 1.4 (won't even compile on 6), with chunks of the project's
> wiki (even task-related pages) last updated 4 years ago, based on some
> framework projects that have been discontinued years ago... at least that's
> the impression the project is making in the past couple of years - that it
> is a dying one.
(here's the way i see things - others may disagree)
the 2.3.x code base is mature. it's production tested and secure. a
point release is overdue since there are a few bugs fixed since the
last one.
most active developers now use 3.0 code. so, we need more active users
of 2.3.x to contribute by testing backports and improving the
documentation if they want to see further releases.
it's not really possible to develop this code base any further.
problems with avalon, backwards compatibility, revised design
requirements and JDK changes meant that active, evolutionary
development stopped several years ago on 2.x.
sometimes (when this happens) a way forward can be agreed. at other
times, the existing developers fall out and the project explodes. i
started developing james 3.x when the developers were exploding. the
fall out from those disagreements meant that most of the server
developers are now much less active. so, the server's short of
developers (but the libraries are still reasonably active).
sometimes, time is the only healer. i think enough time has passed and
that progress would now be possible if new contributors want to get
involved.
> But, I wouldn't want to abandon it either. As a user, the alternatives are
> either the above, or a trunk 3.0 version whose status, progress and future
> is not quite clear either - there's a v3 wiki page that was last updated at
> the beginning of 2005! Perhaps it's time for a proper alternative? Perhaps
> an alpha/beta of 3, with a fresh feeling of liveliness? Something to show a
> clear sign of activity and progress? cleaning up the wiki from ancient
> roadmaps and plans which have been abandoned long ago? I think that feeling
> of freshness would make it much easier to contribute than the current
> uninviting feeling of gloom... I contribute to several projects in what
> spare time I've got, and this one always gets pushed to the bottom of the
> list because of that feeling of 'who knows if it's not already dead? Are
> there more than a dozen users still using it? haven't seen any movement
> there in months, years... why not work on that other well-supported project
> instead?' Or to paraphrase the well known quote - "contributors contribute
> to those projects who help themselves"...
i've done the whole popular project thing before and i decided on
james that i'm focussing just on the code. i'm willing to help anyone
interested in documentation but it's not something i'm willing to take
on.
but maybe james would come higher on your personal development agenda
if you saw it as a far of doing cool stuff rather than a chore
i'm interested in advanced, next generation mail architectures. in
particular, in pulling in multiple information sources (news, email,
atom, jabber, etc), to process them (especially using machine learning
for intelligent filtering), persist in document-centric storage then
pushing them out through multiple protocols (IMAP, POP3, twitter).
there's a lot still to do, and if anyone's interested in this stuff
it'd be great to work together,
this agenda is controversial and i don't think we'd be able to agree a
road map along those lines. but a lot of the work needed is well
aligned with other visions for 3.0. so, i use james 3.0 which
motivates me to improve and fix it.
IMO IMAP's a big enabler. creating a reasonable IMAP implementation
has been a PITA but i think it'll prove worthwhile. if people are
interested in exchange alternatives, it would be possible to push on
from this base. approaching new protocols as independent, pluggable
libraries is my preferred approach so there's less to learn. if
anyone's interested in improving exchange compatibility then i'd be
willing to help get you started.
the elephant in the room is avalon. the death of avalon has really
wounded james. avalon it a PITA and makes the code difficult to work
with. it need to be replaced but the topic of replacement has proved
controversial in the past. i suspect that this isn't so heated these
days.
the good news is that - by chance - this wait has had some advantages.
in the meantime, OSGi has emerged and matured. it also plays much
better with spring these days. the karaf microkernel which was
recently donated to felix looks really cool.
IMHO moving to karaf would be really great for james. the server could
be split into a number of loosely coupled libraries which could be
dynamically loaded and re-configured. if advanced OSGi sounds
interesting to anyone then jump in.
another personal interest of mine is improving JPA and JCR support. if
this sounds interesting to anyone, then please jump in.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Project status and perception
Posted by "A. Rothman" <am...@amichais.net>.
Hi all,
Here's a thought/feeling I've been having for a while regarding JAMES,
as a user of many years (both at work and at home). It's not at all
meant as a rant, but as the personal experience of a long time user who
really wants to see this project thrive - this is how it looks from the
'outside'. [reposted from elsewhere - oops :-) ]
Speaking for myself, I can't exactly say that I'm interested in more
releases and features from a 2.x codebase with no active developers,
targeted at Java 1.4 (won't even compile on 6), with chunks of the
project's wiki (even task-related pages) last updated 4 years ago, based
on some framework projects that have been discontinued years ago... at
least that's the impression the project is making in the past couple of
years - that it is a dying one.
But, I wouldn't want to abandon it either. As a user, the alternatives
are either the above, or a trunk 3.0 version whose status, progress and
future is not quite clear either - there's a v3 wiki page that was last
updated at the beginning of 2005! Perhaps it's time for a proper
alternative? Perhaps an alpha/beta of 3, with a fresh feeling of
liveliness? Something to show a clear sign of activity and progress?
cleaning up the wiki from ancient roadmaps and plans which have been
abandoned long ago? I think that feeling of freshness would make it much
easier to contribute than the current uninviting feeling of gloom... I
contribute to several projects in what spare time I've got, and this one
always gets pushed to the bottom of the list because of that feeling of
'who knows if it's not already dead? Are there more than a dozen users
still using it? haven't seen any movement there in months, years... why
not work on that other well-supported project instead?' Or to paraphrase
the well known quote - "contributors contribute to those projects who
help themselves"...
...is it just me?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Robert Burrell Donkin wrote:
> On Tue, May 12, 2009 at 3:28 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>
> <snip>
>
>> "Contribution" covers everything from installing, running and reporting
>> test results to bug reports, documentation patches, code patches.
>>
>> Today I contributed a patch to another Apache project I never
>> contributed to before. The patch was utterly trivial: One word changed
>> in a toString() method. It was created in less than 5 minutes. The patch
>> was applied within less than 10 minutes!
>>
>> What I want to say by this is: It doesn't take much to make a difference
>> on an open source project. The borders between user, contributor and
>> committer are floating.
>
> +1
>
>> I can understand why people are frustrated. I am, too.
>> It's because something has changed within the last couple of month:
>> Three committers who were heavily using James on a daily basis moved on.
>> They were first hand testers of TRUNK.
>>
>> Instead, at the moment, TRUNK is largely untested. So nobody knows
>> exactly how good it really is (or they don't report here).
>>
>> So if the community asks for a milestone release, we all must be aware
>> of the fact that we then need to do actual testing on the released
>> software. Otherwise, releasing a milestone serves no real purpose. So
>> others need to jump in and test.
>
> +1
>
> one of the conflicts is that james is both a final user application
> and an extensible platform for developing mail applications
>
> for users who are interested just in a plain mail application then
> avalon-phoenix shouldn't be a problem. it works well and has been well
> tested in production. 2.3.x really is the right choice.
>
> the avalon-phoenix framework has major issues as a development
> platform. most developers prefer spring. the 3.x version is the right
> choice for developers looking to extend james.
>
> most of the developers who remain active are interested in developing
> mail applications rather than creating and maintaining a basic user
> email application.
>
> IMHO both codebases are just too big for new developers. i would
> prefer lots of smaller, more accessible libraries from which the two
> versions are build.
>
> if people aren't willing to contribute to testing 3.0 then one option
> would be to think about 2.x as the stable, user application and 3.x as
> the extensible developer version. it should be possible to extend
> 2.x's lifespan by factoring out libraries from 3.x to replace code in
> 2.x. avalon-pheonix support could then be dropped from 3.0.
+1 (insightful)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, May 12, 2009 at 3:28 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
<snip>
> "Contribution" covers everything from installing, running and reporting
> test results to bug reports, documentation patches, code patches.
>
> Today I contributed a patch to another Apache project I never
> contributed to before. The patch was utterly trivial: One word changed
> in a toString() method. It was created in less than 5 minutes. The patch
> was applied within less than 10 minutes!
>
> What I want to say by this is: It doesn't take much to make a difference
> on an open source project. The borders between user, contributor and
> committer are floating.
+1
> I can understand why people are frustrated. I am, too.
> It's because something has changed within the last couple of month:
> Three committers who were heavily using James on a daily basis moved on.
> They were first hand testers of TRUNK.
>
> Instead, at the moment, TRUNK is largely untested. So nobody knows
> exactly how good it really is (or they don't report here).
>
> So if the community asks for a milestone release, we all must be aware
> of the fact that we then need to do actual testing on the released
> software. Otherwise, releasing a milestone serves no real purpose. So
> others need to jump in and test.
+1
one of the conflicts is that james is both a final user application
and an extensible platform for developing mail applications
for users who are interested just in a plain mail application then
avalon-phoenix shouldn't be a problem. it works well and has been well
tested in production. 2.3.x really is the right choice.
the avalon-phoenix framework has major issues as a development
platform. most developers prefer spring. the 3.x version is the right
choice for developers looking to extend james.
most of the developers who remain active are interested in developing
mail applications rather than creating and maintaining a basic user
email application.
IMHO both codebases are just too big for new developers. i would
prefer lots of smaller, more accessible libraries from which the two
versions are build.
if people aren't willing to contribute to testing 3.0 then one option
would be to think about 2.x as the stable, user application and 3.x as
the extensible developer version. it should be possible to extend
2.x's lifespan by factoring out libraries from 3.x to replace code in
2.x. avalon-pheonix support could then be dropped from 3.0.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Bernd Fondermann <bf...@brainlounge.de>.
A. Rothman wrote:
>
> I think JAMES is currently in a deadlock of sorts regarding
> contributors. My base assumptions are -
>
>
> 1. The only usable version of JAMES at the moment is 2.x. Other than
> core developers, very few users will checkout trunk on some random day
> and use that as a production system. 3.x is off-limits for normal users,
> at least until there's some milestone release they can depend on.
>
>
> 2. No one is going to contribute to 2.x. As everyone here seems to agree
> - while it may be battle-worn (in the good stable sense), it is a
> dead-end development-wise, and not even the core developers want to mess
> with it, for all the reasons we stated earlier. It's abandoned.
>
>
> 3. Contributors contribute to projects they use. As a consequence of
> being a user, they stumble upon bugs and enhancements, hopefully report
> them, and even more hopefully contribute solutions themselves. If they
> don't use a project, the chances of contributing as an academic exercise
> is slim.
>
>
> From these 3 assumptions, the potential contributor's deadlock is
> evident - he will be willing/able to contribute only to 3.x, he will be
> willing/able to actually use in his project/production systems only a
> 2.x, and since it's unlikely that he'll develop for a product he doesn't
> use, he thus he won't contribute at all, and keep bitchin' on 2.x being
> dead and 3.x not getting anywhere, because no one else will either.
> While this is a generalization, I think it does apply to many if not
> most potential contributors.
There are people using current TRUNK, as Robert states in a separate
reply on this thread. Some do because of the Spring-based deployment.
In general, I full-heartedly agree with you: The average mailmaster does
not test trunk.
> How do u break this deadlock? In my opinion - by making a 3.x release.
> Even a Beta. It can get early adopters to adopt, send the message that
> it's becoming ready for the average user, and start the
> use-interact-contribute cycle that's necessary for the project to get
> back on track.
+1.
"Contribution" covers everything from installing, running and reporting
test results to bug reports, documentation patches, code patches.
Today I contributed a patch to another Apache project I never
contributed to before. The patch was utterly trivial: One word changed
in a toString() method. It was created in less than 5 minutes. The patch
was applied within less than 10 minutes!
What I want to say by this is: It doesn't take much to make a difference
on an open source project. The borders between user, contributor and
committer are floating.
I can understand why people are frustrated. I am, too.
It's because something has changed within the last couple of month:
Three committers who were heavily using James on a daily basis moved on.
They were first hand testers of TRUNK.
Instead, at the moment, TRUNK is largely untested. So nobody knows
exactly how good it really is (or they don't report here).
So if the community asks for a milestone release, we all must be aware
of the fact that we then need to do actual testing on the released
software. Otherwise, releasing a milestone serves no real purpose. So
others need to jump in and test.
> What should be included in such a release? what do users want? As a
> start, I'd say a Java mail server. That's what users search for when
> they find JAMES. SMTP/POP3 and a DB backend. No fancy bells and whistles
> just yet. A bare-bones replacement for 2.x. And as can be seen from some
> other Java mail server projects mentioned here or googled, that's
> shouldn't become a 3-year project, but a rather modest goal for a
> handful of core developers. One only needs the very basics that will
> bring 3.x into the spotlight as an alternative to 2.x, and after things
> get into motion it can take off to many creative directions.
>
> That's my take on it, anyway :-)
Thanks for your suggestions. And you are right: Technically, a release
is not a complicated thing to do. Actually every developer should be
able to help out. If nobody does, 3 years can actually become a very
short time.
Bernd
>
>
> -Amichai
>
>
>
>
> Robert Burrell Donkin wrote:
>
>> On Sun, May 10, 2009 at 4:38 PM, BJ <bj...@free-man.com> wrote:
>>
>>> Though I agree about the feeling of livelness, I also know that all
>>> apache projects are community based.
>>> so the way to get things cleaned up is roll up your sleeves and jump in
>>> offer to do the clean up and make it fresh.
>>>
>>> My point of view is James is a very powerful application. I have
>>> integrated it into other Apache projects.
>>> Though I have been on a sort of leave from contributing, I am just
>>> getting back into the grove.
>>>
>>> Hope you see you and others join in.
>>>
>>
>> cool :-)
>>
>> i'm very willing and able to help contributors get started. maybe
>> we'll be able to pull out some code into libraries to make it easier
>> to learn.
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, May 12, 2009 at 11:36 AM, A. Rothman <am...@amichais.net> wrote:
>
> I think JAMES is currently in a deadlock of sorts regarding contributors. My
> base assumptions are -
>
>
> 1. The only usable version of JAMES at the moment is 2.x. Other than core
> developers, very few users will checkout trunk on some random day and use
> that as a production system. 3.x is off-limits for normal users, at least
> until there's some milestone release they can depend on.
i know of projects downstream that use 3.0. also a number of
developers use 3.0.
> 2. No one is going to contribute to 2.x. As everyone here seems to agree -
> while it may be battle-worn (in the good stable sense), it is a dead-end
> development-wise, and not even the core developers want to mess with it, for
> all the reasons we stated earlier. It's abandoned.
it's not abandoned - it's just mature
bugs are fixed and minor improves backported (see
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10411&styleName=Html&version=12312493)
if there are contributors willing to test a new release then it might
be possible to cut a 2.3.2 sometime soonish
> 3. Contributors contribute to projects they use. As a consequence of being a
> user, they stumble upon bugs and enhancements, hopefully report them, and
> even more hopefully contribute solutions themselves. If they don't use a
> project, the chances of contributing as an academic exercise is slim.
the libraries (IMAP, mime4j, jsieve, jspf) have downstream users and
are more accessible for new developers. i would like to see more
services factored out into reusable, OSGi enabled services but i doubt
that this view is a consensus one.
> From these 3 assumptions, the potential contributor's deadlock is evident -
> he will be willing/able to contribute only to 3.x, he will be willing/able
> to actually use in his project/production systems only a 2.x, and since it's
> unlikely that he'll develop for a product he doesn't use, he thus he won't
> contribute at all, and keep bitchin' on 2.x being dead and 3.x not getting
> anywhere, because no one else will either. While this is a generalization, I
> think it does apply to many if not most potential contributors.
>
> How do u break this deadlock? In my opinion - by making a 3.x release. Even
> a Beta.
the conventional terminology here at apache would be a milestone.
> It can get early adopters to adopt, send the message that it's
> becoming ready for the average user, and start the use-interact-contribute
> cycle that's necessary for the project to get back on track.
james has been short of contributors willing to push any 3.0 releases
after the explosion
IMHO a major consequence of the explosion was that obtaining the
consensus required to release became improbably (until enough time has
passed and enough new contributors emerged). time has passed but very
few contributors have emerged for the server (unlike the libraries).
> What should be included in such a release? what do users want? As a start,
> I'd say a Java mail server. That's what users search for when they find
> JAMES. SMTP/POP3 and a DB backend. No fancy bells and whistles just yet. A
> bare-bones replacement for 2.x.
2.x already works very well for this
we've discussed issues a stripped down 3.x but without deciding on a
new framework to replace avalon, it seems a little pointless...
> And as can be seen from some other Java mail
> server projects mentioned here or googled, that's shouldn't become a 3-year
> project, but a rather modest goal for a handful of core developers.
james already has a SMTP/POP3 server that's proved production ready
with an advanced architecture: it's called 2.3.1. the basic SMTP/POP3
code's fine (and the 3.x code is essentially the same). there's no
reason to rewrite it.
but if you're interested just in POP3 and SMTP - please start
contributing (james is very short of active developers in that area).
i'm confident that just a few more interested contributors in this
area would make a big difference.
> One only needs the very basics that will bring 3.x into the spotlight as an
> alternative to 2.x, and after things get into motion it can take off to many
> creative directions.
if that's your vision for james, then go for it! start contributing
and push for it :-)
IMHO it'd be much easier to start with solid, production ready SMTP
and POP3 code and just polishing it up than working on a new
implementation
otherwise, those developers whose interest lies in those creative
directions will just continue pushing the 3.x code onwards
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by Zsombor <gz...@gmail.com>.
On Tue, May 12, 2009 at 12:36, A. Rothman <am...@amichais.net> wrote:
>
> I think JAMES is currently in a deadlock of sorts regarding contributors.
> My base assumptions are -
>
>
> 1. The only usable version of JAMES at the moment is 2.x. Other than core
> developers, very few users will checkout trunk on some random day and use
> that as a production system. 3.x is off-limits for normal users, at least
> until there's some milestone release they can depend on.
>
>
> 2. No one is going to contribute to 2.x. As everyone here seems to agree -
> while it may be battle-worn (in the good stable sense), it is a dead-end
> development-wise, and not even the core developers want to mess with it, for
> all the reasons we stated earlier. It's abandoned.
>
>
> 3. Contributors contribute to projects they use. As a consequence of being
> a user, they stumble upon bugs and enhancements, hopefully report them, and
> even more hopefully contribute solutions themselves. If they don't use a
> project, the chances of contributing as an academic exercise is slim.
>
>
> From these 3 assumptions, the potential contributor's deadlock is evident
> - he will be willing/able to contribute only to 3.x, he will be
> willing/able to actually use in his project/production systems only a 2.x,
> and since it's unlikely that he'll develop for a product he doesn't use, he
> thus he won't contribute at all, and keep bitchin' on 2.x being dead and 3.x
> not getting anywhere, because no one else will either. While this is a
> generalization, I think it does apply to many if not most potential
> contributors.
>
> How do u break this deadlock? In my opinion - by making a 3.x release. Even
> a Beta. It can get early adopters to adopt, send the message that it's
> becoming ready for the average user, and start the use-interact-contribute
> cycle that's necessary for the project to get back on track.
>
> What should be included in such a release? what do users want? As a start,
> I'd say a Java mail server. That's what users search for when they find
> JAMES. SMTP/POP3 and a DB backend. No fancy bells and whistles just yet. A
> bare-bones replacement for 2.x. And as can be seen from some other Java mail
> server projects mentioned here or googled, that's shouldn't become a 3-year
> project, but a rather modest goal for a handful of core developers. One only
> needs the very basics that will bring 3.x into the spotlight as an
> alternative to 2.x, and after things get into motion it can take off to many
> creative directions.
>
> That's my take on it, anyway :-)
>
>
> -Amichai
>
>
+1 on a 3.x release, which I'm waiting for ages :)
BR,
Zsombor
Re: Project status and perception
Posted by "A. Rothman" <am...@amichais.net>.
I think JAMES is currently in a deadlock of sorts regarding
contributors. My base assumptions are -
1. The only usable version of JAMES at the moment is 2.x. Other than
core developers, very few users will checkout trunk on some random day
and use that as a production system. 3.x is off-limits for normal users,
at least until there's some milestone release they can depend on.
2. No one is going to contribute to 2.x. As everyone here seems to agree
- while it may be battle-worn (in the good stable sense), it is a
dead-end development-wise, and not even the core developers want to mess
with it, for all the reasons we stated earlier. It's abandoned.
3. Contributors contribute to projects they use. As a consequence of
being a user, they stumble upon bugs and enhancements, hopefully report
them, and even more hopefully contribute solutions themselves. If they
don't use a project, the chances of contributing as an academic exercise
is slim.
From these 3 assumptions, the potential contributor's deadlock is
evident - he will be willing/able to contribute only to 3.x, he will be
willing/able to actually use in his project/production systems only a
2.x, and since it's unlikely that he'll develop for a product he doesn't
use, he thus he won't contribute at all, and keep bitchin' on 2.x being
dead and 3.x not getting anywhere, because no one else will either.
While this is a generalization, I think it does apply to many if not
most potential contributors.
How do u break this deadlock? In my opinion - by making a 3.x release.
Even a Beta. It can get early adopters to adopt, send the message that
it's becoming ready for the average user, and start the
use-interact-contribute cycle that's necessary for the project to get
back on track.
What should be included in such a release? what do users want? As a
start, I'd say a Java mail server. That's what users search for when
they find JAMES. SMTP/POP3 and a DB backend. No fancy bells and whistles
just yet. A bare-bones replacement for 2.x. And as can be seen from some
other Java mail server projects mentioned here or googled, that's
shouldn't become a 3-year project, but a rather modest goal for a
handful of core developers. One only needs the very basics that will
bring 3.x into the spotlight as an alternative to 2.x, and after things
get into motion it can take off to many creative directions.
That's my take on it, anyway :-)
-Amichai
Robert Burrell Donkin wrote:
> On Sun, May 10, 2009 at 4:38 PM, BJ <bj...@free-man.com> wrote:
>
>> Though I agree about the feeling of livelness, I also know that all
>> apache projects are community based.
>> so the way to get things cleaned up is roll up your sleeves and jump in
>> offer to do the clean up and make it fresh.
>>
>> My point of view is James is a very powerful application. I have
>> integrated it into other Apache projects.
>> Though I have been on a sort of leave from contributing, I am just
>> getting back into the grove.
>>
>> Hope you see you and others join in.
>>
>
> cool :-)
>
> i'm very willing and able to help contributors get started. maybe
> we'll be able to pull out some code into libraries to make it easier
> to learn.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
Re: Project status and perception
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, May 10, 2009 at 4:38 PM, BJ <bj...@free-man.com> wrote:
> Though I agree about the feeling of livelness, I also know that all
> apache projects are community based.
> so the way to get things cleaned up is roll up your sleeves and jump in
> offer to do the clean up and make it fresh.
>
> My point of view is James is a very powerful application. I have
> integrated it into other Apache projects.
> Though I have been on a sort of leave from contributing, I am just
> getting back into the grove.
>
> Hope you see you and others join in.
cool :-)
i'm very willing and able to help contributors get started. maybe
we'll be able to pull out some code into libraries to make it easier
to learn.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Project status and perception
Posted by BJ <bj...@free-man.com>.
Though I agree about the feeling of livelness, I also know that all
apache projects are community based.
so the way to get things cleaned up is roll up your sleeves and jump in
offer to do the clean up and make it fresh.
My point of view is James is a very powerful application. I have
integrated it into other Apache projects.
Though I have been on a sort of leave from contributing, I am just
getting back into the grove.
Hope you see you and others join in.
A. Rothman sent the following on 5/10/2009 5:58 AM:
> Hi all,
>
> Here's a thought/feeling I've been having for a while regarding JAMES,
> as a user of many years (both at work and at home). It's not at all
> meant as a rant, but as the personal experience of a long time user who
> really wants to see this project thrive - this is how it looks from the
> 'outside'. [reposted from elsewhere - oops :-) ]
>
>
> Speaking for myself, I can't exactly say that I'm interested in more
> releases and features from a 2.x codebase with no active developers,
> targeted at Java 1.4 (won't even compile on 6), with chunks of the
> project's wiki (even task-related pages) last updated 4 years ago, based
> on some framework projects that have been discontinued years ago... at
> least that's the impression the project is making in the past couple of
> years - that it is a dying one.
>
> But, I wouldn't want to abandon it either. As a user, the alternatives
> are either the above, or a trunk 3.0 version whose status, progress and
> future is not quite clear either - there's a v3 wiki page that was last
> updated at the beginning of 2005! Perhaps it's time for a proper
> alternative? Perhaps an alpha/beta of 3, with a fresh feeling of
> liveliness? Something to show a clear sign of activity and progress?
> cleaning up the wiki from ancient roadmaps and plans which have been
> abandoned long ago? I think that feeling of freshness would make it much
> easier to contribute than the current uninviting feeling of gloom... I
> contribute to several projects in what spare time I've got, and this one
> always gets pushed to the bottom of the list because of that feeling of
> 'who knows if it's not already dead? Are there more than a dozen users
> still using it? haven't seen any movement there in months, years... why
> not work on that other well-supported project instead?' Or to paraphrase
> the well known quote - "contributors contribute to those projects who
> help themselves"...
>
> ...is it just me?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707786#action_12707786 ]
Amichai Rothman commented on JAMES-902:
---------------------------------------
I apologize - I will.
As for javamail, since I am not aware of the issues Stefano mentioned a few comments up, I can't do anything about fixing or patching them. I just dropped in the new jar and it *seems* to work so I didn't realize there was more to it. So I guess this bug can be closed as wontfix, as Stefano implied.
If trunk/3 isn't using javamail 1.4.2 either, u might want to upgrade it there.
Thanks :-)
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Assigned: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer reassigned JAMES-902:
-----------------------------------
Assignee: Norman Maurer
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
> Assignee: Norman Maurer
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707659#action_12707659 ]
Robert Burrell Donkin commented on JAMES-902:
---------------------------------------------
Submit a patch ;-)
(I'll review it unless anyone beats me to it)
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707777#action_12707777 ]
Amichai Rothman commented on JAMES-902:
---------------------------------------
Speaking for myself, I can't exactly say that I'm interested in more releases and features from a codebase with no active developers, targeted at Java 1.4 (won't even compile on 6), with chunks of the project's wiki (task-related pages) last updated 4 years ago, based on some framework projects that have been discontinued years ago... at least that's the impression the project is making in the past couple of years - that it is a dying one.
But, I wouldn't want to abandon it either. As a user, the alternatives are either the above, or a trunk 3.0 version whose status, progress and future is not quite clear either. Perhaps it's time for a proper alternative? Perhaps an alpha/beta of 3, with a fresh feeling of liveliness? Something to show a clear sign of activity and progress? cleaning up the wiki from ancient roadmaps and plans which have been abandoned long ago? I think that feeling of freshness would make it much easier to contribute than the current uninviting feeling of gloom... I contribute to several projects in my spare time, and this one somehow always gets pushed to the bottom of the list because of that feeling of 'who knows if it's not already dead? Are there more than a dozen users still using it? haven't seen any movement there in too long... why bother?'
...is it just me?
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707700#action_12707700 ]
Amichai Rothman commented on JAMES-902:
---------------------------------------
ok, thanks :-)
I find it somewhat unintuitive - the place I'd expect it is under 'source code' or the 'binary and source' link to the downlaod page - that's generally were svn urls are found in OSS projects. It would actually make a lot of sense if the svn web-viewer (the 'source code' link) would show the real non-web svn url somewhere...
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707670#action_12707670 ]
Stefano Bagnara commented on JAMES-902:
---------------------------------------
It is not as straightforward as it can seem. I had a big issue when upgrading javamail to 1.4.2 because they changed the way they handle nested encoding in multipart messages. The new way is RFC compliant but I had to fix a lot of code in order to make my deployment work with javamail 1.4.2 instead of 1.4.1.
A javamail upgrade would require a lot of testing, more than what we are probably willing to do for a 2.3.x release.
So I think it is better to let some people simply replace the javamail library in their deployment if they need the updated one, for 2.3.1..
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707781#action_12707781 ]
Stefano Bagnara commented on JAMES-902:
---------------------------------------
@Amichai ... please use the mailing list for this kind of comments. Here we should only discuss the issue "Upgrade to Javamail 1.4.2" related to the "2.3.1" release.
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-902) Upgrade to JavaMail 1.4.2
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer resolved JAMES-902.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0-M1
Trunk was upgraded to javamail 1.4.3
> Upgrade to JavaMail 1.4.2
> -------------------------
>
> Key: JAMES-902
> URL: https://issues.apache.org/jira/browse/JAMES-902
> Project: JAMES Server
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: Amichai Rothman
> Assignee: Norman Maurer
> Fix For: 3.0-M1
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org