date:20030127

Hi Guys,

Continuing on with my BounceHandler mailet idea, I would need to do
something like this in my configuration block for my mailet

   
   


   
   
   
   .
   <>...
   
   
   

However the mailet API does not give me access to this sort of thing and I
have not figured out if I can gain access directly to the James
Configuration object from my Mailet. I think not.

As a temporary work around I could do something like this:

   

class=DSNBounce;class=QmailBounce;class=etc

name=DBBounceProcessor;database=..
   

But this is not very elegent and idealy I would at the very minimum need to
pass additional config parameters to the bounceProcessors.

Anyone have any ideas, suggestions?

Thanks,
Sergei



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Mailet Configuration

2003-01-27 Thread Aaron Knauf

Hi Serge,

This subject has come up a few times.  I suggested an approach to 
handling mailet and matcher config better, as did a few others.  I even 
offered to write it.  However, due to the distinct lack of enthusiasm 
for my (or any other) solution, I lost interest.  I could be convinced 
to revisit this if some of the committers indicated that they were 
interested.

Cheers

ADK

Serge Sozonoff wrote:

Hi Guys,

Continuing on with my BounceHandler mailet idea, I would need to do
something like this in my configuration block for my mailet

  
  
   
   
  
  
  
  .
  <>...
  
  
  

However the mailet API does not give me access to this sort of thing and I
have not figured out if I can gain access directly to the James
Configuration object from my Mailet. I think not.

As a temporary work around I could do something like this:

  

class=DSNBounce;class=QmailBounce;class=etc

name=DBBounceProcessor;database=..
  

But this is not very elegent and idealy I would at the very minimum need to
pass additional config parameters to the bounceProcessors.

Anyone have any ideas, suggestions?

Thanks,
Sergei



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

Serge

My 2c..

1/ *don't* access James for config, that is officially discouraged, and Not Supported, 
it may well not be possible in the next release.
2/ use the nastylooking hack for now, we can improve mailet/matcher config if its 
wanted, or use config files for your mailets I see no reason why that shouldn't be 
acceptable.
3/ tell us what you want from the config. look at the mailet plans wiki page.

Why can't you split this all up into seperate mailet/matchers in their own linear 
processor? :


bounceprocessor








Without knowing what your doing its hard to say exactly what the answer should be.

d.

> -Original Message-
> From: Serge Sozonoff [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 10:17
> To: James Developers List
> Subject: Mailet Configuration
> 
> 
> Hi Guys,
> 
> Continuing on with my BounceHandler mailet idea, I would need to do
> something like this in my configuration block for my mailet
> 
>
>
> 
> 
>
>
>
>.
><>...
>
>
>
> 
> However the mailet API does not give me access to this sort of thing and I
> have not figured out if I can gain access directly to the James
> Configuration object from my Mailet. I think not.
> 
> As a temporary work around I could do something like this:
> 
>
> 
> class=DSNBounce;class=QmailBounce;class=etc eHandlers>
> 
> name=DBBounceProcessor;database=.. ocessors>
>
> 
> But this is not very elegent and idealy I would at the very 
> minimum need to
> pass additional config parameters to the bounceProcessors.
> 
> Anyone have any ideas, suggestions?
> 
> Thanks,
> Sergei
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/proposals/imap2/test/org/apache/james/test AbstractProtocolTest.java

2003-01-27 Thread darrell

darrell 2003/01/27 03:30:54

  Modified:proposals/imap2/test/org/apache/james/imapserver
ImapHostTest.java
   proposals/imap2/test/org/apache/james/test
AbstractProtocolTest.java
  Log:
  Imap2 proposal: synch with changes in main CVS tree
  
  Revision  ChangesPath
  1.5   +2 -2  
jakarta-james/proposals/imap2/test/org/apache/james/imapserver/ImapHostTest.java
  
  Index: ImapHostTest.java
  ===
  RCS file: 
/home/cvs/jakarta-james/proposals/imap2/test/org/apache/james/imapserver/ImapHostTest.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ImapHostTest.java 4 Dec 2002 06:06:45 -   1.4
  +++ ImapHostTest.java 27 Jan 2003 11:30:54 -  1.5
  @@ -10,8 +10,8 @@
   import org.apache.james.imapserver.store.ImapMailbox;
   import org.apache.james.imapserver.store.InMemoryStore;
   import org.apache.james.imapserver.store.MailboxException;
  -import org.apache.james.services.User;
   import org.apache.james.userrepository.DefaultUser;
  +import org.apache.mailet.User;
   
   import junit.framework.TestCase;
   
  
  
  
  1.5   +2 -2  
jakarta-james/proposals/imap2/test/org/apache/james/test/AbstractProtocolTest.java
  
  Index: AbstractProtocolTest.java
  ===
  RCS file: 
/home/cvs/jakarta-james/proposals/imap2/test/org/apache/james/test/AbstractProtocolTest.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- AbstractProtocolTest.java 3 Dec 2002 14:00:14 -   1.4
  +++ AbstractProtocolTest.java 27 Jan 2003 11:30:54 -  1.5
  @@ -8,10 +8,10 @@
   import org.apache.james.imapserver.ImapTest;
   import org.apache.james.imapserver.JamesImapHost;
   import org.apache.james.imapserver.store.MailboxException;
  -import org.apache.james.services.User;
  -import org.apache.james.services.UsersRepository;
   import org.apache.james.userrepository.AbstractUsersRepository;
   import org.apache.james.userrepository.DefaultUser;
  +import org.apache.mailet.User;
  +import org.apache.mailet.UsersRepository;
   
   import junit.framework.TestCase;
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

Aaron,

You wrote:

> This subject has come up a few times.  I suggested an approach to 
> handling mailet and matcher config better, as did a few others.  I even 
> offered to write it.  However, due to the distinct lack of enthusiasm 
> for my (or any other) solution, I lost interest.  I could be convinced 
> to revisit this if some of the committers indicated that they were 
> interested.

Without checking I think that the perceived lack of interest was due to a deferal of 
these issues to v3.
Now that v3 is proceding go ahead with it, I'm indicating that I'm interested and will 
support your contribution.
Check the wiki for others' opinions on this (and other) v3 topics, and post your 
ideas, or code, here for discussion & inclusion.

AFAICR we reached some concensus on the following style.. which would allow us to 
produce a processor DTD (example attached) and standardise every mailet config.
I can't remember what other suggestions/arguments were raised, but you could check the 
mail archive.

...

...

d.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/src/xdocs/stylesheets site.xsl

2003-01-27 Thread danny

danny   2003/01/27 03:49:59

  Modified:src/xdocs/stylesheets site.xsl
  Log:
  Meta tags seem to have helped us, adding the word "Free" to see what happens. :-)
  
  Revision  ChangesPath
  1.4   +3 -3  jakarta-james/src/xdocs/stylesheets/site.xsl
  
  Index: site.xsl
  ===
  RCS file: /home/cvs/jakarta-james/src/xdocs/stylesheets/site.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- site.xsl  27 Jan 2003 08:32:41 -  1.3
  +++ site.xsl  27 Jan 2003 11:49:58 -  1.4
  @@ -60,8 +60,8 @@
 
 
   
  -
  -
  +
  +
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/proposals/imap2/conf james-config.xml

