Oh just listen to yourselves!
We should run the unit tests every time we build using ant, that is
the official way to build James.
Anything anyone does with any other tools is not our concern, we can't
control it so we should step back from getting involved.
If running the tests is a problem be
On 11/11/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> We should run the unit tests every time we build using ant, that is
> the official way to build James.
Sorry my bad, I expressed myself badly.
1/ Ant is the *only* sanctioned way to build James
2/ we should run the unit tests every time
On 11/11/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
AIUI, your proposal means multiple jars (instead of just james.jar),
multiple separate components,
Yes.
and complicates refactoring/introduction of
new internal modules. No?
No, it doesnlt have to. I understand why you wouldn't want
On 11/14/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
On 11/14/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Memory garbage should not be a problem any longer in the light of
generational GCs.
I'm not sure how you arrive at this sweeping conclusion!
Profligate use of memory is a problem
What we're really interested in here is being able to comit designed
tests before we commit the code which passes the test.
IMO that *is* TDD
What we're up against is the knowedge that some of the passes are a
low priority, and not critical enough to prevent others from working
on other aspects o
On 11/22/06, Jürgen Hoffmann <[EMAIL PROTECTED]> wrote:
And if trunk == next-major, where is the difference? Why is everyone so touchy
about the term?
The issue is that it has no meaning.
We all have our own ideas about what the next major release is, but
the term "next_major" is not defined.
Trying to inject a positive thought here...
Well, it's a label. Frankly, I'm almost getting used to it. I agree that
it has no meaning in the long-term, since it is a floater, and eventually
needs to have a real label attached to it, but that's a minor point.
In fact that is how we manage re
I am, flushed with my sucess last time ;-) I'm open to suggestions.
perhaps we could get two or three together and have a james "track"?
I thought I might take a line through Henning's one at EU05 and have a
brief intro to James followed by a more detail explanation of
extension points. Ideally I'
As I'm being quoted please read my comment at the bottom...
On 1/2/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Noel J. Bergman wrote:
> I see all of the work here, and Norman explained on Skype what he and
> Stefano are doing, but this is not the way that we develop code. Please
> correct me
On 1/4/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
I agree with everything you say, particularly about dialogue. I think
Noel's original comment was only meant to highlight the fact that this
dialogue should be public.
James might be held back if we make it difficult for people to
innovate, bu
+0
Now I'm voting, but I trust you guys to come to the right decision
without my input.
Happy Norman? ;-)
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 1/2/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
In a way really similar to Danny's "Mailet API sandbox" this is thought
as an experiment to create a strawman implementation to talk about later.
Great stuff guys, this approach certainly got the debate started about
the mailet api.
If I c
On 1/4/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Btw the vote included 3 options: should we consider your "+0" like an
"Any option is ok for me, I don't have a preference" ?
Almost... "any option you agree on is OK by me"
d.
--
On 1/4/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Hi Danny, unfortunately we started the issues together because they are
really tightly related.
That's fine, if that's what you already did then it is done. I know
how hard it can be, but sometimes you can just commit much more often
to ge
On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
So how to resolve this issue? How to come to a decision in this case?
What to do?
http://www.apache.org/foundation/voting.html
When a reasonable time has elapsed and more than three votes have been
cast the option with the most +1's and n
On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to sandbox/mailet-refactorings/. If
you want
On 1/5/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Danny Angus schrieb:
> On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>
>
>> The best way would be a native, logical, hierarchical mailbox access
>> through the Mailet API.
>
> If you would like t
On 1/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
Ha! Yes, We've discussed this before in relation to deployment of
m
On 1/6/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> sorting isn't good enough for me either: emails need to be tagged with
> meta-data on the server. meta-data can then used to present a folder
> based view to a client or for any ot
Norman,
I've updated the status file with the numbers of the binding votes, so
that it is clear what was decided.
On 1/8/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Mornin,
I think its time to close the VOTE as i started it at 18.12.06. So here we go..
1) Commit fixes and new "minor" features
A discussion on the Mailet-api list about annotations has started to
look at the possibility of requiring java 5 for James.
WDYT?
I would be cautiously in favour of this as long as no-one knows of any
real situations where 1.4 is the newest available version.
depending on whether this proposal
Hi,
I'm calling this vote here and not on general@ because it affects James server.
Because of interest in advancing the Mailet API and opinions already
expressed in this thread
(http://mail-archives.apache.org/mod_mbox/james-general/200610.mbox/[EMAIL
PROTECTED])
I would like to propose that t
On 1/8/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Do you propose to create a new JIRA project, too?
Oh yeah, makes sense to I think.
We could even make a standalone release from that release (so current
projects using mailet apis can already use that) and add it as a
dependency in james
On 1/8/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Does anyone know how many users was on Jdk 1.3 for outdated j2ee servers
1 year after java 5 has been released?
We were. I don't know of others.
d.
-
To unsubscribe, e-ma
On 1/8/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
What you are probably interested in is an example for the use case
"MailboxManager usage inside a Mailet". This can also be done in trunk.
Yes correct. :-)
-
To unsubscrib
On 1/9/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Should whole James only work with JCRs? Should usage of JCR be part of
the Mailet API?
IMO No, because we don't want to *require* any kind of sophisticated
storage. It may be impossible to avoid specifying a simple interface
or two, but the
On 1/9/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
Me too! Long term I would hope we can devolve the responsibility for
achieving many of these characteristics to standards based components such
as a JSR-170 based CR, leaving James to concentrate on mail technologies.
Just wanted to add my +1
On 1/10/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
+1.
I'd also think about moving our mailets into the mailet subproject,
and that could serve as your testing ground or at least samples. At
least the mailets that are not tied to James/Avalon APIs.
I thought about that, having a /contrib
Robert,
Can you sumarise the changes in a few words?
I suspect that this could go straight in the trunk if it isn't a
functional change.
d.
On 1/10/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
many moons ago i created
https://issues.apache.org/jira/browse/JAMES-575. this contains
impr
Better Cast my own vote ;-)
+1
On 1/8/07, Danny Angus <[EMAIL PROTECTED]> wrote:
Hi,
I'm calling this vote here and not on general@ because it affects James server.
Because of interest in advancing the Mailet API and opinions already
expressed in this thread
(http://mail-archives
On 1/13/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
i suspect that given good modularization, this choice could be made on
a per-component basis whilst the core remained lowest common
denominator JVM. james would then still run on older JVMs with small
changes to the configuration files
This vote has passed with 8 +1's and no -1s
I will be in touch to get opinions about the best way to break the code out.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1
On 1/17/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
With a new official release of this software in the making, I think we
should make an attempt to improve its representation over on
http://www.openspf.org/Implementations
---
+1
d.
On 1/17/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Hi,
i want to call this VOTE for releasing jSPF-0.9b4. We did some
refactoring and improvments. This release pass all current tests in the
last tagged version of the official spf testsuite:
http://www.openspf.org/source/project/test-s
On 1/17/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
+1.
ATM you have an inefficien
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think this is a step back from the current design or it simply regards
>> something we already trying to solve differently with the handlerapi.
>
> the current API design is flawed: this is just one way to fi
james is a collective work composed from those individual changes: it
is not collectively authored
there are good reasons why i would wish to deny authorship of anything
i did not personally create: authorship implies liability
But the point is that that liability should be delegated to the ASF
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
"hooks" in POP3
On 1/18/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
IMHO "handlerapi" should not be smtp specific: we use handler for every
protocol. Maybe someone doesn't share this view, but I thought this was
the main intent in calling "handler api". At least the pattern (if not
the code) can be (and IMHO
Lissette,
If you mean that you want to archive the messages which James sends
you just need to add a ToRepository mailet, like this
file://var/mail/archive/
true
On 1/19/07, lissette <[EMAIL PROTECTED]> wrote:
hello, I am new in this of James and want to
I think this only affects the trunk,
I also think it is a side-effect of a revision of Norman's which made
a change to use default domain.
I wonder whether the fix is to change the domain service, or to
*require* the missing config parameters.
Probably both.
d.
On 1/22/07, Guillermo Grandes (
thanks :-)
I think its actually a problem with the domain service's unconditional
"add" methods rather than your change, which just uncovered it.
On 1/22/07, Norman Maurer (JIRA) wrote:
I will take care...
-
To unsubscribe,
I tend to agree with Serge,
We really need to ensure that the overhead of a separate release cycle
is worth living with for the benefits it will bring.
I agree that there is the potential for some work to be done on this
mailet but I'm -0 to a separate sub-project.
However, it might be a good can
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Do I have your attention yet? :)
Yes :-)
I understand there are architectural thingies in James to consider and
phoenix and whatnot. I understand that there's a lot of time and
investment in the existing architecture. And I'm not sugges
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Unfortunately I think that hot redeployable mailets are far away,
the biggest issue is that you would have to move all "in process"
messages to a save point that you know will allow them to continue
after you have changed the whole processi
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> wrote:
I think your "James is a POJO chameleon" idea makes a lot of sense. If
we make it easy for 3rd parties to wrap James up, they'd do the heavy
lifting of packaging the code up for you and making it deployable to
their systems. Is there anything
On 2/2/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
While working on the fix I decided to publish the Security.setProperty
configuration as a system property so that the default behaviour of the
phoenix laucher jar is not changed
sounds sensible.
but we can tune the default value via
a sys
>> If this is not necessary I'm even happier: we'll have a better overview
>> once the new component is ready, so go ahead!
>
> +1
+1
On 2/1/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Ps: Im still alive :-P
Great news! ;-)
d.
--
On 2/3/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
opinions?
I like it.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I prefer maven2 for modular builds. Imho make things more clear.
Please, not this again, lets just stick with Ant.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Ehi Danny, I replied +1, didn't you see? ;-)
I saw, thats fine, I'm not criticising you, just making the point that
we could probably all do without re-running the Maven vs Ant debate,
and particularly not with adding it to this discussion.
I believe that the isoc / ietf are pretty relaxed about the use of
those documents in derivative works, they are copyright, and as such
we should attribute them. I would suggest that in the Class comment we
put "Extracts from rfc's (C) ISOC" or whomever. It may also be polite
to check this with th
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Where should we add documentation?
Good question, some where in
here:http://james.apache.org/server/2.3.0/index.html and possibly as
an FAQ.
I'll do this, perhaps you could raise a jira issue and assign it to me
so I don't forget.
d.
-
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Where should we add documentation?
Good question, some where in
here:http://james.apache.org/server/2.3.0/index.html and possibly as
an FAQ.
I'll do this, perhaps you could raise a jira issue and assign it to me
so I don't forget.
d.
-
Steve,
On 2/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
With these two issues resolved a simple script could be used to bring up the
new server with a new and already tested configuration, switch the IP
redirection to point to this server, then "drain and close" the old server.
If you could
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
in this case, it seems unreasonable to stop
serving corporate emails just so because some enterprise application
needs to reconfigure their mailets.
This is kind-of my point, you can re-deploy or reconfigure the
server's behaviour wit
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
but it might be solved by moving into the world of mail applications...
Yeah, but at some point there will have to be a "vendor specific"
container config, even if the bulk of the behaviour is in the std. app
config. For a long while n
Hi,
I've got two questions about moving Mailet into its own sub project,
as agreed in the VOTE.
1/ Should I move or copy the package?
I favour copy, followed by delete of the old one once dependance on
the new one is sorted-out.
2/ What svn technique is most appropriate (assume I'm pretty weak
On 2/6/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think you should use copy and then delete (like you allready said)..
That'd preserve the history would it?
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
Hi,
David Reid interviewed me about James for Feathercast a week or two ago.
You can download the podcast here: http://feathercast.org/?p=39
I've been involved now for over six years and this is a personal view
from the "back room" of what James is, and where I think we might be
going. It isn't
Don't wait is my 2c.
d.
On 2/7/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Mornin,
should we start the VOTE for "RC1" now and add the documentation about
the ttl issue later , or do the others prefer to wait ?
bye
Norman
Norman Maurer schrieb:
> Hi,
>
> i think we have all beside the ttl is
not really a lot of information there Stephen, have you looked at the
log files in
\apps\james\logs ?
Are you, in fact, using the correct username and password?
Have you tried "user" without "@localhost"?
d.
On 2/7/07, stephen boey <[EMAIL PROTECTED]> wrote:
Hi,
I am testing James on localhos
I just got this in the moderation queue, what the Sam Hill is it all
about? I figure it is spam, but what could the goal of the sender be?
If you think the headers might contain a clue I can let it through to the list.
-- Forwarded message --
From: [EMAIL PROTECTED]
<[EMAIL PROTE
I'll do it, when is the last date?
On 2/8/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Norman Maurer ha scritto:
>> put the same content:
>> * in the README
>> * in the config.xml
>> * in the RELEASE_NOTES
>> * in the download advertising
>> * in the announcement
>>
>> - robert
>
> It whould b
On 2/8/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Classic attempt to fool you into installing malware.
For a highly paid IT professional I can certainly be pretty bloody dumb, eh?!
d.
-
To unsubscribe, e-mail: [EMAIL PRO
+1 to http://www.apache.org/dist/james/jspf/beta/
not "unstable"
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 2/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Hi Danny, it was named "Products" after a discussion.
We also evaluated Sub Projects but we had agreement for "Products".
I remember that, but I'd forgotten.
As the guy who renamed the jakarta website links to "products" you'd
think I'd b
On 2/15/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Past that, it sounds like from past conversations that the deployment of
James as a Geronimo plugin might be made more worthwhile if we did the
refactoring to make multiple independent sub-systems out of what is
currently in James.
+1 I thi
On 2/15/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
---
We recommended that users of JAMES *products* subscribe to the JAMES
users mailing list.
---
Ok, my bad! I didn't think it through. :-(
d.
-
To unsubscribe, e-mail:
I will be there, presenting a session on James (surely not!?...) at
5:30 on the 2nd.
http://www.eu.apachecon.com/program/talk/5
While we're on the subject, I'd love to get input into the
presentation, anything you want me to cover or avoid let me know on
this list or privately at [EMAIL PROTECTE
Hi all,
Google Summer of Code '07 (http://code.google.com/soc/) will soon be
accepting applications from students.
If you have an idea for a student to work on as a James SoC project
send it to general@james.apache.org or post it on this wiki
http://wiki.apache.org/general/SummerOfCode2007
If y
I will be there from ~13:00
On 3/12/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
Hi,
I could make it for the Hackathon on May 1st. I'd be able to be there
from 12:00 till 18:00 local time.
Anyone else there for the H.?
Bernd
On 3/2/07, Søren Hilmer <[EMAIL PROTECTED]> wrote:
> Sorry, I ca
On 3/10/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Yes, I really like subant. Perhaps we can get back to using it, and
eliminate the Maven ... er ... "stuff" ... that has crept into JAMES.
+1
-
To unsubscribe, e-mail: [E
On 3/11/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
are in the directory org.apache.james. good enough?
Yes, until I get my a*** in gear and do the mailet move.
BTW Sorry that's late in coming, I've been up to here ^ with all kinds of stuff.
d.
-
I don;t know but.. I think it is because they were added later, and we
generally like to avoid changing the datamodel in ways which aren't
backwards compatible.
If we change the datamodel we should provide a migration script for
upgrades, need to either release db alter-table & update scripts or
On 3/13/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
but the main issue in this case is 1-1 relationships are tough for OR
mapping layers to optimize. torque frequently performs unnecessary
joins across to message_flags. ATM this results in tables scans which
may be possible to index awa
On 3/13/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
reinforces my view that JAMES should only parse data into a JavaMail
message when this is demanded by a processor
Totally.
and we do need to write our own implementation rather than use the
com.sun stuff which isn't really suited to
On 3/13/07, Danny Angus <[EMAIL PROTECTED]> wrote:
P.S. I'm happy to support a fully normalised data model, but I would
suggest that if we're going to do that we should make (document) a
logical model first. There are some de-normalisations which can also
reap benefits, such a
On 3/13/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
The Geronimo boys started that but aborted,
They started to recreate *all* of the API including the javax.mail stuff.
I think it would be more sensible to just write the content handlers,
assuming that this is where the performance issues
Noel,
I'm in favour of a JCA deployment option because it would let people
embed mail functionality in J2EE applications making it available to
systems assembled from J2EE components.
The big win this would have would be that administrators wouldn't have
to get right out of their comfort zone, t
On 3/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Maybe we can solve this once we move the mailet-api into its own
project. But this must be investigated while splitting/moving modules.
I hope I'll have some time to look at that, and review the
modularisation, this w/e.
I've been pretty f
On 3/23/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
(other than energy) what issues prevent the mailet-api being moved out
into a separate subproject?
Nothing.
Needs web pages, and a build, but nothing challenging technically.
d.
That's generous of you, feel free to wade right in there if you feel like it.
I hereby withdraw my right to moan if you don't do what I was
expecting, and replace it with a promise to pull my finger out :-)
d.
On 3/23/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 3/23
On 3/25/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> I prefer to have each jar with its own javadocs, and maybe we can unpack
> them all in a single package in the final distribution, but I don't know
> if this is easy to do.
i favour this as well but i'd like to see if there's a cons
James
> Issue Type: Task
>Affects Versions: 2.3.1-dev, Next Major
>Reporter: Stefano Bagnara
> Assigned To: Danny Angus
> Fix For: 2.3.1-dev
>
>
> Add documentation to the site and/or to the config.xml about the unbounded cache i
+0
Norman, I trust you!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Call for Papers Opens for ApacheCon US 2007
The Call for Papers is now open for ApacheCon US, to be held November
12-16 at the Peachtree Westin, Atlanta. The conference will consist
of two day of tutorials (November 12-13) and three days of regular
conference sessions (November 14-16).
Please lo
On 4/17/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
1. We tried to fetch emails via POP3 from a Exchange 2003 server which
Should it not just use
"127.0.0.1" and not try to parse it ?
Depends upon whether or not doing that would provide a "cloak" for
spam. I suppose you could.
2.
... That
On 4/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
will spooled mail survive a JVM crash?
will it be automatically processed next time james starts?
Just to add to what everyone else has said.. Yes. (we got that right
:-) the cost is that it may be processed twice through one or mo
On 4/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
what does it do?
compiles bytecode to native, the "rules" for what it compiles are more
complex for -server and it can be invoked well into a long run, not
just at the start. Those later optimisations are sometimes more buggy.
my
+1
Maybe that whould give us and danny's talk some
more attention.
Thank's for that thought.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 4/30/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
So who has made it? :-)
Robert and I are here. Danny, here yet?
Tomorrow mid-day-ish.
Anyone else? Perhaps we can all
get togeter for a live/virtual hack-a-thon tomorrow, EU time
+1 make it after lunch apachecon-time and I'll be th
If you are a flickr user join the apachecon group
http://www.flickr.com/groups/apachecon/ and post your photos.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert, I and Jukka have been having a grand ol' time
working on JAMES v3 (or 4:-p),
Please don't do anything that invalidates my talk until *after* I've
given it. ;-)
Looking forward to getting my teeth into it.
d.
-
To unsub
Woops, sorry Norman I *missed* the VOTE email, I wasn't being lazy,
just not paying enough attention!
d.
On 4/29/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Hi Guys,
its time to close the VOTE. So here we go:
Binding:
+1 Norman, Stefano, Vincenzo
+0 Søren
+1
Non-Binding:
+1 Sandeep
So we
On 4/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
And enjoy your talk! Will you publish something about the talk after the
talk?
Probably, depends whether or not it goes down well :-)
d.
-
To unsubscribe, e-mail: [EMAIL
+1
On 5/2/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Stefano Bagnara schrieb:
> Noel J. Bergman ha scritto:
>
>> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
>> work on a Proof of Concept related to the use of JCR as our unified data
>> store. The proof of concept
I prefer to
not require a full J2EE stack for running it. If we build upon JCR and
JMS we already provide lots of options for deployment. Btw it seems you
switch deployment options too fast ;-) .. yesterday (some months ago)
everyone was for OSGi... I don't read OSGi in this mail...
I don't thi
On 5/3/07, David Blevins <[EMAIL PROTECTED]> wrote:
Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to
use as "just a library" in various ways.
I hadn't really thought of that, I know Noel had mentioned OpenEJB,
but I couldn't figure out why, and I used it years ago so I sho
I would not neccessarily suggest to change a running
system. Mail infra is very critical to the ASF!
What's more James is better suited to complex processing than to
handling very large volumes. FWIW I heard that a few years ago Apache
sent 1,000,000+ mails per day.
James would need to be optimi
1 - 100 of 692 matches
Mail list logo