I still use James v2 in production. I could be convinced to move forward
(migration of config is a concern), but I still do run it, and would be able to
fix any bugs, given the amount of code in there that was written by me.
Are there any particular defects that need to be addressed? I agree
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:
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
i quite fancy experimenting with some stuff (for example OpenJPA) that
requires java 5.
I want to see annotations, myself. And favor a move to Java 6, as long as
we are making the big switch.
following long term strategy: we use the same module system but ship
the phoenix built under 1.4
Norman Maurer asked:
Why we would need java 6 ? Which feature you miss in java 5 ?
JSR-223, for one. Yes, we could backport using BSF, but deployment would be
easier if we went with Java 6.
Also, little features include SSLParameters class that encapsulates the
configuration of SSL
Stefano Bagnara wrote:
The current process is a simple nighly build [that] is good
for the nighlies, but I think I don't have to explain the
difference between a real CI environment and a nighly build script.
That is correct. We have a CI at the ASF. The nightly wasn't intended to
replace
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?
We don't
We had a number of recent messages (2 related to spring, 2 related to
imap) about people trying to build sandboxes or branches code for things
we already merged to trunk.
I don't see a handful of messages as necessitating a massive change in our
source structures. Just leave everything alone
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 PROTECTED]
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.
--- Noel
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: [EMAIL
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 atmosphere we were able to overcome
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
environment.
Every message can
Serge Knystautas wrote:
This is a good example of Robert's points on modularity. If mordred
was a separate project built separately, we could keep it as a binary
dependency, no?
Except that the issue is that mordred needs updating because it no longer
works with newer versions of Java.
Robert Burrell Donkin wrote:
there is no prospect of releasing trunk without Noel's active support.
I hope that's not actually the case, but regardless, what does the PMC think
of the following?
Trunk is simply not trustworthy. Anyone who would consider releasing from
trunk would do little to
Bernd Fondermann wrote:
I don't trust 2.3.1 more than TRUNK or any other James snapshot.
That's really too bad, since we know from empirical experience that JAMES
2.3 + my patches hold up to years of real-world production loads. We have
some justification that 2.3.x are OK because we're not
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 created JIRA-605 (http://issues.apache.org
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 release or could just
Hontvari Jozsef wrote:
The current 2.3.1 cannot be compiled using ant compile-main, because
mordred PoolConnEntry assumes a very old version of java.sql.Connection.
Is this correct?
Probably, with the newest versions of Java. Mordred is deprecated, and
since I don't see any reason to update
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 commands, e-mail:
Hontvari Jozsef wrote:
The trunk receives all changes. It must always be in a useable state.
Trying convincing people of that. :-) Robert, for example, explicitly
considers that to be the wrong approach, and indicates that he considers a
substantial amount of trunk to be junk. His thought is
I wasn't referring to the obvious intent, I was referring to the fact that
there are commits to each branch that are not present in the other. So your
suggestion to:
svn cp v2.3 next-minor
would lose commits in next-minor that are not present in the v2.3 branch.
Nevermind. I'll continue to
A year and a half ago, Norman created next-minor to Rename v2.3 branch to
next-minor, but as far as I can see, branches/v2.3 continued, and I'm
trying to figure out what was done, since it appears that there was a
divergence.
Norman, can you elaborate while I review the commit logs?
FWIW, I've
After discussion of various technical and non-technical things at ApacheCon
by Robert, Bernd, Norman and myself, here's a road forward.
When I get a moment (right now, I am in the planning meeting for ApacheCon
US New Orleans), I am going to branch from v2.3.1. I am going to re-review
the diff
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 java file at:
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, e-mail: [EMAIL
Danny Angus wrote:
I'm not sure what google think about more than one student per idea,
Since the MLM is modular, perhaps they can work on different parts. There is
plenty to do there. I have a whole list of MLM related activities, each of
which could be GSoC-sized.
For example, when the
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.
--- Noel
| are you interested in verp or mladmin?
I threw a glance on VERP and think it's indeed quite interesting.
Please note that I've already written and contributed a REGEX-based VERP
parser. The real issue would be implementing VERP in the mailing list
manager, along with other necessary
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
[mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 2:14
To: James Developers List
Subject: RE: GSOC?
+1
Norman
Am Mittwoch, den 12.03.2008, 16:19 -0400 schrieb Noel J. Bergman:
Enhance the mailing list manager. Add moderation, confirmation, etc.
--- 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
Robert Burrell Donkin wrote:
I think that I'd rather we follow the example of other
getInputStream/getReader exemplars, and throw
java.io.UnsupportedEncodingException if it is called on a type for which
a
Reader is not appropriate.
in the end, i decided that consistency was more
Robert Burrell Donkin wrote:
IMAP requires case-insensitive charset-aware searching of mail body
parts (a bit of a PITA, i know and most likely slow). ATM the Mime4J
pull parser has a getInputStream method but i plan to add a getReader
method which will perform charset-aware
Stefano Bagnara wrote:
I think it is a different story. That branch involved much less code than
current v2.3-trunk differences but included major changes to mailet api.
Yes, much less code. More code == more bugs. And you certainly aren't
going to claim that there aren't major changes in
Robert Burrell Donkin wrote:
releasing a 3.0 would involve a series of milestone releases to
build confidence in the new codebase rather than a manual process
of re-evaluating every change.
Re-evaluating implies that they were evaluated in the first place.
i hope to have a function complete
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 prior to the
refactorings, but instead
Robert,
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 prior to the
refactorings, but instead we started with unstable baselines and refactored,
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]
[
https://issues.apache.org/jira/browse/JAMES-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569719#action_12569719
]
Noel J. Bergman commented on JAMES-290:
---
Please submit an diff against the v2.3.1
Bernd,
This is the tail from the current build log:
-
[junit] Running
org.apache.james.experimental.imapserver.ExperimentalAuthenticatedStateTest
[junit] Location:
/org/apache/james/test/functional/imap/scripts/AppendExpunge.test:80
[junit] Expected: '\* 1 EXPUNGE'
I need to modify the nightly build script. The reporting problem is that
because the build failed, the directory wasn't created, and the log file
could not be moved into the expected place to be uploaded.
Should be fixed, as you can see from the manually executed runs of the
nightly build
Embeding james in databases is not as silly as you seem to think, Dan
Debruner proposed embeding james in derby a couple of years ago.
Admins want to run the products they know, and as little else as
possible.
That's generally down to laziness, not good architecture. And it can hamper
other
Bernd Fondermann wrote:
- The Web container is the wrong container
One has to get used to it. ;-)
Oh, please, I spend more time in the web container than you do awake. :-p
Still doesn't make the web container the right place to embed a fairly heavy
mail server, as opposed to providing a
Stefano Bagnara wrote:
The really cool thing would be to have each top level component deployable
as separate osgi bundle, so to be able to undeploy the spool manager,
alter mailet configuration, deploy it back (and other similar things).
Mailet configuration seems the wrong place. Pipeline
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.
:-)
--- Noel
with the release of the OSGi extension to Spring[1], it seems to be
reasonably easy to turn any spring app into an OSGi deployment ('bundle').
Yes, but doing so seems backwards. It appears that SpringSource is
conceding that OSGi is to Spring as JSF is to Struts, and that Spring will
go the
In case anyone noticed, yes, I changed the release build e-mail. Instead of
sending 75K - 100K+ to the mailing list every night, the new report includes
any errors reported by unit testing and the tail from the build log, the
full contents of which are uploaded along with the artifacts.
We will
When I build TRUNK locally , I always get a fresh copy of all /stage/*
jars
because target is deleted on every run.
But the nightly doesn't work that way currently
The nightly build does dist build, which implies a clean. If there are
droppings that aren't being cleaned up by the clean
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
-
To
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
AFAIK ToRepository code has not changed since 2.2.
See
http://svn.apache.org/viewvc/james/server/tags/build_2_3_1/src/java/org/apac
he/james/transport/mailets/ToRepository.java?r1=109067r2=532358diff_format
=h
I haven't looked into the deeper dependencies, but I do concur that the URL
described
Danny Angus wrote:
I agree, but the message body should be a serialised Mail and not a
Message to keep things simple.
I don't know that the message needs to be a serialized Mail as opposed to some
other text format, to make things easier (a goal of Robert's) -- the key is
that we need the
Robert Burrell Donkin wrote:
Tom Brown wrote:
3. As SMTP-to-JMS bridge (reverse of #1)
a. JAMES receives mail
b. JAMES publishes mail to specific JMS queue or topic
c. mail is processed/stored/whatever by any interested listeners
fancy volunteering to contribute some code to do this?
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 method, and
how would
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 ought to use it.
See also:
http://www2.osgi.org/JSR291/HomePage
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.g., if you have a use
Robert Burrell Donkin wrote:
A generic base class for [posting to a JMS destination],
with an abstract createMessage method, would let people
create their own subclass to provide whatever ad-hoc JMS
message they desire.
i'd prefer delegation to inheritance
Delegate to a message factory,
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 ought to use it.
AIUI OSGi is not IoC but COP
See http
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 IMAP.
Why?
the mailbox API is full of cruft but most
Robert Burrell Donkin wrote:
the current table structure [in trunk] is inefficient.
opinions?
As I said, toss and reboot.
We need to change the data storage scheme. As a strawman, we should
separate spool, mailbox and message store.
The message store is simple: the message. Once a
In the specific case of interface and implementation, perhaps the package
name rather than the class name should be used to distinguish interface from
implementation. Then the class names can be intentionally identical, with
the package name semantically indicating the difference to the viewing
the current table structure is inefficient.
opinions?
Which table structure? If you mean in v2.3.1, we need to separate out the
message body from the mailbox entries. If you mean this torque nonsense, I
will reiterate: trunk is crap. Fix whatever you find. Discard torque
entirely, in fact.
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 transactionality at the processor level is important.
Using just a database for both spool and message store is
i didn't see this before but blending jsieve with mailets would be
quite powerful
No time to respond properly, but yes, I've said so multiple times. :-)
Steve's primary use case is within IMAP, especially for your:
one use case would be for safe per-user scripting
but I like the idea of
ImapMailboxSession (see 1) is implemented only by
ImapMailboxSessionWrapper (see 2) and these methods are only outlined.
Which is amusing, since this entire thing came about only for IMAP.
in general, i think that would be a good idea to simply the mailbox
API. eliminating this interface
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
-
To unsubscribe,
the mailbox API is abundently provided with abstract factories
hopefully someone will jump in here to explain the history behind this
design...
I think that we need to revisit the whole area. I don't consider much of
the code in the trunk more than experimental directions that various people
Bernd Fondermann wrote:
Building the source distribution from the nightly build fails. Both top
level properties files are missing and a lot of java source files are
missing, too.
Shouldn't we build the source distribution from root directory (parent
of phoenix-deployment and all other
I will go on record that I oppose a move to Spring, and have said so on
multiple occassions. However, I do not oppose optional support for Spring.
So long as we are agreed on that, I'm +1 to on the latter.
As a consequence, we would be able to release a Spring-container-based
Server runtime
See: http://wiki.apache.org/incubator/ComposerProposal
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 unsubscribe, e-mail: [EMAIL
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
Robert Burrell Donkin wrote:
the disadvantage with using a byte array rather than a bytebuffer is
that direct bytebuffers would have to copy their data out into a byte
array. using a byte buffer at the lowest level would solve this issue
without really an added overhead for the bio case
Robert Burrell Donkin wrote:
your patch would require double buffering when used with direct
buffers and would require convertion of structured data into bytes.
so, it's unsatisfactory for use cases 1 and 2. however, i'm not sure
whether this is something that is worthwhile arguing about.
Robert Burrell Donkin wrote:
it's really about objectives and aims rather than technical designs
i wonder whether it's worthwhile having what's probably going to be a
long technical discussion about a design for a unified parser for both
streams and non-streams. if no one else really feels
Robert Burrell Donkin wrote:
Jochen Wiedmann wrote:
robert burrell donkin-2 wrote:
i'd like to gauge opinions about whether anyone else feels strongly
about supporting non-streaming inputs for MimeTokenStream. i've been
keeping this in mind whilst reviewing jochen's patches but this
Robert Burrell Donkin wrote:
i could reduce the quantity of warnings etc
but perhaps they are useful reminders.
Perhaps.
what i could do is add a 'quiet' property which would allow people to
decide whether they need to see all that noise or not. opinions?
If that just means that the nightly
Stefano Bagnara wrote:
I use/know continuum.
Just level setting the discussion for Danny, Serge, Bernd, Norman, Steve,
Soren, Robert, ...
Besides, since *you* asked about Continuum, I wanted to keep you up to date.
I hope they will be ready soon with something stable enough for Infra
to
If you make a tail -20 of log (and full log... pkzip attach as file?)
:-)
We block those attachments, IIRC. :-) Besides, the full script is:
#!/bin/sh
#
#
(
echo To: JAMES Server Development server-dev@james.apache.org
echo From: JAMES Nightly Build System [EMAIL PROTECTED]
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.
I would like to have nightly for everyone of our projects: some day ago
I had to do a nightly build for jspf to let an user test a bugfix.
Where do you run this
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? Anything else we want to strip out
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 running, but still exhibiting issues
Something has been changed in the past couple of weeks, and the nightly
build e-mails are broken again. Since the last one, containing 94K, was
sent on August 10th, we have not only gone over 100K of output, we're at
239K of output!
As a point of reference, back in December, the breakdown was:
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.PoolConnEntry class that implements
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
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 unsubscribe,
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 when revamping our website.
Well, then I
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-minor (delayed 6
months), then simply go ahead
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.
I have already generated a complete diff between 2.3.0 and 2.3.1 to see what
was done to the code and packaging, and stripped out the licensing changes
so
Just a heads up that the nightly builds may be down for a night or two.
Hopefully not longer. A fire down the street took out electric and internet
service. Power is back, but the internet service still needs to be
repaired.
--- Noel
Whats grok? I can't find a german word for it :-(
It is a made up word from a book by Robert Heinlein that ended up in the
English language (q.v. http://en.wikipedia.org/wiki/Grok)
--- Noel
-
To unsubscribe, e-mail:
Yeah there's something wrong, it should have failed because
org.apache.mailet.Mail cannot be found.
At a quick glance, it seems that the build script isn't cleaning the staging
area. And artifacts that are dependencies are conflated with artifacts that
we generate during the build, so simply
[
https://issues.apache.org/jira/browse/MAILET-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel J. Bergman reassigned MAILET-1:
Assignee: Noel J. Bergman
Fix commit messages to go to mailet-api
[
https://issues.apache.org/jira/browse/MAILET-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel J. Bergman resolved MAILET-1.
--
Resolution: Fixed
Should be fixed.
Fix commit messages to go to mailet-api
What target is/are invoked by the build server?
ant dist, since clean is supposed to be implied by dist.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
If you prefer to clean the build.xml instead of changing your build
server I have no problem with this.
We'd already determined that a dist should imply a full clean. The old
build.xml did this, but that was lost in the refactoring. I've made the
change, but it is insufficient, because it
Stefano Bagnara wrote:
Noel J. Bergman ha scritto:
it doesn't remove files from the staging area, so an old copy
could still be used if not overwritten
I think you're missing something because here is not happening
what you say (I use clean before the dist): ant exited with
error.
You may
1 - 100 of 1312 matches
Mail list logo