2003-01-27 Thread darrell

darrell 2003/01/27 05:03:10

  Modified:proposals/imap2 build.xml
   proposals/imap2/conf james-config.xml
  Log:
  Imap2 Proposal:
  Build and config fixes to synch with main tree.
  
  Revision  ChangesPath
  1.5   +4 -4  jakarta-james/proposals/imap2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-james/proposals/imap2/build.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- build.xml 8 Jan 2003 06:05:46 -   1.4
  +++ build.xml 27 Jan 2003 13:03:10 -  1.5
  @@ -28,8 +28,8 @@
   
   
   
  -
  -
  +
  +
   
   
  @@ -406,7 +406,7 @@
   
   
   
  -
  +
   
   
   
  
  
  
  1.2   +18 -8 jakarta-james/proposals/imap2/conf/james-config.xml
  
  Index: james-config.xml
  ===
  RCS file: /home/cvs/jakarta-james/proposals/imap2/conf/james-config.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- james-config.xml  22 Nov 2002 02:09:50 -  1.1
  +++ james-config.xml  27 Jan 2003 13:03:10 -  1.2
  @@ -302,16 +302,23 @@
  
  
  
  +   
  +   
  +   
  +   
  +   
  +   
  
  
  
  
  
 
  -
  -
  -
  - 127.0.0.1
  + 
  + 
  + 
 
 false
  
  @@ -382,7 +389,7 @@
   
  
 
  -  
  +  
 110
   
 
  @@ -452,6 +459,9 @@
   
   
  
  +   
 
 
 119
  @@ -706,7 +716,7 @@
  
  
 
  - 
  + 
   
  file
   
  @@ -720,7 +730,7 @@
   

   
  - 
  + 
   
  file
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: config.xml and imap2 proposal

2003-01-27 Thread Darrell DeBoer

On Mon, 27 Jan 2003 14:11, Darrell DeBoer wrote:
> On Mon, 27 Jan 2003 12:33, Kenny Smith wrote:
> > Does anyone have info on what I need to add to my config.xml to use the
> > imap2 proposal?
> >
> > Kenny
>
> Hi Kenny.
>
> From memory, you just need to use the "dist" target from the
> proposals/imap2/build.xml build file. This overwrites the main
> james-config.xml with an imap-specific one. However, there may have been
> divergent changes in the main tree, I'm not sure.

Hi Kenny,

I've made some fixes so that the proposal will build and start - needed to 
synch for changes in the dns-server component.

You should now be able to build James with the imap2 proposal, and startup 
successfully. That's all I've tested so far, but you could then try 
connecting with an email client.

I've put some *very* brief notes on the wiki. Maybe there should be a link 
from james.apache.org to the James wiki pages?

-- 
ciao,
Daz

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Mailet Configuration

Hi Danny,

1/ *don't* access James for config, that is officially discouraged, and Not
Supported, it may well not be possible in the next release

So, basically it is up to my mailets to manage "fancy" configuration for
themselves?
I guess (as you suggested) I can write my own config file and use Avalon
Configuration to deal with it.
Moving forward we are going to have to take a stance here and either offer a
configuration service to mailets or not because as it stands now we are
offering IMO an incomplete solution.
I know that there has been some talk on this issue before, I will have to
revisit the messages now that I am getting more familiar with things.

2. OK

> Why can't you split this all up into seperate mailet/matchers in their own
linear processor? :

On the 22.01 I wrote an email to the dev list discussing my idea and I did
mention that I had thought (maybe not enough) about using the seperate
mailet/matcher aproach, I was kinda hoping for some feedback Re. that mail
:-)

Maybe I can use the mailet/matcher aproach, I had orginally broken down the
process into three things.
Match -> Parse -> Process.

Match would basically indicate if this message is a bounce of type X and can
be parsed by the related parser (Their is a tight relationship between match
and parse)

Parse would parse the message to try and extract the necessary info (Bounce
Type, Status Code, Original recipient etc ) and create a new instace of
a Bounce object housing this data.

Process would act on the data it recived from the parser. Anyone should be
able to plug in their own processor and do what they like with the data.
eg. Update a DB.
Process would need to receive an instance of Object Bounce from the parse
operation containing the data.

For the moment I have not found a clean way to satisfy these requirements
with the standard mailet/matcher approach.

> Without knowing what your doing its hard to say exactly what the answer
should be.
I tried to describe the process here
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg06017.html

Thanks,
Sergei


- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 12:12 PM
Subject: RE: Mailet Configuration


Serge

My 2c..

1/ *don't* access James for config, that is officially discouraged, and Not
Supported, it may well not be possible in the next release.
2/ use the nastylooking hack for now, we can improve mailet/matcher config
if its wanted, or use config files for your mailets I see no reason why that
shouldn't be acceptable.
3/ tell us what you want from the config. look at the mailet plans wiki
page.

Why can't you split this all up into seperate mailet/matchers in their own
linear processor? :


bounceprocessor








Without knowing what your doing its hard to say exactly what the answer
should be.

d.

