Thanks Serge - good luck with future direction.
Cheers, Steve.
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]
> Sent: 01 December 2004 04:02
> To: [EMAIL PROTECTED]
> Subject: Removed temp committer privs
>
> We voted back in January
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: 07 November 2004 18:38
> To: James-Dev Mailing List
> Subject: Migrate from CVS to SVN
>
> I propose that we migrate from CVS to Subversion ASAP (I should have
time
> to do it during ApacheCon next weekend).
> -Original Message-
> From: Roy Henderson [mailto:[EMAIL PROTECTED]
> Sent: 18 October 2004 18:52
> To: 'James Developers List'
> Subject: Container direction for James
>
> Hi,
>
> A recent question to the Avalon list resulted in a very clear "Phoenix
is
> no longer supported" response
Last run from gump generated the compilation error listed below. Before
I start digging into this does anyone have any immediate suggestions
(just for reference the build is working fine locally).
[x:javac]
/usr/local/gump/public/workspace/james-server/target/build/main/org/apac
he/james/secur
Just a heads up on some planned surgery of the MAIN build procedures.
Over the last week we have updated a lot of definitions in Gump
supporting Avalon projects and currently these are all building nicely.
We do have some dependency problems relating to Excalibur content and to
resolve this I'll
Theoretically speaking .. the next Gump run should be ok.
Steve.
> -Original Message-
> From: Gump Build Robot [mailto:[EMAIL PROTECTED]
> Sent: 18 August 2004 09:09
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: james-server/james-server failed
>
> To whom it may engage...
>
ASAIU a fork of the Phoenix codebase has been setup under the James CVS
(somewhere). Probably the best thing to do would be to add you patch as
a comment on the JIRA 307 report.
Cheers, Steve.
-Original Message-
From: Hes Siemelink [mailto:[EMAIL PROTECTED]
Sent: 16 August 2004 15:10
Can someone provide me with the details of the bouncycastle artifact
needed for this update? In the ibiblio maven repo there is
bouncycastle-jce-jdk13-112.jar - is that ok?
http://www.ibiblio.org/maven/bouncycastle/jars/
We will also need to setup update the gump deps.
Steve.
> -Origina
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 29, 2004 16:42
> To: Avalon Developers List; 'James Developers List'
> Subject: RE: Migration ... change for Thread Pool
>
> > Are you referring to the Excalibur Thread package?
>
> Only partia
> -Original Message-
> From: Alex Karasulu [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 29, 2004 16:03
> To: James Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Avalon - moving away from ?
>
> On Thu, 2004-07-29 at 09:27, Paul Hammant wrote:
> > This is an enabler, not migra
and James MAIN HEAD has been building and running against Avalon
releases successfully for more than a year including operation runtime
validation throughout that period.
Stephen.
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 29, 2004
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 29, 2004 06:50
> To: Stephen McConnell
> Cc: James-Dev Mailing List; [EMAIL PROTECTED]
> Subject: Migration ... change for Thread Pool
>
> Stephen,
>
> Do others have their own killer reasons right now?
I've got some killer reasons to get into some restructuring once James
is on svn. For example - breaking out James subsystems into discrete
units enabling:
* better management of unit tests
* improved separation of api and implementation
Jason Webb wrote:
Don't think so. What are the actual compile errors that come
up when you exclude cornerstone store impl?
Of all these errors (ignoring the warnings) the last error in the list
(SimpleConnectionManager) seems to be the strangest as there appears to be a
conflict between pack
In the build procedure for james there is a test to see if the jdk that
the build is running in contains java.sql.SavePoint. The presence of
this class causes the replacement of a token in the following file:
org/apache/james/util/mordred/PoolConnEntry.java
This means that the build result is
Stephen McConnell wrote:
[EMAIL PROTECTED] wrote:
I'm confused about the Cornerstone setup in 3.0. To get 3.0a1 to
compile (mostly) I need to add the following to the include.properties
file (and build.xml):
cornerstone-connection-impl.jar=${candidates.dir}/cornerstone-connection-impl-
[EMAIL PROTECTED] wrote:
I'm confused about the Cornerstone setup in 3.0.
To get 3.0a1 to compile (mostly) I need to add the following to the
include.properties file (and build.xml):
cornerstone-connection-impl.jar=${candidates.dir}/cornerstone-connection-impl-
1.0.jar
cornerstone-store-impl.jar
Serge Knystautas wrote:
Jason Webb wrote:
I've checked out HEAD (I think :)) to check something and it no longer
builds as it complains about various cornerstone problems.
You mean MAIN. :)
HEAD means the very end of a branch, compared to a datestamp or tag
checkout.
So - just to confirm - it wou
Jason Webb wrote:
I've checked out HEAD (I think :)) to check something and it no longer
builds as it complains about various cornerstone problems.
Are there newer Cornerstone libraries available, or do code changes need to
be made?
If they do I'm quite happy to make them, I just need to know
I'm s
Looks like we have a successful James build in gump.
http://brutus.apache.org/~gump/public/james-server/james-server/index.html
Cheers, Steve.
--
|---|
| Magic by Merlin |
| Production by Avalon |
|
Noel J. Bergman wrote:
For now I've simply copied ListUtils into james/util
ListUtils is also in Commons Collections. The same origin. Commons
Collections is in the 2.x branch, and I've no problem putting it into the v3
branch.
It's done - now using commons-collections ListUtils.
Steve.
--
|
Based on the last gump run (completed a few minutes ago) we are down to
three compilation errors. I already corrected one of these (commons
pool dependency) but I wanted to post a note concerning the remaining
two errors.
The two errors are due to the fact that I have not included
excalibur-c
Have just committed a few updates that james peeps may want to look
over. Changes include eliminate of dependency of excalibur.io and
updating of the code to remove references to long since deprecated
excalibur-thread interfaces. Just for reference - the gump running
periodic builds and provi
Noel J. Bergman wrote:
Caused by: java.lang.ClassNotFoundException:
org.apache.avalon.phoenix.tools.xdoclet.PhoenixXDoclet
Could someone please check if the jar file referenced
by /usr/local/gump/packages/phoenix-client.jar actually
contains org.apache.avalon.phoenix.tools.xdoclet.PhoenixXDoclet.
Adam R. B. Jack wrote:
Just before the error - ant is reporting that it is dropping a bunch of
phoenix references because the gump outputs are not found - and
logically as a consequence we hit the error concerning the class not
found.
Good point. Looks like two absolute paths are being concatenated
Gump Build Robot wrote:
-INFO- Failed with reason build failed
CLASSPATH :
/usr/local/gump/packages/phoenix-client.jar:
-
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(
I'm digging around in James HEAD looking at build procedures,
dependencies, gump, etc. etc. - trying to figure out how to set things
up so that they are nice and clean. I started to think "ok - we could
move this to there and that to here..." and then I remembered we are on
CVS not SVN.
Hence
Noel J. Bergman wrote:
Could whoever activated Gump for this project disable it? It seems that
James's build process is not compatible with Gump, or it was not setup
right.
No one did anything recently (which may be the problem). The reason we're
finally getting Gump notices is that the pre-requ
Steve Brewin wrote:
Stephen McConnell wrote:
Steve Brewin wrote:
As I understand it, different containers vary in their
depth of support for
the Avalon lifecycle. As I remember from way back, we could
dynamically
modify configurations if the container supported the requisite, but
optional
Steve Brewin wrote:
Danny Angus wrote:
My take on the container is that we it to just be there, support our
code,
be free of memory leaks and crashes, and otherwise stay out
of our way.
Agreed. And i don't normally pay it much attention, but with
people talking
about Merlin I wondered what your ide
Noel J. Bergman wrote:
OK guys, James 2.2.0 is released. That's it from me for probably the next
week or so. I have something next week that I really must focus on. After
that, I'll get onto the branch merger.
Conjectured Roadmap:
Release James X (2.3, 3.0, don't care) based upon
the merged
Noel J. Bergman wrote:
Get your hands on the latest versions..
We put significant milestones, and potential release
candidates in the download area.
Download area is a href to http://cvs.apache.org/dist/james/ which
has nothing in it.
Because the latest IS the 2.2.0 Release.
I figure that te
From index.html
Get your hands on the latest versions..
We put significant milestones, and potential release
candidates in the download area.
Download area is a href to http://cvs.apache.org/dist/james/ which has
nothing in it.
Cheers, Steve.
--
|---|
| M
[EMAIL PROTECTED] wrote:
Message:
The following issue has been resolved as WON'T FIX.
Resolver: Danny Angus
Date: Mon, 14 Jun 2004 8:54 AM
The Mailet API will never expose Avalon. Ever, period.
Dany - it seems to me that your confusing services with a component
model. Exposing a mech
Albert Kwong wrote:
Anyways, I have made some changes to JamesSpoolManager so that it can
load any avalon component implementing the Mailet interface as regular
mailets. If anyone is interested in the code, do let me know.
Yes - I'm interested.
Steve.
--
|---|
|
Noel J. Bergman wrote:
Stephen McConnell wrote (on jakarta commons):
Noel J. Bergman wrote:
And I would love to have James (both branch_2_1_fcs and MAIN)
building with GUMP.
One way to get a lot more value back from Gump for the James project
would be to separate build descriptions for the
Roy Henderson wrote:
.. managed to capture the earlier part of the build errors and it appears to
be failing due to a missing package javax.mail
Should this be provided as part of the James download or do I need to get
this from somewhere else? If so, where do I place it so it can be found
during t
The following Avalon release candidates have been posted to
http://www.apache.org/~mcconnell/candidates
* avalon-framework (api/impl)4.2
* avalon-logging 2.0
* excalibur-lifecycle (api/impl) 1.2
* excalibur-pool (api/impl) 2.0
* excalibur-thread (api/impl)2.0
Mauro Braggio wrote:
i found the error, missing the library
org.apache.avalon.cornerstone.services.connection.ConnectionManager
and all org.apache.avalon.cornerstone.services.*,
in my CVS build.
How can i get it?
http://www.apache.org/dist/avalon/cornerstone-connection-api/
http://www.apache.o
Noel J. Bergman wrote:
Marco,
Hi, of the jars at the following address:
http://www.apache.org/dist/java-repository/james/jars/
which ones I need in order to develop a custom mailet/matcher?
As I said to you earlier, we are not responsible for that packaging. My
guess is that Stephen
Noel J. Bergman wrote:
Noel J. Bergman wrote:
I am just getting ready to commit Steve Shorts JMX extensions.
To where? MAIN?
Well both MAIN and branch_2_1_fcs
Ah, that's cool. :-)
The patch removes the need to handcode the .mxinfo files by using the
Phoenix supplied doclet
Is this a build
Merlin 3.3 (a.k.a CVS HEAD) now includes:
* a plug-in logging implementation
* a default implementation supporting the
much requested rotating file strategies
* support for multiple logging factory
types and multiple targets
* improved category management
* complete separation of
The following is a text report of the wiring diagram generated by Merlin
when deploying the James Mail Server as a composite component.
It's kind of interesting to see the bigger picture.
Cheers, Stephen.
---
Application Model
--
Steve Brewin wrote:
Serge Knystautas wrote:
Steve Brewin wrote:
126 classes and 161 JUnit tests (tip of an iceberg) later I
have a server
neutral Java implementation of Sieve - RFC 3028. Now it
needs a home!
Nice! I suggest making it a separate CVS module, managed by
the James PMC.
You mean
Serge Knystautas wrote:
The last paragraph in the volano report conclusions:
"The good news is that Dan Kegel's C10K Problem has been solved in
Java 1.3, even when using the original blocking Java input and output
methods, and even when using modest hardware. The bad news is that the
Java ve
Steve Short wrote:
As far as JMX is concerned the root kernel is already MBean
enabled and is an active event generator (reflecting changes
to kernel state).
What still needs to be done is the exposure (via the kernel)
of the subsidiary applicance mbeans - but more internal event
structure
Alex Karasulu wrote:
Yes this is the next critical step. I think everyone at
Avalon would be in favor of this since it has surprisingly
become the basis for IoC in the J2EE container world.
Yes, I'm all for it as Noel says! Once the repo release is
complete is suspect this is the next priorit
Noel J. Bergman wrote:
Stephen J. McConnell wrote:
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new release will be a much cleaning
embedding strategy based on a bunch of improvements from Alex (Apache
Directory Project).
If
Noel J. Bergman wrote:
The Monitor service would be exposed via JMX (automatically
thanks to Phoenix and hopefully Merlin).
The monitor service configuration would allow declaration of
groups and act as a factory for other components that wish
to be monitored.
My suggestion would be
Steve Short wrote:
I can do it using JMX calls but if Stephen
McConnell is reading - please treat this as a feature request for
Merlin's JMX implemtation.
I'm reading ;-)
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new
Noel J. Bergman wrote:
While on the subject of direction, what do we want to do before cutting the
next major release?
- Do we want to take the current code as-is?
- Do we want to take the current code + latest Avalon,
which means pulling in Component->Service changes?
+1 (please)
Steve.
Soeren Hilmer wrote:
Well I believe that Merlin is a must (IMO Phoenix is dying), but apart
from
that JBoss etc. is not that interesting. Geronimo might be interesting
when
it sees the light (is Geronimo Merlin based?)
Geronimo is not Merlin based.
Geronimo is a J2EE container whereas Merli
Steven Harris wrote:
First time poster (so bare with me). If or when we move this thing
from phoenix to merlin doesn't merlin have jmx integration already?
Only partially.
Today - only the kernel is fully JMX manageble. A MBean is defined for
appliance instances (the component scenario ma
Noel J. Bergman wrote:
Nitpick: JMS is a J2EE technology, not an EJB technology. I have no
experience using JMS, but it seems overkill for many purposes. I've always
had a fondness for the COS Event Service, myself.
Umm, blush - me too!
Stephen.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED
Noel:
I'm cc'ing Avalon dev. Perhaps we can try to get some assistance
on this - after all, the upside is certainly interesting.
Stephen.
Noel J. Bergman wrote:
Stephen McConnell wrote:
Noel J. Bergman wrote:
But something I'm still not clear on. Under a unit test
Danny Angus wrote:
Steve,
echoing Serge..
2. enhanced configuration error handling
No repeated stack trace dumps, and tying an error to the line number
(and column!) in the configuration file.
This has been a thron in our side for a while, it would be nice to have
meaningful and concise erro
Noel J. Bergman wrote:
Harvesting user requirements concerning Avalon containment:
1. enhanced logging management
2. enhanced configuration error handling
3. remotely accessible services (e.g. via JNDI)
JMX.
JMX support at the kernel level is already in place, support for
internal manag
Serge Knystautas wrote:
Steve,
As long as you're harvesting, just to clarify these... :)
Stephen McConnell wrote:
Harvesting user requirements concerning Avalon containment:
1. enhanced logging management
It seems you have very flexible logging configuration right now, but
Danny Angus wrote:
Serge Knystautas wrote:
I'm still waiting for the Avalon containers to
stabilize basic server features like friendly configuration errors,
logging management, stuff like that, and am looking forward to the new
releases we'll get with 3.0.
Me too.
Harvesting user requirements
Steve Short wrote:
Thanks - this worked first time - very cool!
LOL - I should hope so!!
Steve.
Steve
-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 1:34 PM
To: James Developers List
Subject: Re: Merlin Config Files for
Steve Short wrote:
Stephen McConnell,
I wanted to start using some James components in new and interesting
ways and I was thinking of using Merlin as the container for this to
reduce the amount of configuration (read assembly.xml and
environment.xml) I needed to do. I've found a number o
Danny Angus wrote:
Danny contributed the Mailet API changes. Stephen did the Avalon changes.
Other than that, I think I committed most of the changes to MAIN. And I
kept them in since until sometime this summer, IIRC. I don't know of any
features present in MAIN that are not in v2.
I f
Noel J. Bergman wrote:
But something I'm still not clear on. Under a unit test
the BSF mailet would be declared under the James
configuration.
I was just using those matchers as examples. For testing, I think you want
to have similar code available within Merlin, itself, able to access
wha
Noel J. Bergman wrote:
Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
Thanks - penny has dropped
Noel J. Bergman wrote:
Excalibur IO is depricated in favour of Commons IO. However, the
cornerstone-store package used a number of IO utilities not available
within the commons-io package
So we need commons-io,
No - you don't need commons-io (I just mentioned that Excalibur IO
was depric
Noel J. Bergman wrote:
2. Do an api/impl split (which will make me happy)
Where do you see that we don't?
[warning - I'm probably rambling]
I'm talking about a physical split that would result in the following
artifacts:
* james-server-api-VERSION.jar
* james-server-impl-VERSION.jar
*
Noel J. Bergman wrote:
As for formal testing, we still don't have much. Bench and live testing,
basically. For example, when I get home, I'll test Soren's patch by setting
up a schedule, and sending mail to a dead gateway. I don't know what Avalon
has done in terms of facilitating component t
Serge Knystautas wrote:
I think that will be messy since there has been so much changes on
each, but I don't have a better suggestion. grunt grunt grunt.
This really could expose our Archiles heel though, which is a lack of
adequate testing to make sure the merged version works well. Have w
Noel J. Bergman wrote:
Everything from Avalon on which James is dependent has gone though an
official release.
Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
there is a release later than we are using.
Woops!
Honestly - it just didn't occur to me.
Possibly Freudi
Danny Angus wrote:
2. Discuss and resolve the mailet API changes.
I propose we abandon many of the changes made to the HEAD, and adopt only
those changes made to the branch as well.
The repository access and database access is likely to be superceded by
JNDI.
I propose that we keep whatever
Serge Knystautas wrote:
Noel J. Bergman wrote:
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get
merged,
I think it makes sense for Stephen to add configuration files for a
James
package using Merlin as well as our
Noel J. Bergman wrote:
Amusingly enough, I was just asking Dion that question last night. I do
suggest that we make the effort to merge the branches before we re-do the
build process, at this point.
+1000
--- Noel
-
To unsub
Serge Knystautas wrote:
Any opinions on migrating to doing builds using maven? I have only
cursory experience with it, but it's been generally positive, and it
helps address the javamail.jar and activation.jar issues.
Maven will not help you with the javamail.jar and activation.jar issues
The problem you are seeing is generated by the container you are using.
I.e. it isn't a James issue.
Stephen.
Kenny Smith wrote:
Hi all,
I'm trying to get a new installation of 2.2-dev working and I'm
running into this error:
org.apache.excalibur.containerkit.lifecycle.LifecycleException:
Com
Noel J. Bergman wrote:
The level of exposure of these classes to client code is a function of
the container support for isolation. If your running James in Phoneix
then these classes will be exposed. If you running under Merlin then
they will be isolated to the implementing container. For examp
Noel J. Bergman wrote:
Commons-collection is a dependent jar from the cornerstone threads
component (actually the dep traces back to the latest excalibur-threads
release).
OK. And apparently no issues with those classes being exposed to client
code. At one point, I had thought that there
Noel J. Bergman wrote:
Stephen,
Why is Commons Collections in the candidates directory? Should that be one
level up in lib/?
Commons-collection is a dependent jar from the cornerstone threads
component (actually the dep traces back to the latest excalibur-threads
release).
Steve.
--- Noel
Noel J. Bergman wrote:
Its working now.
Thanks. :-) But why did you remove the junit checks?
According to me its checked into cvs.
I.e. no remote downloading required.
Steve.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PRO
Its working now.
Steve.
Noel J. Bergman wrote:
I was trying to build the main branch today, and ran into these errors:
Resource: mail-1.3.1.jar
Recovery:
Get the mail-1.3.1 jar from the mail-1.3.1 distribution at
http://java.sun.com/products/javamail/
and place
Noel J. Bergman wrote:
I was trying to build the main branch today, and ran into these errors:
Resource: mail-1.3.1.jar
Recovery:
Get the mail-1.3.1 jar from the mail-1.3.1 distribution at
http://java.sun.com/products/javamail/
and place it in /home/noel/ASF/
Alexis Agahi wrote:
On Tuesday 07 October 2003 19:08, Noel J. Bergman wrote:
Steve,
Merlin doesn't have support for JMX and one of the goals on the
James roadmap is to improve monitoring / management via JMX.
Quite correct. However, today James does use better logging than Merli
David Liles wrote:
For a couple days now I have been trying to configure JBuilder to run the Ant script with James (2.1.3) but have not been successful.
I am wanting to be able to do this so I can develop locally. are there any other developers who are doing this? If not, how are people dev
Noel J. Bergman wrote:
Steve,
Merlin doesn't have support for JMX and one of the goals on the
James roadmap is to improve monitoring / management via JMX.
Quite correct. However, today James does use better logging than Merlin
supports, and does not use JMX. Today. So the logging is
Steve Short wrote:
Merlin is fine, although not quite where James can use it yet
as a standard platform. The primary issue, AFAIK, is
Merlin's logging support, and Steve is working to fix it.
Also Merlin doesn't have support for JMX and one of the goals on the
James roadmap is to impr
Noel J. Bergman wrote:
I know we can rotate on size, but what would be the easiest way to keep
just
the above sort of size limited log? Is there a suitable log
implementation
already provided?
The way I deal with this is to create child loggers to seperate out
thes
Stephen McConnell wrote:
Noel J. Bergman wrote:
Stephen McConnell wrote:
Noel J. Bergman wrote:
While on this topic ... James is a Mailet container. We have a
single log channel for all Mailet log messages. However, James
might want to change the priority so that a particular
Noel J. Bergman wrote:
Stephen McConnell wrote:
Noel J. Bergman wrote:
While on this topic ... James is a Mailet container. We have a
single log channel for all Mailet log messages. However, James
might want to change the priority so that a particular mailet uses
DEBUG priority
Noel J. Bergman wrote:
The real problem is that the names used to report missing .jars are
hard-coded rather than being the properties containing the names of
the actual .jars used.
Please submit a patch to fix this properly. :-)
It's done!
Thanks, Steve. :-) Were there o
Steve Brewin wrote:
Stephen McConnell wrote:
It's done!
I've updated the check-targets.properties to reference and report the
correct mail jar name and tied the default.properties
reference to use
the check-targets.properties values.
Steve.
And being picky, how about the
Noel J. Bergman wrote:
The real problem is that the names used to report missing .jars are
hard-coded rather than being the properties containing the names of
the actual .jars used. They are bound to get out of sync. unless
someone remembers that they need updating.
Please submit a patch to
Noel J. Bergman wrote:
It would be nice to get to a position where patches are not
applied against non-development branches (i.e. only accept
patches against HEAD).
The point is that we had two development branches. One based
upon the current stable API, and the other with some
experim
merlin website. Its totally generated via
a maven based build. Site updating and distribution building is now almost
trivial (ie. around 5 mins for a totally new site and distribution
archive).
Cheers, Steve.
--- Noel
-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
I'm currently running an instance of James based on CVS HEAD. Looking
at some of the recent comments on the dev and user lists it appears that
updates are being applied to 2.1/2.2 and that HEAD is now not really
HEAD at all. Should I be dropping 3.0a1 in favour of 2.2 (which I'm not
too keen
Noel J. Bergman wrote:
The cornerstone suite of components were released a couple of days ago.
James CVS is already updated. A vote on the release plan for Merlin is
also underway.
Stephen, unless Merlin has been updated so that it supports our
configuration as-is, I don't think we want to
Serge:
The cornerstone suite of components were released a couple of days ago.
James CVS is already updated. A vote on the release plan for Merlin is
also underway.
Steve.
Serge Knystautas wrote:
Vincenzo Gianferrari Pini wrote:
P.S. I committed both branch_2_1_fcs and HEAD; comparing the
Serge Knystautas wrote:
Danny Angus wrote:
I'd like to propose that Jason Webb be made a commiter on this
(James server) project.
Get the ball rolling with my..
+1
Who started this thread? I didn't remember seeing it and can't find
it in eyebrowse.
http://marc.theaimsgroup.com/?t=106
Danny Angus wrote:
Have recently changed a bunch of things related to DNS, MX records, and
the configuration and location of my local james installation. In this
process I've managed to establish an error condition and on
investigation I've located a possible bug in the LocalDelivery mailet
(Ja
Have recently changed a bunch of things related to DNS, MX records, and
the configuration and location of my local james installation. In this
process I've managed to establish an error condition and on
investigation I've located a possible bug in the LocalDelivery mailet
(James HEAD).
In Loc
Noel J. Bergman wrote:
So I did some digging .
.. and in the James source for RepositoryManager I noticed the following:
We inherited that code from Cornerstone when we were told that in order to
fix bugs in the Cornerstone code, we needed to take that into our module so
that PeterD cou
Noel J. Bergman wrote:
As I understand it from your previous notes, Merlin is primarily short in
the area of log configuration?
It's the reverse - well almost. The reverse would suggest that Merlin
is long in the area of short configurations which doesn't really man
anything to me.
Huh? Steph
1 - 100 of 107 matches
Mail list logo
