that it
should be viewed as maintenance only, with no new development.
Oh, and hi! 😊
--- Noel
-Original Message-
From: btell...@apache.org
Sent: Friday, July 23, 2021 5:18
To: server-dev@james.apache.org
Subject: End of support for Apache James 2.3.2 ?
Hello,
Following
I'm updating the system that hosts the nightly build, so we probably won't
have a build tonight.
--- Noel
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: se
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
I'm fine with requiring Java 5 or even Java 6 at this point.
--- Noel
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
nd
consistent manner. So, no, it is not acceptable for each bundle to have its
own ad hoc means of configuration. We want the ability to have a consistent
configuration delivered to the service, and that seemed to be what Danny had
in mind: a service that read configuration from some source, a
o the component to be
configured, which would allow us to use Spring or Commons Configuration or
anything else.
Regardless, we'll want to go back to plain POJO interfaces. And that's
another reason for looking at annotations.
--- Noel
-
built under 1.4 (without new features) and spring built
> under 1.5 (with the new features).
-1 to Spring. +1 for OSGi.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
me.
LOL Actually, you're right -- I went back and cbecked. It is always you who
disagrees, but in this case it was BERND! LOL OK, I apologize. :-)
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Norman Maurer wrote:
> > We've talked about having a JAMES zone for testing.
> I think a zone is fine for testing but please not another CI instance
> running.
Absolutely. We agree. We want the zone for TESTING of JAMES, not a CI.
:-)
> the current Nightly Build stuff is under control of Noel
> and we have no way to tune or make better investigations
> there.
Yes, and I am happy to provide that service to the greater JAMES community.
Was there a Thank You in there somewhere, or just your usual complaining
behavior?
&
ave everything alone unless/until a real need
arises.
And for certain do NOT delete anything (aside to Robert).
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> rewriting the JAMES spool using JMS would be good
Why?
You do realize that rewriting the spool for JMS actually means introducing a
spool broker service, right?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTEC
> FYI the build log is no more there since 9 days.
Thanks. Weirld. The script hadn't changed since February, but I saw the
problem. Must have been a race condition that allowed it to work at all,
but I've fixed it now.
Bernd Fondermann wrote:
> Noel J. Bergman wrote:
> > The proposal is based on the fact that every message delivered to the
zone
> > will be disposable spam. Therefore, unlike performing some sort of faux
> > release without any basis, we will be testing in a risk-free
e
Bernd Fondermann wrote:
> Noel J. Bergman wrote:
>> That sort of thinking led Stefano to push to rush out v2.3.0 over my
>> objections that there was a critical memory leak.
> This is an obvious attempt to discredit other committers and bring back
> the old hostile atmos
Robert Burrell Donkin wrote:
> if anyone needs to use mordred with newer versions of java then they
> can submit a patch
As I mentioned earlier, and we can deal with it then.
--- Noel
-
To unsubscribe, e-mail:
ne" on untested code and screw over
our users, who trust us, because some folks here don't understand the
fundamentals of stability and reliability. JAMES is not a game or hobby.
E-mail service is business-critical and time-critical. It tolerates near
zero defects.
--- Noel
--
C members
to send via it, or alternatively, allow relaying only when the connection
comes from p.a.o.
This would be a really good thing for helping us to improve trust in the
code, both now and as it evolves.
--- Noel
-
To
rsions of Java.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert Burrell Donkin wrote:
> Noel advocated deletion in another thread
After some years of resisting removing it. :-)
> I tend to be conservative about backwards compatibility. So I would
> tend to move the source into somewhere like legacy. Wouldn't take much
> to cut a
Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
> > Probably, with the newest versions of Java. Mordred is deprecated, and
> > since I don't see any reason to update mordred, it will be removed as
soon
> > as I can start work on the new stable branch.
> i've had enough of keeping mordred around in the source. why don't we
> just make mordred a separate library product?
See my reply.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
any reason to update mordred, it will be removed as soon
as I can start work on the new stable branch. I had hope to do it last
week, but / on my main server blew up and the server had to be rebuilt. And
right now, the ASF SVN repository is in read-only mode.
ver using JAMES, that's just not
the case. The spammers have raised the noise level so high that, for
example, fast-fail is really mandatory, not optional. Improvements in
fast-fail are important. My private build gets by; the public JAMES build
would be seriously
I'll continue to review diffs.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
gs?
FWIW, I've compared tags/build_2_3_1 and branches/v2.3, and that's fine.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ion branch, and reference the new package.
Trunk will also share that same releasable, so in that manner, we will
effectively "merge" production and trunk incrementally over time.
--- Noel
-
To unsubscribe, e-ma
> I don't get it why removing maven is not already discussed as an obvious
option here.
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Norman Maurer wrote:
> > You wrote that you already implement VERP parser, where i can see it? I
> > try to estimate difficulty of the task (moderation+archivation) in order
> > to include a schedule in my application.
> I think Noel is talkin about attached
> you can post but not subscribe to legal-private but i recommend
> legal-discuss as your first port of call
Danny can take any legal issues that need attention to legal-internal.
--- Noel
-
To unsubscribe,
> James already can archive mail, but to retrieve them you'd need to
> assign ID's to them.
And use VERP, for example, as part of the command pattern to retrieve them.
--- Noel
-
To unsubscribe
k
on message and subscriber moderation, archiving, etc.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
other necessary features, and then using VERP (with the
provided parser) when receiving bounces and similarly encoded messages.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> it's a bit tricky to use old JREs on gentoo so this was a test :-/
Define old. JSE 5 is old? Have we agreed to permit anything newer? I can
install newer on the build server, but stuck with what we agreed was the
level.
The build failed:
/home/noel/ASF/james/server/trunk/imap-codec-library/src/test/java/org/apach
e/james/imapserver/codec/decode/imap4rev1/SearchCommandParserCharsetTest.jav
a:49: cannot find symbol
[javac] symbol : method getBytes(java.nio.charset.Charset)
[javac] location: class
For the "etc.", add VERP and bounce handling. I've already written and
posted the VERP parser, and can do so again.
Robert and Danny: are one of you going to do the GSoC work this year, or are
you waiting for someone else to do it?
--- Noel
-Original Message---
Enhance the mailing list manager. Add moderation, confirmation, etc.
--- Noel
-Original Message-
From: Robert Burrell Donkin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 9:44
To: James Developers List
Subject: GSOC?
http://wiki.apache.org/general/SummerOfCode2008
t a trivial pull parser
> application. definitely not worth a major design exercise. probably
> best as a worked example somewhere in the documentation.
I suspect that it will have a lot more utility than that. Mailets will want
to search for text within the message structure.
--- Noel
headers or parts of only certain content-type(s)?
Point being that, yes, I'd like to have a search functionality, but I'd like
some discussion over the interface and supported use cases. And if we don't
build this into an existing class, it could be a
yment, the only change that springs to mind are
> the JAMES handler framework improvements. if inheritance were to be
> replaced by delegation for this framework then most modules would have
> very few changes.
Sounds like the start of a discussion.
--- Noel
g issues in our services API.
So you propose that we first vet v2.3.0 against a pre-reorg revision of
trunk, and then compare the current trunk against the first post-reorg
revision?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > It sounds OK, so +1 in general, but with all of the refactoring, we've
> > making it increasingly difficult to compare versions of JAMES. This
would
> > not be so bad if we had ever made a stable baseline pri
tored,
meaning that we will have to do considerable manual comparison between the
only known stable JAMES code (2.3.0) with its known defects and the current
trunk(s) for JAMES and Mailets.
--- Noel
-
To unsubscribe, e
Please attach the patch to the JIRA issue. In-line patches on the mailing
list get corrupted by mail clients.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
nightly build script.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
scripts/AppendExpunge.test:80
[junit] Expected: '\* 1 EXPUNGE'
[junit] Actual : '* 2 EXPUNGE')
[junit] Tests run: 54, Failures: 0, Errors: 3, Time elapsed: 12.236 sec
BUILD FAILED
/home/noel/ASF/james/server/trunk/build.xml:134: The following error
occurred while exec
oon, anyway, to maintain a version
of JAMES suitable for use in production, and will apply this code there for
testing.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/JAMES-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569719#action_12569719
]
Noel J. Bergman commented on JAMES-290:
---
Please submit an diff against the v2
r?
There is clearly a value to refactoring our component architecture, and
possibly one in allowing JAMES to move into a J2EE container. But the Web
container isn't the right place for it. The EJB container comes closer.
--- Noel
-
S inside of Oracle and DB2, too?
They're in mainstream use.
> As I reported recently, the phoenix-deployment is currently broken caused
> by JMS configuration issues.
Well, it would be nice if whomever broke it, fixed it.
--- Noel
--
ong place. Pipeline configuration means
configuring processors, which could be the deployable unit. Processors are
the containers for Mailets. Can you make the argument for why Mailets,
themselves, should not be kept simple and far far away from this stuff?
ring will
go the way of Struts. So why not write directly to the standard in the
first place, and discard the legacy Spring code?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> What do others think?
I think that:
- The Web container is the wrong container
- We should be doing OSGi, not Spring
- None of this has anything to do with improving JAMES for mainstream use
But have fun, as long as you don't break JAMES and/or introduce overhead.
:-)
see how it goes, but this is a lot less traffic, and it doesn't seem
that the build logs needed to be archived permanently.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [
leaned up by the clean target, that should be
fixed.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bernd Fondermann wrote:
> Noel, could you do me a favor please when you find the time and have a
> look into the stage directory on the build machine.
I purged it (rm -rf) and replaced it from SVN.
--- Noel
--
I will be there, arriving Monday morning of the Hack-a-thon on a red-eye
from the USA, and probably staying until the Friday *after* ApacheCon.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
ts that if deliveryHeader or resetReturnPath
isn't specified, the code will attempt to store a null message.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
means to inject Mail into James' processors." The
processors are managed by the spooler, and JMS doesn't support the dynamic
selection we need, internally, for the spooler.
--- Noel
-
To unsubscribe, e-ma
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > > ActiveMQ has good spring integration. it's a lot of work tapping
> > > it's power within phoenix.
> > OSGi, as JSR-291, is the emerged standard for JSE. Felix is our OSGi
> > container. We o
tle more effort: session and connection
> caching would be are needed for high throughput. commons pool would be
> good enough.
Keeping in mind the fact that there is a single mailet instance, and it has
reentrancy requirements. :-)
--- Noel
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > what are the real-world use cases for using JMS as that method, and
> > how would it improve on JavaMail or a simple wrapper around it?
> by not having to run SMTP
Non-answer, unless the SMTP protocol is the problem, e
7/08/osgi-jsr277-debate
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > You are talking about injecting messages into JAMES.
> yep
> easy ways to inject messages is a frequent request from users and
> those extending JAMES
Yes, but what are the real-world use cases for using JMS as that met
ethod, would
let people create their own subclass to provide whatever ad-hoc JMS message
they desire.
An effort of a few moments to code it, leaving configuring JNDI is an
exercise for the reader.
--- Noel
-
To unsubscribe,
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > Robert Burrell Donkin wrote:
> > > > > the current table structure [in trunk] is inefficient.
> > > > > opinions?
> > As I said, toss and reboot.
> today, this implies tossing and rebooting
ve
previously suggested that we could make that more flexible, allowing
different entry points for messages. It might benefit FetchMail, for
example, if it could bypass some of the things we do in the root processor.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ng
relational database means not requiring XA.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > Yes, Robert, I have looked at it as one of the options for future
spooling.
> > However, there are issues and it may not be the easiest and most
appropriate
> > solution.
> >
> > The requirement for transa
anyone having any low hanging fruit to include?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
human.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ly, in fact. Again, just another sandbox project gone wrong.
> if the table structure is changed then upgrade scripts will be needed.
Yes, and it depends upon the final tables.
--- Noel
-
To unsubscribe, e-mai
easier than having
both JMS and database, and thus requiring XA.
There are also issues related to filtering. JMS has a static definition of
filtering, which does not serve the needs of our spooler.
--- Noel
-
To
but I like the idea of using Sieve in the mailet pipeline, too.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> MessageResult (see 1) is a crucial part of the mailboxAPI. however,
> it's behaviour is not defined.
As previously noted, feel free to discard the entirety of the mailbox API
and start over.
--- Noel
-
ll of our needs,
but he indicated some weakness in searching or indexing for what MarkMail
needs to do.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ly place where I feel that LDAP offers a value to us is with user
credentials (e.g., SMTP AUTH and/or S/MIME certificates).
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
oyment and all other modules)?
Arguably, we shouldn't bother to distribute source for the nightlies. Just
binary, and let people come to SVN for anything else.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Projects in the Incubator have one set of issues to deal with (Incubator
policies); projects that *use* them, have others.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
> AFAIK plexus does not anymore support Avalon out of the box and I
> don't see anything about Avalon in the Composer proposal.
We'll see, and I've already raised the topic.
--- Noel
-
To unsubs
See: http://wiki.apache.org/incubator/ComposerProposal
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ver runtime besides our regular Avalon-based.
I'll start another thread on Avalon.
How much does your proposed merger effect the stability of code that
couldn't care less about Spring, e.g., the Avalon-based relea
ement.
Here's a question for the lot of you: is this similar to DOM vs SAX, and if
so, can we come up with a StAX solution? Just go with the analogy, but the
issue is a best of both worlds.
--- Noel
-
To unsubsc
laims
that we have not seen what he intends to present.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
;s talk about use cases before detailed design. As
Serge asked, what are the use cases for both? What are the trade-offs in
choosing to support or limit the exposed functionality?
Please note: I may not be responding until Sunday evening.
--- Noel
oposal?
>
> because if no one but me cares then there's little point in me
> obstructing your patches for what are design reasons
Let's have some technical discussion, please. I'm not sure that I've seen
enough to understand the dispute.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
at just means that the nightly builds run quiet, that'd fine with me.
As Stefano notes, we're currently working around it for the nightly build
using grep.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
eam. As we speak, Continuum is being
setup. Brett is preparing a team to support it within ASF infrastructure.
Phil Steitz has been moving Commons to it. I got my first Continuum
generated e-mail this morning (amusingly enough, it was a build error).
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> > You just wrote on general@ that ASF is planning allowing other java
> > based tools in the future: what about continuum? A continuum instance
> > with all of our projects would be great.
> Continuum is already runni
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> > What about a "| grep -v javadoc" while you write the mail body?
> Sure, I'll give it a shot and we'll see.
Please review the latest nightly build report. We're just under 64K.
Satisfied with the content
ng worse as more things go into it.
As noted above, I'm perfectly happy to do the builds. I have pretty much
dedicated a fast Athlon ubuntu system to it, at least during build hours.
:-)
--- Noel
-
To unsubscri
nit Tests and Distribution Packages
echo
ant -Ddeprecation=off dist
echo
echo Done. Packages Will Be Uploaded To The Nightly Repository.
echo ------
[copy] Copying files to : ~ 9K
[mkdir] Created dir: : ~ 9K
messages. Any idea how we can eliminate some of this extraneous garbage so
that the build report can be posted? Or should I just shut down the nightly
builds because no one cares
sentially unchanged from its current state.
The only difference is the removal of the JDBC 3 comments.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jukka Zitting wrote:
> Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > Please note that JAMES will not build with Java 6 unless Mordred
> > is removed or updated. Incompatible changes in JDBC.
> I checked that and the problem is
> org.apache.james.util.mordred.PoolConn
Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
> > Norman Maurer wrote:
>>> I finally found the time todo the releases for mime4j
>> Does it build with Ant?
> No, mime4j has always been a maven project. I moved it from maven1 to
> maven2 more than 1 year ago whe
Norman Maurer wrote:
> I finally found the time todo the releases for mime4j
Does it build with Ant?
> and james-project.
Why is this something that needs to be and should be released?
--- Noel
-
To unsubscr
Please note that JAMES will not build with Java 6 unless Mordred is removed
or updated. Incompatible changes in JDBC.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
> > I'm looking at a defect (one or more, but seemingly related) in the
current
> > release code, so I'll be forking a branch that is maintainable.
> Is this "next-minor" or something new? If it is next-m
1 - 100 of 2092 matches
Mail list logo