> -Original Message-
> From: Serge Sozonoff [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 10:17
> To: James Developers List
> Subject: Mailet Configuration
>
>
> Hi Guys,
>
> Continuing on with my BounceHandler mailet idea, I would need to do
> something like this in my configuration block for my mailet
>
>
>
> 
> 
>
>
>
>.
><>...
>
>
>
>
> However the mailet API does not give me access to this sort of thing and I
> have not figured out if I can gain access directly to the James
> Configuration object from my Mailet. I think not.
>
> As a temporary work around I could do something like this:
>
>
>
> class=DSNBounce;class=QmailBounce;class=etc eHandlers>
>
> name=DBBounceProcessor;database=.. ocessors>
>
>
> But this is not very elegent and idealy I would at the very
> minimum need to
> pass additional config parameters to the bounceProcessors.
>
> Anyone have any ideas, suggestions?
>
> Thanks,
> Sergei
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Mailet Configuration

Hi again Danny,

2/  or use config files for your mailets I see no reason why that
shouldn't be acceptable.

This would be fine as well, although in this case I would expect the
MailetContext to give me a base path so that I could use relative paths to
load my own Mailet config files. I should be able to specify a path relative
to /apps/james or something.

Thoughts?

Thanks, Serge




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

> > Without knowing what your doing its hard to say exactly what the answer
> should be.
> I tried to describe the process here
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg06017.html

Thx Sergei, I know you did, but I didn't follow it very closely.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

Ok, I just re-read your original.

My opinion is now that you either do use mailets or you don't.
Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.

What I'd also say is why not try to use a mailet approach. 
I say this because we're trying to get the mailet API enhanced to support more 
sophisticated behaviour, and you have a test case of more sophisticated behaviour.

What we're about to offer, that is relevant, is

a) Mail properties. Matchers and mailets will be able to set and get serializable 
persistent properties on Mail objects they handle. This allows mailets to work 
step-wise with Mail exhibiting state.

b) Matcher parameters, enhanced matcher config provided by elevating match from 
attribute to element in the config.

c) Matcher chains, initially AND (only no OR) matcher chains will pass the mail 
through the configured matchers and only mail which passes all matchers will reach the 
mailet. 

d) Configurable processor classes. Its my desire, now that the Mailet contract so 
closely resembles the Processor contract, to see processors added to the API, so that 
developers can add new processors other than the standard LinearProcessor. This will 
allow people to support FIFO pipelines, or forking pipelines and other more 
sophisticated or specialised pipelines.

I hope that this covers all of your requirements, I believe that it does. :-)

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

Are you developing against the 2.1 branch or the Head?

I think we should be able to add an attribute to mailet context in the HEAD to allow 
this.
Hopefully this will let you continue work while we implement better mailet config, and 
you can roll your config back into configuration.xml when its ready.

d.

> -Original Message-
> From: Serge Sozonoff [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 14:05
> To: James Developers List
> Subject: Re: Mailet Configuration
> 
> 
> Hi again Danny,
> 
> 2/  or use config files for your mailets I see no reason why that
> shouldn't be acceptable.
> 
> This would be fine as well, although in this case I would expect the
> MailetContext to give me a base path so that I could use relative paths to
> load my own Mailet config files. I should be able to specify a 
> path relative
> to /apps/james or something.
> 
> Thoughts?
> 
> Thanks, Serge
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Mailet Configuration

Hi Danny,

Currently I am coding against Head.

Thanks, Sergei

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 3:28 PM
Subject: RE: Mailet Configuration


Are you developing against the 2.1 branch or the Head?

I think we should be able to add an attribute to mailet context in the HEAD
to allow this.
Hopefully this will let you continue work while we implement better mailet
config, and you can roll your config back into configuration.xml when its
ready.

d.

> -Original Message-
> From: Serge Sozonoff [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 14:05
> To: James Developers List
> Subject: Re: Mailet Configuration
>
>
> Hi again Danny,
>
> 2/  or use config files for your mailets I see no reason why that
> shouldn't be acceptable.
>
> This would be fine as well, although in this case I would expect the
> MailetContext to give me a base path so that I could use relative paths to
> load my own Mailet config files. I should be able to specify a
> path relative
> to /apps/james or something.
>
> Thoughts?
>
> Thanks, Serge
>
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Mailet Configuration

Hi Danny,

This all sounds very good!
Since am almost 70% done with my implementation including a handler for DSN
style bounce messages and an Example DBProcessor.
I would suggest that I complete an initial prototype (Non mailet/matcher
approach) including rolling my own config and then I submit my code
somewhere for others to review. (This should help back some requirements
with a concrete example)

One reason for this is that I guess it will still be a little while before
the new Mailet API is usable. As the new Mailet API starts to develop we can
start migrating my code to the new mailet/matcher API with the enhanced
features and maybe discover some other requirements.

Other points:

1. Did we come to a conclusion on how to handle DB connections in Mailets?
Is the mailet responsable, is the MailetContext going to provide for this or
is it optional based on the MailetContext implementation?

Thanks,
Sergei

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 3:25 PM
Subject: RE: Mailet Configuration


Ok, I just re-read your original.

My opinion is now that you either do use mailets or you don't.
Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.

What I'd also say is why not try to use a mailet approach.
I say this because we're trying to get the mailet API enhanced to support
more sophisticated behaviour, and you have a test case of more sophisticated
behaviour.

What we're about to offer, that is relevant, is

a) Mail properties. Matchers and mailets will be able to set and get
serializable persistent properties on Mail objects they handle. This allows
mailets to work step-wise with Mail exhibiting state.

b) Matcher parameters, enhanced matcher config provided by elevating match
from attribute to element in the config.

c) Matcher chains, initially AND (only no OR) matcher chains will pass the
mail through the configured matchers and only mail which passes all matchers
will reach the mailet.

d) Configurable processor classes. Its my desire, now that the Mailet
contract so closely resembles the Processor contract, to see processors
added to the API, so that developers can add new processors other than the
standard LinearProcessor. This will allow people to support FIFO pipelines,
or forking pipelines and other more sophisticated or specialised pipelines.

I hope that this covers all of your requirements, I believe that it does.
:-)

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/src/java/org/apache/james James.java

2003-01-27 Thread danny

danny   2003/01/27 07:22:13

  Modified:src/java/org/apache/james James.java
  Log:
  Added attribute confDir to the MailetContext as a temporary measure to allow Sergei 
Sozonoff to continue work on bounce processors without waiting for pending changes in 
mailet configuration
  
  Revision  ChangesPath
  1.44  +4 -2  jakarta-james/src/java/org/apache/james/James.java
  
  Index: James.java
  ===
  RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/James.java,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- James.java14 Jan 2003 13:58:20 -  1.43
  +++ James.java27 Jan 2003 15:22:12 -  1.44
  @@ -46,6 +46,7 @@
   import org.apache.avalon.framework.context.DefaultContext;
   import org.apache.avalon.framework.logger.AbstractLogEnabled;
   import org.apache.avalon.framework.logger.Logger;
  +import org.apache.avalon.phoenix.BlockContext;
   import org.apache.james.core.MailHeaders;
   import org.apache.james.core.MailImpl;
   import org.apache.james.services.DNSServer;
  @@ -371,7 +372,8 @@
   
   //TODO NOT unless specifically required by conf
   attributes.put(Constants.AVALON_COMPONENT_MANAGER, compMgr);
  -
  +//Temporary get out to allow complex mailet config files to stop blocking 
sergei sozonoff's work on bouce processing
  +attributes.put("confDir", 
((BlockContext)myContext).getBaseDirectory().getCanonicalPath()+"/conf/");
   System.out.println(SOFTWARE_NAME_VERSION);
   getLogger().info("JAMES ...init end");
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration

Sergei,

> This all sounds very good!
> Since am almost 70% done with my implementation including a 
> handler for DSN
> style bounce messages and an Example DBProcessor.
> I would suggest that I complete an initial prototype (Non mailet/matcher
> approach) including rolling my own config and then I submit my code
> somewhere for others to review. (This should help back some requirements
> with a concrete example)

Yes, very good I agree. I have *just now* commited a revised James.java which provides 
an attribute "confDir" this attribute is a string path to ~james/appas/james/conf to 
allow you to pick up config files from there.

I *haven't* tested it, excpet that it does compile.
It should work, because it is exactly the same as the method used to get a path for 
the mailet/matcher classloaders, which do work.

 
> One reason for this is that I guess it will still be a little while before
> the new Mailet API is usable. As the new Mailet API starts to 
> develop we can
> start migrating my code to the new mailet/matcher API with the enhanced
> features and maybe discover some other requirements.

Yep.

> 1. Did we come to a conclusion on how to handle DB connections in Mailets?
> Is the mailet responsable, is the MailetContext going to provide 
> for this or
> is it optional based on the MailetContext implementation?

The general feeling seemed to be that the the mailets should be responsible, at least 
for now.
I suspect we may end up with "hasDBProvider()" and "getDBProvider()" so that DB 
provision is optional but allowed for containers.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [PATCH] imap2 proposal - refactored to current structure

2003-01-27 Thread Kenny Smith

Hi Noel,

> Is it OK with you if we put off this merger until you finish up,
> and get it running?  Is anyone waiting for this code?

No one, afaik, is waiting for the code, but I figured it would be good to
bring the proposal in CVS up to date with the main source tree. I had a
couple of different reasons, but probably the most important one to me is
the ability to revert. If I start working on the source tree and realize
that I've just totally screwed it up, then I can ditch my code and check out
of CVS again.

> > I haven't been able to test if these work because I don't know how to
> > configure config.xml to use the imap proposal
>
> Look at proposals/imap2/conf/* for the configuration files.
> You'll want to, again, update them by taking the current files from HEAD
> and updating the IMAP bits.  Then you should be able to run some basic
> tests, tweak any other bits that need tweaking, and we can merge this back
> into the CVS.

Ah, excellent. Sorry I missed that. Will do!

> And would you please take a moment to update the IMAP2 build
> instructions at
> http://nagoya.apache.org/wiki/apachewiki.cgi?JamesIMAP when you
> can, please?
> :-)

I can, but I don't know what instructions need to be updated. I used the
instructions posted there to do my builds and apart from the minor
refactoring it worked just fine. :)

Kenny Smith
JournalScape.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [PATCH] imap2 proposal - refactored to current structure

2003-01-27 Thread Kenny Smith

> I've applied your patches - thanks heaps! Saved me chasing down
> all of those changes in main tree.

Yay! :)


> For future reference, could you please create patches using:
> cvs diff -u run from the root of the cvs tree, with no filename
> specified. This creates a single diff file which is easier for
> me to apply. If you've only made changes to the proposal, or
> only want to send a patch for that directory, you could run the
> above command from within the proposals directory.

oo... that sounds a _lot_ easier than what I did. :) Will do!

> I noticed that the source files in the "test" directory haven't
> been patched, and won't compile. Maybe you want to fix those
> while you're at it? Use the ant build file "build-test.xml" and
> the "compile" target to test it out. Once that's done, you
> should be able to run all of the unit tests, using the
> "unit-tests" target.

You bet. I've finished all my other projects currently so my lunch time at
work this week will go toward that. :)

Kenny Smith
JournalScape.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Excalibur/Cornerstone/James woes

Stephen McConnell wrote:

I now have two james builds locally on my machine:

 1.  James based on Peter's derivative of 2.1, CM/SM
 migration and Cornerstone candidates in place.
 This is working fine.  Some problems were occuring
 in the test case but we finally narrowed this down
 to a bug in the test case (the test delete's the user
 before the spool completes its work, resulting in
 email in the spool that contain invalid reciipient
 addresses).

 2.  James based on HEAD + CM/SM migration + updates for
 Cornerstone candidates.  This version is doing the
 500 error on "" commands and getting itself into a
 loop.  However, it's fully synced with the HEAD and
 can be committed.

I suggest we go ahead and ties build (2) into head and sort of the 
loop/500 problem from there.

Sounds great... this loop bug is one I introduced in HEAD and mean to 
sort out soon (was supposed to this weekend, but long story... it will 
be fixed soon).

There is also the question of migration of excalibur-xxx packages to 
commons-.  This has been taken care of for the pool package 
(commons-collection).  There may be a coupe of other packages that 
require transition.  Also, excalibur-cli (used in Phoenix and a couple 
of Excalibur projects) can/should/could be replaced by commons-cli.

I would support migrating to commons libs as I'm more familiar with them 
and I think commons does a good job with release management.  Especially 
if it means the Avalon community has less to worry about releasing in 
the short-term.

Also, for DBCP we'll be bundling commons pool anyway, so one step there.

i.e. Things are already looking comfortable - and within a few weeks we 
should be able to freeze the release targets and validate things across 
containers, applications and external projects followed by formal 
vote/release/publication.

Great!


Yep - its in progress. Some of the updated in Excalibur are used 
extensively in Cocoon and some of guys on working on the Avalon/Cocoon 
front in much the same we as I'm trying to get James/Avalon in sync.

Sounds good.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Build process: was http://james.apache.org

Danny Angus wrote:

I'd like to see a formal proposal, so we can have a synopsis of why we need to change things, debate the benefits and drawbacks of competing systems are, and, if we don't reach concensus, a vote.

I'm susceptable to persuasion on all counts, including retaining the status-quo (ant & xslt) and would like to hear someone make the case for change. Otherwise it would seem to be change for change's sake, or keeping up with the Joneses.

This is somewhat perpendicular to this, but could have an impact...

The tests we have right now (they don't compile, but that
notwithstanding) are functional tests, not unit tests.

So last night I created a new directory and build tasks for junit tests
on the individual classes in James. This was primarily driven by
wanting to unit test ExtraDotOutputStream, and we can use this test
build task for over unit tests as they get written.

Adding this prompted me to do some renaming in the build.xml since
between the multiple javadocs, multiple source code locations, etc...,
the naming conventions were becoming somewhat confusing. For example,
the intermediate build directories are named "build.[something]" while
the source directories are named "[something].dir".

Anyway, I'm pretty sure I've broken where the javadocs get created, but
if we're going to just scrap all of that, then maybe it's not important
for me to fix it before I commit.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com

--
To unsubscribe, e-mail:
For additional commands, e-mail:

[VOTE] Stephen McConnell temporary commit privilege

I'd like to propose that we offer Stephen temporary commit access to James to let him 
apply his *very welcome* update to James to bring the HEAD up to date with Avalon.

d.






--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Build process: was http://james.apache.org

> Anyway, I'm pretty sure I've broken where the javadocs get created, but 
> if we're going to just scrap all of that, then maybe it's not important 
> for me to fix it before I commit.

Its pretty important for the web-site though.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Build process: was http://james.apache.org

Danny Angus wrote:

Anyway, I'm pretty sure I've broken where the javadocs get created, but 
if we're going to just scrap all of that, then maybe it's not important 
for me to fix it before I commit.


Its pretty important for the web-site though.

Ok, I can sort that out before committing.  Just didn't think we'd be 
updating the website with HEAD before we moved to Forrest or whatever 
the decision is.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [VOTE] Stephen McConnell temporary commit privilege

Danny Angus wrote:

I'd like to propose that we offer Stephen temporary commit access to James to let him apply his *very welcome* update to James to bring the HEAD up to date with Avalon.

d.


+1, although would like to have "temporary" defined... until a specified 
date (couple of weeks?, 3 months?), until a milestone is reached (ACR?, 
James 3.0?), or whatever.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Release Builds and Mirroring

[From infrastructure mailing list]

Those of us who are doing the Release builds and mirroring work should pay
attention to Justin Erenkrantz's comment about what to do with old releases.
In case it isn't me at some point, I thought it worth noting, since
infrastructure@ isn't archived.

--- Noel

Justin Erenkrantz wrote:
> Stefano Mazzocchi  wrote:
> > those are not minor releases. Those are "releases", a release is
> > something that you might build your stuff upon. It's a contract.
> > Books, for example, use these contracts for years (before a new
> > edition outdates another one, but that edition can still be used)

> Correct.  If you look at our new mirroring guidelines
> (http://www.apache.org/dev/mirrors.html), we're attempting to
> advocate keeping releases in a stable place forever.  For example,
> cocoon 2.0.4 source should always be available at:
> http://www.apache.org/dist/xml/cocoon/source/cocoon-2.0.4-src.tar.gz



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

TLP announcement

We've sent around a TLP announcement to every place mentioned on the 
listserv (leading up to the 2.1 PR), including...

Cnet
ZDNet
ServerWatch
JavaWorld
SLASHDOT
IBM Devworks
TechTV.com
Onjava.com
OfB.biz
Apache
Java DevJournal
Open Directory
TheServerSide
JSPInsider
JSPIN
JavaLobby
JGuru.com
JavaRanch
Open Enterprise
eBizQ

We've got all the info on where to send the news for each, so when we do 
the 2.1.1 release and want to blast that out, we can handle that as well.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [VOTE] Stephen McConnell temporary commit privilege

+1 to give Stephen commit access to James to help get up to date with
Avalon.  I'd suggest that he have such rights at least for this current
update, and preferably until we are integrated with the actual ACR (Avalon
Coordinated Release).

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [VOTE] Stephen McConnell temporary commit privilege

IMO until he tells us his work is done or v3 whichever is sooner. 
Of course his work *will* be done by v3 by definition, so its all a bit moot.
But I agree that we should have some indivisible cut off date.

d.

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 18:05
> To: James Developers List
> Subject: Re: [VOTE] Stephen McConnell temporary commit privilege
> 
> 
> Danny Angus wrote:
> > I'd like to propose that we offer Stephen temporary commit 
> access to James to let him apply his *very welcome* update to 
> James to bring the HEAD up to date with Avalon.
> > 
> > d.
> 
> +1, although would like to have "temporary" defined... until a specified 
> date (couple of weeks?, 3 months?), until a milestone is reached (ACR?, 
> James 3.0?), or whatever.
> 
> -- 
> Serge Knystautas
> Lokitech
> Software - Strategy - Design
> http://www.lokitech.com
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [PATCH] imap2 proposal - refactored to current structure

> No one, afaik, is waiting for the code, but I figured it would be good to
> bring the proposal in CVS up to date with the main source tree.

No worries.  Darrell knows the imap2 code well, and already took care of the
merger.  :-)  He even finished some of the other things that I figured you'd
encounter before the updates were really completed, and updated the wiki a
bit.

Thanks Darrell!  :-)

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

BlockContext introduces Phoenix dependency

Danny,

  +//Temporary get out to allow complex mailet config files to stop
blocking sergei sozonoff's work on bouce processing
  +attributes.put("confDir",
((BlockContext)myContext).getBaseDirectory().getCanonicalPath()+"/conf/");

This introduces a problem.  BlockContext is Phoenix dependent.  We should
find out from Stephen if there is a portable way to accomplish the same
goal.  I believe that I have code from Peter that removes BlockContext for
the mailet class loader code.  I'll look and see.  I should have time to
start looking at his contributions (tons of new features and enhancements),
and James v3.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Build process: was http://james.apache.org

> Anyway, I'm pretty sure I've broken where the javadocs get created, but
> if we're going to just scrap all of that, then maybe it's not important
> for me to fix it before I commit.

Until we see a/the better way working, I'm not in favor of scrapping
anything.  :-)  If/when Maven were to become the better way, we'd end up
"scrapping" the entirety of build.xml, as I understand it.

Apparently, one of the benefits of using Maven is that a minimum
installation is just Maven and our project file.  The user runs Maven, which
downloads and installs all of the requisite files from the repository,
including the necessary builds of third party jar files.

Other benefits include a whole set of canned project reports.  But I'd
rather let Dion and Jason promote Maven, and let Nicola promote Forrest.
:-)  That way we will all learn more about these non-exclusive options.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: TLP announcement

Excellent.

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 19:29
> To: [EMAIL PROTECTED]
> Subject: TLP announcement
> 
> 
> We've sent around a TLP announcement to every place mentioned on the 
> listserv (leading up to the 2.1 PR), including...
> 
> Cnet
> ZDNet
> ServerWatch
> JavaWorld
> SLASHDOT
> IBM Devworks
> TechTV.com
> Onjava.com
> OfB.biz
> Apache
> Java DevJournal
> Open Directory
> TheServerSide
> JSPInsider
> JSPIN
> JavaLobby
> JGuru.com
> JavaRanch
> Open Enterprise
> eBizQ
> 
> We've got all the info on where to send the news for each, so when we do 
> the 2.1.1 release and want to blast that out, we can handle that as well.
> 
> -- 
> Serge Knystautas
> Lokitech
> Software - Strategy - Design
> http://www.lokitech.com
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: BlockContext introduces Phoenix dependency

In which case we need to find another way to get the path to apps/james, its going to 
be essential if we're going to manage to have packaged mailet apps.

d.

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: 27 January 2003 20:11
> To: James Developers List
> Subject: BlockContext introduces Phoenix dependency
> 
> 
> Danny,
> 
>   +//Temporary get out to allow complex mailet config 
> files to stop
> blocking sergei sozonoff's work on bouce processing
>   +attributes.put("confDir",
> ((BlockContext)myContext).getBaseDirectory().getCanonicalPath()+"/conf/");
> 
> This introduces a problem.  BlockContext is Phoenix dependent.  We should
> find out from Stephen if there is a portable way to accomplish the same
> goal.  I believe that I have code from Peter that removes BlockContext for
> the mailet class loader code.  I'll look and see.  I should have time to
> start looking at his contributions (tons of new features and 
> enhancements),
> and James v3.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Build process: was http://james.apache.org

> Apparently, one of the benefits of using Maven is that a minimum
> installation is just Maven and our project file.  The user runs 
> Maven, which
> downloads and installs all of the requisite files from the repository,
> including the necessary builds of third party jar files.

What is it you say Noel? ROTFLMAO! We can do that with Avalon? that is magic.

 That was just kiddin' I know lots of people are working very hard on the 
avalon/james version issues.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Build process: was http://james.apache.org

> > Apparently, one of the benefits of using Maven is that a minimum
> > installation is just Maven and our project file.  The user runs
> > Maven, which downloads and installs all of the requisite files
> > from the repository, including the necessary builds of third
> > party jar files.
> What is it you say Noel? ROTFLMAO! We can do that with Avalon? that is
magic.

Well, yes.  It would be if the Avalon folks had actually done a Release, or
otherwise provided a coordinated set of jars.  Dion could take our Jars and
rename them something like filename-james-v2.1.jar, but that's a bit silly.
I'd just as soon see Avalon do their job, and put out the ACR.  And this is
one of those perfect examples for why there IS such a thing as Avalon.  We
don't want piecemeal releases of technology bits.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Build process: was http://james.apache.org


I do recall a "shoot-out" between Maven and Forrest for the web site, and we
seemed to prefer Forrest.  In discussions with Dion, he noted that Maven's
primary benefit was process and build related, and that we could seamlessly
use Forrest with Maven, getting what appeared to be the best of both worlds.

Dion has been working on a project file for James so that we can see the
benefits of Maven.  As Danny says on our list (which is where this should be
discussed), we'd like to hear more about our build and web publishing
options so that we can make the informed selection.

For example, if we have james-site, james-mailet and james-server, and we
want james-site to be populated with HTML generated from javadocs in
james-mailet and james-server, is Maven able to handle such a thing?  Is
Forrest?

Unlike Jakarta, our sub-projects are related.  Is Maven's report generator
capable of giving us integrated reports across our sub-projects, or is it
only capable of separate reports?  We will have dependencies such that
james-mailet will produce one or more jar files that james-server depends
upon.  Will Maven handle that?  How?

Right now, everytime I generate the build, every javadoc page is regenerated
for publication, even though the javadoc hasn't changed.  Will Maven clean
up that idiotic process?  Will Forrest?

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Build process: was http://james.apache.org]

2003-01-27 Thread Jason van Zyl

On Mon, 2003-01-27 at 17:46, Noel J. Bergman wrote:
> I do recall a "shoot-out" between Maven and Forrest for the web site, and we
> seemed to prefer Forrest.  In discussions with Dion, he noted that Maven's
> primary benefit was process and build related, and that we could seamlessly
> use Forrest with Maven, getting what appeared to be the best of both worlds.

What I was going to point out was that you have a maven POM and the
reports generated from the POM alone are very useful. You'll be
duplicating HTML docs for:

- mailing lists
- project team
- dependencies
- sources repository and instructions for retrieval
- issue tracking
- changelogs
- developer activity
- file activity
- tasklists (taken from @todo in javadocs)

> Dion has been working on a project file for James so that we can see the
> benefits of Maven.  As Danny says on our list (which is where this should be
> discussed), we'd like to hear more about our build and web publishing
> options so that we can make the informed selection.

Well you quite a bit from Maven with simply the POM. You do nothing.
Even if you have zero content aside from the POM people can find the
sources with basic instructions. All what I've listed above for free.
All you have to do is install Maven and with your POM you get loads of
useful info for your users.

And plugins are being added to Maven at pretty quick and you can now
control the reports you want presented on your site from the POM itself.
So again all you do is select the reports you want by editing the POM
and you get what you want.

> For example, if we have james-site, james-mailet and james-server, and we
> want james-site to be populated with HTML generated from javadocs in
> james-mailet and james-server, is Maven able to handle such a thing?  Is
> Forrest?

Sure, there is a vdoclet plugin that I use for passing over the source
of a project to find the @todos. I also use it to create JMX code. You
would add something like:

And then it could be later transformed and pushed onto your site. You
can do whatever you like with with vdoclet and your sources.

> Unlike Jakarta, our sub-projects are related.  Is Maven's report generator
> capable of giving us integrated reports across our sub-projects, or is it
> only capable of separate reports?  

The sample commmons reactor build I made 6 months ago built each of the
commons components, generated the docs for them and then aggregated them
together in what you see here:

http://www.apache.org/~jvanzyl/jakarta-commons/

I also use it to produce docs for the Plexus components. The reactor
walks over each of projects performing the specified task, in this case
generating site docs, and then gives you a list of processed projects
that you can subsequently process in any desired fashion.

So for example, you could walk over all your james-mailets, process the
docs for them and then generate a front-end site with links to all the
individual james-mailets by extracting information from each of the POMs
processed by the reactor. Same process used to make the commons site
above.

> We will have dependencies such that
> james-mailet will produce one or more jar files that james-server depends
> upon.  Will Maven handle that?  How?

For this we can group your mailets under the james 'groupId' and each
mailet would have an artifactId. Then for james itself you can declare
dependencies on each of these mailets. Not a problem. Maven's build
itself uses this when one plugin depends on another.

> Right now, everytime I generate the build, every javadoc page is regenerated
> for publication, even though the javadoc hasn't changed.  Will Maven clean
> up that idiotic process?  Will Forrest?

I'm sure both could fix that with a check. There is a tool in
CruiseControl which checks the timestamps on a set of files. It uses it
to detect whether or not to update the source repository before doing
another build. I'm sure that tool could be snagged and employed for
documentation as well.

> 
>   --- Noel
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: TLP announcement

So are you saying that you don't want me to send out the Press Release?  You
want me to just post it to you?

I have a somewhat longer list than below, with either e-mail addresses or
URLs.  I'll post it to pmc@ (I don't feel like contributing to spam
harvesters).

--- Noel

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 14:29
To: [EMAIL PROTECTED]
Subject: TLP announcement


We've sent around a TLP announcement to every place mentioned on the
listserv (leading up to the 2.1 PR), including...

Cnet
ZDNet
ServerWatch
JavaWorld
SLASHDOT
IBM Devworks
TechTV.com
Onjava.com
OfB.biz
Apache
Java DevJournal
Open Directory
TheServerSide
JSPInsider
JSPIN
JavaLobby
JGuru.com
JavaRanch
Open Enterprise
eBizQ

We've got all the info on where to send the news for each, so when we do
the 2.1.1 release and want to blast that out, we can handle that as well.

--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: BlockContext introduces Phoenix dependency

2003-01-27 Thread Stephen McConnell



Noel J. Bergman wrote:


Danny,

 +//Temporary get out to allow complex mailet config files to stop
blocking sergei sozonoff's work on bouce processing
 +attributes.put("confDir",
((BlockContext)myContext).getBaseDirectory().getCanonicalPath()+"/conf/");

This introduces a problem.  BlockContext is Phoenix dependent.  We should
find out from Stephen if there is a portable way to accomplish the same
goal.  I believe that I have code from Peter that removes BlockContext for
the mailet class loader code.  I'll look and see.  I should have time to
start looking at his contributions (tons of new features and enhancements),
and James v3.



It would probably be a best to do the following:

 1. Create: james/util/AvalonConstants.java

  public static final String URN_HOME_DIR = "app.home";

 2. Then update the source

  String path =
((File)context.get(  URN_HOME_DIR  ) ).getCanonicalPath() 
+"/conf/";

Once a standard URN is defined under the framework (or container work) 
we will be able to synchronize containers.  The "app.home" key works in 
both Merlin and Phoenix.  Merlin also supports "urn:avalon:home" - but 
its not Avalon official.

Cheers, Steve.


	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/src/xdocs index.xml

2003-01-27 Thread noel

noel2003/01/27 17:55:00

  Modified:src/xdocs index.xml
  Log:
  Updated for TLP (site was changed without commit)
  
  Revision  ChangesPath
  1.26  +3 -1  jakarta-james/src/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-james/src/xdocs/index.xml,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- index.xml 17 Jan 2003 05:48:00 -  1.25
  +++ index.xml 28 Jan 2003 01:54:59 -  1.26
  @@ -15,7 +15,9 @@
   James is based upon the Apache Avalon application framework. (For more 
information about Avalon, please go to http://jakarta.apache.org/avalon";>http://jakarta.apache.org/avalon)
   James requires Java 2 (either JRE 1.3 or 1.4 as of 2.0a3). 
   
  -Find out how to use James with sendmailWe've added a HOW TO document 
explaining how to configure sendmail to route all mail through James, read it Here.
  +James Comes Of AgeWe're proud to announce that Jakarta James has 
been promoted from being a Jakarta sub-project to Apache James, a top-level project of 
the Apache Software Foundation (ASF).  James now has its own Project Management 
Committee, and reports directly to the http://www.apache.org/foundation";>ASF.
  +We also have a brand new domain name: http://james.apache.org and are in 
the process of moving our infrastructure over to the new domain, so please forgive any 
confusion that might occur.
  +At this time we would especially appreciate hearing about broken links or out 
of date references on this site.
   
   
   Latest and Stable: james-2.1
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/src/xdocs/stylesheets project.xml

2003-01-27 Thread noel

noel2003/01/27 17:55:49

  Modified:src/xdocs/stylesheets project.xml
  Log:
  Added Wiki link
  
  Revision  ChangesPath
  1.22  +1 -0  jakarta-james/src/xdocs/stylesheets/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-james/src/xdocs/stylesheets/project.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- project.xml   27 Jan 2003 08:32:41 -  1.21
  +++ project.xml   28 Jan 2003 01:55:48 -  1.22
  @@ -10,6 +10,7 @@
   
   
   http://jakarta.apache.org/site/mail.html"/>
  +http://nagoya.apache.org/wiki/apachewiki.cgi?James"/>
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-james/www FAQ.html adding_users_2_1.html announcement_2_1.html architecture_v2_0.html build_instructions_2_1.html changelog.html code-standards.html configuration_v2_0.html contribute.html custom_mailet_2_1.html custom_matcher_2_1.html document_archive.html documentation_2_1.html fetchpop_configuration_2_1.html index.html install.html installation_instructions_2_1.html james_and_sendmail.html license.html mailet_api_2_1.html mailing_lists_2_1.html nntp_configuration_2_1.html pop3_configuration_2_1.html provided_mailets_2_1.html provided_matchers_2_1.html remotemanager_configuration_2_1.html repositories_2_1.html rfclist.html serverwide_configuration_2_1.html smtp_auth_2_1.html smtp_configuration_2_1.html spoolmanager_2_1.html spoolmanager_configuration_2_1.html summary_2_1.html todo.html usingJDBC_v2.0.html usingLDAP_v1_2.html usingTLS_2_1.html usingTLS_v1_2.html using_database_2_1.html weare.html

2003-01-27 Thread noel

noel2003/01/27 17:58:44

  Modified:www  FAQ.html adding_users_2_1.html
announcement_2_1.html architecture_v2_0.html
build_instructions_2_1.html changelog.html
code-standards.html configuration_v2_0.html
contribute.html custom_mailet_2_1.html
custom_matcher_2_1.html document_archive.html
documentation_2_1.html
fetchpop_configuration_2_1.html index.html
install.html installation_instructions_2_1.html
james_and_sendmail.html license.html
mailet_api_2_1.html mailing_lists_2_1.html
nntp_configuration_2_1.html
pop3_configuration_2_1.html
provided_mailets_2_1.html
provided_matchers_2_1.html
remotemanager_configuration_2_1.html
repositories_2_1.html rfclist.html
serverwide_configuration_2_1.html
smtp_auth_2_1.html smtp_configuration_2_1.html
spoolmanager_2_1.html
spoolmanager_configuration_2_1.html
summary_2_1.html todo.html usingJDBC_v2.0.html
usingLDAP_v1_2.html usingTLS_2_1.html
usingTLS_v1_2.html using_database_2_1.html
weare.html
  Log:
  Added Wiki link
  
  Revision  ChangesPath
  1.22  +5 -2  jakarta-james/www/FAQ.html
  
  Index: FAQ.html
  ===
  RCS file: /home/cvs/jakarta-james/www/FAQ.html,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- FAQ.html  23 Jan 2003 13:09:11 -  1.21
  +++ FAQ.html  28 Jan 2003 01:58:40 -  1.22
  @@ -4,8 +4,8 @@
   Apache James - Frequently Asked Questions - Java Mail and News server, SMTP 
POP3 NNTP
   
   
  -
  -
  +
  +
   
   
   
  @@ -38,6 +38,9 @@
   
   
   http://jakarta.apache.org/site/mail.html";>Mailing Lists
  +
  +
  +http://nagoya.apache.org/wiki/apachewiki.cgi?James";>Wiki
   
   
   
  
  
  
  1.3   +5 -2  jakarta-james/www/adding_users_2_1.html
  
  Index: adding_users_2_1.html
  ===
  RCS file: /home/cvs/jakarta-james/www/adding_users_2_1.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- adding_users_2_1.html 23 Jan 2003 13:09:10 -  1.2
  +++ adding_users_2_1.html 28 Jan 2003 01:58:41 -  1.3
  @@ -2,8 +2,8 @@
   
   
   Apache James - James 2.1 - Adding Users - Java Mail and News server, SMTP 
POP3 NNTP
  -
  -
  +
  +
   
   
   
  @@ -36,6 +36,9 @@
   
   
   http://jakarta.apache.org/site/mail.html";>Mailing Lists
  +
  +
  +http://nagoya.apache.org/wiki/apachewiki.cgi?James";>Wiki
   
   
   
  
  
  
  1.3   +5 -2  jakarta-james/www/announcement_2_1.html
  
  Index: announcement_2_1.html
  ===
  RCS file: /home/cvs/jakarta-james/www/announcement_2_1.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- announcement_2_1.html 23 Jan 2003 13:09:10 -  1.2
  +++ announcement_2_1.html 28 Jan 2003 01:58:41 -  1.3
  @@ -2,8 +2,8 @@
   
   
   Apache James - James 2.1 - Release Announcement - Java Mail and News server, 
SMTP POP3 NNTP
  -
  -
  +
  +
   
   
   
  @@ -36,6 +36,9 @@
   
   
   http://jakarta.apache.org/site/mail.html";>Mailing Lists
  +
  +
  +http://nagoya.apache.org/wiki/apachewiki.cgi?James";>Wiki
   
   
   
  
  
  
  1.13  +5 -2  jakarta-james/www/architecture_v2_0.html
  
  Index: architecture_v2_0.html
  ===
  RCS file: /home/cvs/jakarta-james/www/architecture_v2_0.html,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- architecture_v2_0.html23 Jan 2003 13:09:10 -  1.12
  +++ architecture_v2_0.html28 Jan 2003 01:58:41 -  1.13
  @@ -4,8 +4,8 @@
   Apache James - Notes for developers - Java Mail and News server, SMTP POP3 
NNTP
   
   
  -
  -
  +
  +
   
   
   
  @@ -38,6 +38,9 @@
   
   
   http://jakarta.apache.org/site/mail.html";>Mailing Lists
  +
  +
  +http://nagoya.apache.org/wiki/apachewiki.cgi?James";>Wiki
   
   
   
  
  
  
  1.3   +5 -2  jakarta-james/www/build_instructions_2_1.html
  
  Index: build_instructions_2_1.html
  ===
  RCS file: /home/cvs/jakarta-james/www/build_instructions_2_1.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build_instructions_2_1.html   23 Jan 2003 13:09:10 -  1.2
  +++ build_inst

RE: BlockContext introduces Phoenix dependency

Stephen,

>  1. Create: james/util/AvalonConstants.java
>  2. Then update the source

You might want to take a look at:
http://cvs.apache.org/viewcvs.cgi/jakarta-james/src/java/org/apache/james/co
ntext/AvalonContextUtilities.java

> Once a standard URN is defined under the framework (or container work)
> we will be able to synchronize containers.

Understood.  I'm starting to lean towards a URI (of which a URN is a subset)
for things, but it depends upon one's needs.

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: BlockContext introduces Phoenix dependency

> In which case we need to find another way to get the
> path to apps/james, its going to be essential if we're
> going to manage to have packaged mailet apps.

You mean like o.a.j.context.AvalonContextUtilities? :-)

See:
http://james.apache.org/javadocs/org/apache/james/context/AvalonContextUtili
ties.html

--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: BlockContext introduces Phoenix dependency

2003-01-27 Thread Stephen McConnell


Exactly!

:-)


Noel J. Bergman wrote:


In which case we need to find another way to get the
path to apps/james, its going to be essential if we're
going to manage to have packaged mailet apps.
   


You mean like o.a.j.context.AvalonContextUtilities? :-)

See:
http://james.apache.org/javadocs/org/apache/james/context/AvalonContextUtili
ties.html

	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: Mailet Configuration