RE: FW: [important proposal] Cocoon as official Apache project

[alan.gerhard]

> James would be a fine top level project.  And it is really
> very independent of anything else, except for the hidden
> dependence upon Avalon. 
> --- Noel

which can be crippling at times. 
in going top-level, it must be very clear that all
dependencies are either removed or explicitly spelled out
with attention dedicated to ensuring those relationships are
whole.

without a clear distinction, james will always be a
subproject.

alan
--
   This EMail Was brought to you by
   WebMail
A Netwin Web Based EMail Client
  http://netwinsite.com/webmail/tag.htm

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

RE: FW: [important proposal] Cocoon as official Apache project

[Noel J. Bergman]

> we've got the server, the mailet API, and a collection
> of mailets all as possible subprojects.  Or maybe
> multiple mailet packages... some standard ones, then
> others that are more like stand-alone apps.

James would be a fine top level project.  And it is really very independent
of anything else, except for the hidden dependence upon Avalon.

--- Noel


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

Re: FW: [important proposal] Cocoon as official Apache project

[Serge Knystautas]

Yeah, I saw this and thought about James... we've got the server, the 
mailet API, and a collection of mailets all as possible subprojects.  Or 
maybe multiple mailet packages... some standard ones, then others that 
are more like stand-alone apps.

--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com

Danny Angus wrote:
If this mail gets through.. (its going via a server being load tested!)

I thought those not on the community/reorg lists might like to read this because Stefano outlines quite well at least one view of the top-level-project issues.

d.



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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> You did.  :-)  My question was about soliciting documentation 
> contributions.

solicit away.

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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > Would you mind if a message went out on James-User [asking]
> > them for contributions towards the [user] documentation?

> That should wait until we have a release plan

OK

> (I thought I did announce the build, if not feel free to repeat it)

You did.  :-)  My question was about soliciting documentation contributions.

--- Noel


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> Thank you.  Would you mind if a message went out on James-User
> telling folks
> that we're working towards a new Release Build, and asking them for
> contributions towards the documentation?  They could contribute
> actual bits
> of documentation, or just questions that they are having trouble with.

That should wait until we have a release plan, and are happy that we have a
release candiidate, which we can release for testing and annouce the planned
release.

(I thought I did announce the build, if not feel free to repeat it)

d.


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > If 2.1aX is an improvement, as we all seem to believe
> > that it is

> We don't, or at least _I_ didn't until two days ago

I didn't think so either, until recently.  And I'm NOT saying that it is
ready today, either, because there ARE issues that should be resolved before
the Release Build.  The question is what are the items to be done to get it
that way.  That was the question Peter raised in his initial post, and the
question you raised again in your post of a few minutes ago.  :-)

> the user documentation and open bugs (still being actively discussed)

Both are things that I agree need to be addressed.

> IMHO 2.1.1 is *not* an improvement until the documentation that
> accompanies it is of an acceptable standard to at least avoid
> leading people astray, even if it isn't actually helpful.

Agreed.

> If you're refering to a milestone, its already been made.

Thank you.  Would you mind if a message went out on James-User telling folks
that we're working towards a new Release Build, and asking them for
contributions towards the documentation?  They could contribute actual bits
of documentation, or just questions that they are having trouble with.

I'll post up an example of multiple mailing lists so that people can see
what needs to be done for EACH new mailing list.  The current documentation
isn't clear on that (in fact, mine works but perhaps I missed a point).
Should such contributions be posted to James-Dev or James-User?

> I don't believe that we javadocs are a showstopper, but neither do I
believe
> that they should be swept under the carpet.

That is exactly what I have been saying, Danny.  No one is sweeping javadocs
under the carpet, or deferring them.  They are being worked on actively.
Andrew has been arguing vociferously that they are a showstopper, and that's
the point of disagreement.

--- Noel


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> Exactly.  The CVS has corrected documentation that should be made
> available
> to the user community.

Up to date documentation is available on the website, this is common
practice.
Unless we seperate the release of docs from code its unavoidable, not least
because we're bound to increment release numbers by the jakarta standards we
can't patch a release once its been made, and incrementing release numbers
to patch docs would lead to a flood of email asking us what exactly had
changed in the product..

> The fact remains that 2.0a3 is out there as a Release Build.  For
> better or
> for worse.  If 2.1aX is an improvement, as we all seem to believe
> that it is

No, actually we don't, or at least _I_ didn't until two days ago, and even
then there are still the user documentation and open bugs (still being
actively discussed) to be dealt with notwithstanding the javadocs. IMHO
2.1.1 is *not* an improvement until the documentation that accompanies it is
of an acceptable standard to at least avoid leading people astray, even if
it isn't actually helpful.

> (or is close to being), then it should be put out as the next incremental
> step on the road.

If you're refering to a milestone, its already been made.

I don't believe that we javadocs are a showstopper, but neither do I believe
that they should be swept under the carpet.
Once the precendent has been establised to defer unpopular tasks it is hard
to instil any urgency in them.
I believe that we should certainly be considering the javadocs when we vote,
as well as the user docs, website and functionality.
What emphasis each commiter gives to that will be reflected in their vote.

d.


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> how long did it take you to find a class to use as an example, 
> or did you just go down the left nav in alphabetical order?

About 30 seconds.  I just picked at random from the nav bar.

> some of the committers of POI would like a policy of
> requiring a unit test per class before release!

A good idea.  Something that we all ought to be doing.

> I'll NEVER understand your position that javadoc isn't
> important enough to hold up a formal release.

Fact: 2.0a3 is listed as a Release Build.
Fact: 2.1a1 improves upon 2.0a3.

View: IF it is as/more stable, it should replace its predecessor.

--- Noel



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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> > how to setup a database URL (which is correct in the
> > CVS, and wrong in the current download).

> If this is the case it because the docs have been fixed.

Exactly.  The CVS has corrected documentation that should be made available
to the user community.

> you should only consider the relevance of the stable "release"
> versions' documentation

I was refering to 2.0a3, which IS the latest "stable Release Build."

> Furthermore James has never released a Beta quality version yet,

Perhaps not, but in Apache terminology, James 2.0a3 is a Release Build.  If
you are saying that James should never have had a Release, only a Milestone,
I won't argue the point.

> I subscribe to Andy's opinion that James is hard for a new user to get
> started with ...

So do I.  But that has to do with end user documentation, not javadocs,
except for the headers on Matchers & Mailets that contain samples, which
I've been fixing as I spot them.

On the one hand, Andy is taking an all-or-nothing position on javadocs (if
we don't have them all, we have nothing); on the other hand, he said "If I
weren't a semi-decent Java developer I couldn't even set up JAMES."

Contrary to his accusations, I've recently found, fixed and documented
various issues involving the spooler (locking, the mysterious NPE, the
reason why a message might no longer be in the spool after accept() gives it
to you); the potential for an infinite loop involving Forward;
address-literals; discrepancies between RFCs and the size of database
fields; and more.  Fortunately, I have a sense of humor.

> a +1 vote for a release binds the voter to support that release

A good policy.  :-)  I've been doing that even without a vote.  And that's
why I want to see a new release, because it will be easier to support.

As for the javadocs, I agree with everything you said about the value of
code documentation.  In every case, everyone says that it is important, no
one has said anything about not documenting or slowing documentation.  The
only issue is whether or not to update what is currently published with what
is available.  It is a matter of improvement while continuing towards
perfection.

The fact remains that 2.0a3 is out there as a Release Build.  For better or
for worse.  If 2.1aX is an improvement, as we all seem to believe that it is
(or is close to being), then it should be put out as the next incremental
step on the road.  Andy views that statement as tantamount to dismissing
javadocs as worthless.  I view his approach as being roughly the same as
saying my transmission needs an overhaul so I'll skip the oil changes until
I can afford to pay for the major service.  Both things need to be done, and
are continuing apace.

--- Noel


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

consider yourself upgraded in my book! ;-)

Danny Angus wrote:
>>or something as
>>fundamental as the correct documentation for how to setup a database URL
>>(which is correct in the CVS, and wrong in the current download).
> 
> 
> If this is the case it because the docs have been fixed.
> 
> And.. you should only consider the relevance of the stable "release"
> versions' documentation, the "latest" and "nightly" builds are strictly
> snapshots of work-in-progress, as such they should not be expected to
> function, nor should documentation be expected to be correct in any aspect.
> 
> Furthermore James has never released a Beta quality version yet, all the
> releases so far have, for various reasons, been considered to be Alpha
> quality code.
> 
> I subscribe to Andy's opinion that James is hard for a new user to get
> started with, because I have had to nursemaid many such users through their
> first experience with James.
> 
> In addition to documentation making life easier for users remember also that
> a +1 vote for a release binds the voter to support that release by
> participating on the developers and users lists. This is a great incentive
> to commiters to produce clear and accurate user documentation, and clear and
> accurate code documentation.
> 
> IMHO while the XP case for not documenting code is based in part upon the
> assumption that the code should be easy to follow and documentation  ca be
> used to avoid writing clear code, it does not follow that concise targeted
> code documentation obfuscates the code.
> 
> I rather believe that good javadoc documentation can encourage encapsulation
> and re-use by removing the necessity for programmers to concern themselves
> with the detail of code not directly relevant to the issues they are
> addressing, revealing method signatures and documenting their intended use
> cannot, surely, be counter productive, particularly in an OSS project.
> 
> Take a look at the Tomcat javadocs, they reveal the architecture of Tomcat
> in just enough detail for an outsider to extend and adapt the product,
> without explaining away bad practices, or forcing you to read the code
> itself.
> 
> I strongly believe that code documentation should be a halfway house between
> user documentation and the code itself, providing a convenient and easily
> navigable journey through the architecture, un-encumbered by the
> implementation details.
> 
> d.





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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

> or something as
> fundamental as the correct documentation for how to setup a database URL
> (which is correct in the CVS, and wrong in the current download).

If this is the case it because the docs have been fixed.

And.. you should only consider the relevance of the stable "release"
versions' documentation, the "latest" and "nightly" builds are strictly
snapshots of work-in-progress, as such they should not be expected to
function, nor should documentation be expected to be correct in any aspect.

Furthermore James has never released a Beta quality version yet, all the
releases so far have, for various reasons, been considered to be Alpha
quality code.

I subscribe to Andy's opinion that James is hard for a new user to get
started with, because I have had to nursemaid many such users through their
first experience with James.

In addition to documentation making life easier for users remember also that
a +1 vote for a release binds the voter to support that release by
participating on the developers and users lists. This is a great incentive
to commiters to produce clear and accurate user documentation, and clear and
accurate code documentation.

IMHO while the XP case for not documenting code is based in part upon the
assumption that the code should be easy to follow and documentation  ca be
used to avoid writing clear code, it does not follow that concise targeted
code documentation obfuscates the code.

I rather believe that good javadoc documentation can encourage encapsulation
and re-use by removing the necessity for programmers to concern themselves
with the detail of code not directly relevant to the issues they are
addressing, revealing method signatures and documenting their intended use
cannot, surely, be counter productive, particularly in an OSS project.

Take a look at the Tomcat javadocs, they reveal the architecture of Tomcat
in just enough detail for an outsider to extend and adapt the product,
without explaining away bad practices, or forcing you to read the code
itself.

I strongly believe that code documentation should be a halfway house between
user documentation and the code itself, providing a convenient and easily
navigable journey through the architecture, un-encumbered by the
implementation details.

d.


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

Yeah, I don't see a problem with that.  its with an actual release.

Danny Angus wrote:
> If thats what you want to do we can put out another dated 2.1a1.
> d.
> 
> 
>>>As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
>>>replace the ancient May 30 2.1a1 Milestone, and I'll feel much 
>>
>>better for
>>
>>>our end users.
>>>
>>> --- Noel
>>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
> 
> 
> For additional commands, e-mail: 





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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

> James' code isn't undocumented, but there are various uncommented members,
> so Peter is trying to complete the documentation.  The same can be said of
> org.apache.poi.  For example, AbstractFunctionPtg is missing javadocs for a
> number of members.

I'll bite...

While this is a tad offtopic...



For one, some of the members are deliberately uncommented (I don't do
inherited members as the javadoc will override the parent's).

However, POI will not have a release with formulas enabled by default 
until its fixed.  It will have "development builds" (alphas or 
"milestones") until then, but thats it.  Why: its not of release 
quality.  As evidence, formula support is still in early beta.

So Noel, how long did it take you to find a class to use as an example, 
or did you just go down the left nav in alphabetical order? That one is 
a few layers deep and in the most beta of code!  I'm impressed at your 
resolve!  If you can find others I'll make a list of them and make sure 
I catch them all before +1'ing our next release.

To take THAT a step further, some of the committers of POI would like a 
policy of requiring a unit test per class before release!  That will 
likely pass for our 3.0 release.  We'll probably need a few enhancements 
to Centipede to support "test-first" a little better before we draft that.

Just FYI, the policy on this is covered here: 
http://jakarta.apache.org/poi/resolutions/res001.html

and more or less here:

http://jakarta.apache.org/site/source.html

Its a quality thing.



Anyhow, I'm just a guy trying to make hide or hair of james.  My opinion 
shouldn't count for much, but I'll NEVER understand your position that 
javadoc isn't important enough to hold up a formal release.  (I already 
said milestone and dev releases are reasonable, but I don't think YOU 
gave it a close read)

Thanks,

Andy




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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

I will write Javadocs as I come to understand what the heck things are
(this is of course is a chicken and the egg proposition).

My interest is more in creating an M$ Exchange protocol replacement. 
But its a ways out and first IMAP needs to get up to snuff.

-Andy

Tetsuya Kitahata wrote:
> On Mon, 19 Aug 2002 00:46:55 -0400
> "Noel J. Bergman" <[EMAIL PROTECTED]> wrote:
> 
> 
>>And, of course, this has nothing to do with end user documentation,
>>such as telling a user how to install and deploy James.  You know,
>>little things like how to setup a mailing list (have fun reading the
>>docs and FAQ), how different matchers and mailets interact with each
>>other, or something as fundamental as the correct documentation for
>>how to setup a database URL (which is correct in the CVS, and wrong in
>> the current download).
> 
> 
> I agree with this. James' user documents are very good and smart.
> I think just Andy want to commit some Mailets as a developer, or
> seek where to.
> 
> I'm wondering how nice it would be to add Mailet which automatically
> collect the attached MS-Office files in e-mails and produce
> automatically RDF/XMLs of these files ... for example.
> (This is why I have come to be interested in POI and James)
> 
> -- Tetsuya Kitahata <[EMAIL PROTECTED]>





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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Danny Angus]

If thats what you want to do we can put out another dated 2.1a1.
d.

> > As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
> > replace the ancient May 30 2.1a1 Milestone, and I'll feel much 
> better for
> > our end users.
> > 
> > --- Noel
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Tetsuya Kitahata]

On Mon, 19 Aug 2002 00:46:55 -0400
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote:

> And, of course, this has nothing to do with end user documentation,
> such as telling a user how to install and deploy James.  You know,
> little things like how to setup a mailing list (have fun reading the
> docs and FAQ), how different matchers and mailets interact with each
> other, or something as fundamental as the correct documentation for
> how to setup a database URL (which is correct in the CVS, and wrong in
>  the current download).

I agree with this. James' user documents are very good and smart.
I think just Andy want to commit some Mailets as a developer, or
seek where to.

I'm wondering how nice it would be to add Mailet which automatically
collect the attached MS-Office files in e-mails and produce
automatically RDF/XMLs of these files ... for example.
(This is why I have come to be interested in POI and James)

-- Tetsuya Kitahata <[EMAIL PROTECTED]>



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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> Undocumented non-quality code is NOT pragmatic... in fact:
> http://www.pragmaticprogrammer.com/cgi-local/pragprog?FailureHowTo

I like how you imply that the James is undocumented and non-quality just
because an effort is being made to improve the quality and consistency of
the comments.

James' code isn't undocumented, but there are various uncommented members,
so Peter is trying to complete the documentation.  The same can be said of
org.apache.poi.  For example, AbstractFunctionPtg is missing javadocs for a
number of members.

The wiki you pointed to says "Write no JavaDoc (for instance) or any
documentation whatsoever."  It doesn't apply.  No one ever said "don't do
documentation."

> Javadoc to me is so basic and takes so little time, to
> actually argue against it...

Are you actually reading these messages, or responding to some imagined
offense?  No one has argued against writing javadocs, which is an active,
on-going process.  The only issue is whether or not to wait for that process
to finish before we update an old, out-of-date, package with a new package
that fixes bugs in both code and documentation that are causing problems for
people on a daily basis.

> To me this is the same as an argument to write variables a1, a2, a3

This kind of hyperbole suggests that you're really reacting to something
unrelated to anything actually going on here.  Some projects from your past,
perhaps.

And, of course, this has nothing to do with end user documentation, such as
telling a user how to install and deploy James.  You know, little things
like how to setup a mailing list (have fun reading the docs and FAQ), how
different matchers and mailets interact with each other, or something as
fundamental as the correct documentation for how to setup a database URL
(which is correct in the CVS, and wrong in the current download).

--- Noel


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Tetsuya Kitahata]

Hi, Andy and all.

On Sun, 18 Aug 2002 23:21:42 -0400
"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> To be honest Tetsuya, it makes me scared to use it.  Javadoc to me is so 
> basic and takes so little time, to actually argue against it...  To me 
> this is the same as an argument to write variables a1, a2, a3... Its 
> code quality.  This is an active argument for poor code quality and I 
> can't believe this is controversial!

I know your feelings, but it seems that it is the difference of 
"where and when to put our milestones" things.
For example, "our objectives at version 2.1 are not necessary 
complete javadocs, but at version 3.0, complete javadocs are
necessary" ... I think (for example) this is possible.

--

I agreed with Noel's opinion, "But javadocs for developers is not a 
reason to hold end users hostage", because this matter also applies
to the translation.
To catch up with frequently changed javadocs (to keep in sync) is
very difficult and almost impossible things.
The difference between this two Japanese Translation Groups(?)
http://www.terra-intl.com/jakarta/
http://www.ingrid.org/jajakarta/
is apparent. I (the former one) clearly declared " I will not
translate Javadocs because external documents are very important
for the PROMOTION of jakarta-projects but javadocs are different."
That's why I can speed it up to translate 9 jakarta-projects (including
JAMES) and the latter could not, it seems.

That's why I love the Noel's sentence.

Regards,

-- Tetsuya Kitahata <[EMAIL PROTECTED]>



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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Serge Knystautas]

Andrew,

If you feel there's something glaringly wrong that should be improved,
patches are always greatly welcome.

For my money, the only thing that should hold up a release is a volunteer
saying they will fix something but won't have it ready until date X.  Beyond
that, changelogs go out with all the contributors and committers names on
them... believe me, they're not looking to put out a bad product and just
are trying to find a balance.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/
- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.james.devel
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 18, 2002 11:21 PM
Subject: Re: about javadocs (was: Re: FW: What do we need to release 2.1?)


> To be honest Tetsuya, it makes me scared to use it.  Javadoc to me is so
> basic and takes so little time, to actually argue against it...  To me
> this is the same as an argument to write variables a1, a2, a3... Its
> code quality.  This is an active argument for poor code quality and I
> can't believe this is controversial!
>
> Tetsuya Kitahata wrote:
> > On Sun, 18 Aug 2002 20:40:35 -0400
> > "Noel J. Bergman" <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Everyone is agreeing that the documentation is necessary.  But javadocs
for
> >>developers is not a reason to hold end users hostage.
> >
> >
> > I love this sentence, "But javadocs for developers is not a reason to
> > hold end users hostage".
> >
> > I think documentation is VERY important, however, in my position
> > just exernal documents (for users) not necessarily internal ones
> > (javadocs).
> >
> > Sorry for the interruption.
> >
> > -- Tetsuya Kitahata <[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

To be honest Tetsuya, it makes me scared to use it.  Javadoc to me is so 
basic and takes so little time, to actually argue against it...  To me 
this is the same as an argument to write variables a1, a2, a3... Its 
code quality.  This is an active argument for poor code quality and I 
can't believe this is controversial!

Tetsuya Kitahata wrote:
> On Sun, 18 Aug 2002 20:40:35 -0400
> "Noel J. Bergman" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Everyone is agreeing that the documentation is necessary.  But javadocs for
>>developers is not a reason to hold end users hostage.
> 
> 
> I love this sentence, "But javadocs for developers is not a reason to
> hold end users hostage".
> 
> I think documentation is VERY important, however, in my position
> just exernal documents (for users) not necessarily internal ones
> (javadocs).
> 
> Sorry for the interruption.
> 
> -- Tetsuya Kitahata <[EMAIL PROTECTED]>





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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

> 
> No, I'm pragmatic and you just don't like it.  This isn't about some ivory
> tower notion of what makes good code.  This is about lots of James users who
> are stuck using buggy code and bad documention while we sit here using the
> good stuff and arguing over when to deliver it to them.
> 
> 
>>What good is a release to a user if he can't make hide nor hair of it?
>>If I weren't a semi-decent Java developer I couldn't even set up JAMES.
> 
> 
> I agree with you, but what does this have to do with javadocs, Andy?  Talk
> about end user documentation and we'd be agreeing, because what good are
> javadocs to the average user?
> 

Its the whole package.  Code complete.  You're not pragmatic. 
Undocumented non-quality code is NOT pragmatic... in fact:

http://www.pragmaticprogrammer.com/cgi-local/pragprog?FailureHowTo

Fine to release a development build, but don't lie and call something a 
release, you do everyone a disservice.

-Andy


>   --- Noel





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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Tetsuya Kitahata]

On Sun, 18 Aug 2002 20:40:35 -0400
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote:

> Everyone is agreeing that the documentation is necessary.  But javadocs for
> developers is not a reason to hold end users hostage.

I love this sentence, "But javadocs for developers is not a reason to
hold end users hostage".

I think documentation is VERY important, however, in my position
just exernal documents (for users) not necessarily internal ones
(javadocs).

Sorry for the interruption.

-- Tetsuya Kitahata <[EMAIL PROTECTED]>


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

> I totally disagree with just about everything Noel said except for the
> end.

> As long as everyone understands that documentation is as important as
> code and that poorly documented code is just pure rat dung.

> Code complete, means docs too.

That may be your philosophy, and it might even be one that I share.  But
we're not the ones being screwed.  The end users are.  You want to incent
developers, find another way.  But I suggest that at the moment, Peter is
doing a great job of fixing years of neglect.

> Noel, you're wrong

No, I'm pragmatic and you just don't like it.  This isn't about some ivory
tower notion of what makes good code.  This is about lots of James users who
are stuck using buggy code and bad documention while we sit here using the
good stuff and arguing over when to deliver it to them.

> What good is a release to a user if he can't make hide nor hair of it?
> If I weren't a semi-decent Java developer I couldn't even set up JAMES.

I agree with you, but what does this have to do with javadocs, Andy?  Talk
about end user documentation and we'd be agreeing, because what good are
javadocs to the average user?

--- Noel


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

I totally disagree with just about everything Noel said except for the 
end.  Development builds "milestone builds" or whatever, should not be 
delayed for quality concerns.  It just can't be blessed as a release.

As long as everyone understands that documentation is as important as 
code and that poorly documented code is just pure rat dung.  IF you 
don't Javadoc, you are a crappy no good developer.  Code complete, means 
docs too.

Noel, you're wrong, once releases are the "gold standard" developers 
care.  What good is a release to a user if he can't make hide nor hair 
of it?  If I weren't a semi-decent Java developer I couldn't even set up 
JAMES.  That puts JAMES a bit behind most other mail servers.  If a 
developer doesn't care about that, then there isn't much he could care 
about.  I've seen projects where the documentation was tied to the 
*real* release and the developers DID care.

-Andy



Noel J. Bergman wrote:
> Peter,
> 
> I agree with almost all of your points.  The only ones that I disagree with
> are:
> 
> 
>>observation of the changelog indicates, leaving javadoc out vs.
>>adding javadoc has not made the development any faster.
> 
> 
> I disagree, in a way that you'll like.  I think that accurate javadocs
> facilitates development.
> 
> 
>>I also suggested that the internal documentation be tied to a release
> 
> because:
> 
>>i) That way it actually gets done
> 
> 
> Only because you want to get it done.  Practically, it just doesn't work
> that way.  Developers already have access to the current code, so if they
> don't care about the javadocs, holding a release up isn't an incentive for
> them to do it.  And you don't need the incentive, you are doing it anyway.
> 
> 
>>ii) When the release announcement spurs a few developers to take a look
>>at the code base, they'll find a well-documented, inviting code base.
> 
> 
> I support that goal.
> 
> As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
> replace the ancient May 30 2.1a1 Milestone, and I'll feel much better for
> our end users.
> 
>   --- Noel





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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

Peter,

I agree with almost all of your points.  The only ones that I disagree with
are:

> observation of the changelog indicates, leaving javadoc out vs.
> adding javadoc has not made the development any faster.

I disagree, in a way that you'll like.  I think that accurate javadocs
facilitates development.

> I also suggested that the internal documentation be tied to a release
because:
> i) That way it actually gets done

Only because you want to get it done.  Practically, it just doesn't work
that way.  Developers already have access to the current code, so if they
don't care about the javadocs, holding a release up isn't an incentive for
them to do it.  And you don't need the incentive, you are doing it anyway.

> ii) When the release announcement spurs a few developers to take a look
> at the code base, they'll find a well-documented, inviting code base.

I support that goal.

As I said in another e-mail, let's put out a 2.1a2 Milestone Build to
replace the ancient May 30 2.1a1 Milestone, and I'll feel much better for
our end users.

--- Noel


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

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Noel J. Bergman]

Vincent Keunen wrote:
> > First, I must say that I agree with 2 comments from Noel:
> > > Internal Documentation
> > > Absolutely necessary. But NOT to hold up the 2.1 release. We can
continue
> > > to upgrade the web site with new documentation, and any serious
developer
> > > should be working from the CVS
> You wouldn't release Documentation with no code would you?
> Why would you release code with no documentation?  If documentation
> isn't a condition for release, you'll never do it.

Everyone is agreeing that the documentation is necessary.  But javadocs for
developers is not a reason to hold end users hostage.  The psychology is
backwards.  The documentation is getting done, but telling developers who
can get the current code from the CVS that there won't be a user release
until there is developer documentation is not going to incent them to do
javadocs.  If they don't care, they don't care, and they aren't the ones
being held hostage by this false incentive.  Fortunately, Peter has both
time and interest, and he is doing a great job of updating the internal
documentation.

>> javadocs are for developers. I view 2.1 as a RELEASE build for users.
>> Yes, we need to work on the javadocs, but I would not wait for them
>> before putting out a stable release build if we can do so.

> retranslate:  "Code quality is not important"

Overly simplistic software cliche.  2.1 is superior in all ways to 2.0a3,
including javadocs (albiet incomplete).

Ironically, I just answered a question from someone who downloaded 2.0a3
over a week ago, and ran into the erroneous end user documentation.
Releasing 2.1, which has CORRECT documentation would have saved that person
10 days of grief.  Sure, it would have saved me the 30 seconds it took to
reply, but it would have saved him 10 days.

At the least, I do not see any reason not to replace 2.1a1 with a 2.1a2
Milestone Build based upon what we have now, and invite end users to help
out with the user documentation.  The CVS HEAD currently fills all the
criteria necessary for a Milestone Build.

--- Noel


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

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

Well said Peter.  If your on Advogoto I'd love to upgrade you.

-Andy

PS... very offtopic
Furthermore de-emphasizing documentation is one of my key beefs with XP.
While I hate 300 page specs, I hate 0 page ones too.

Peter M. Goldstein wrote:
> Vincent,
> 
> I'm not offended, although I disagree almost entirely with your points.
> :)
> 
> Basically I feel that on distributed, volunteer projects extensive and
> appropriate documentation is even more important than on projects being
> done by a full-time, localized development team.  And I feel that it is
> extremely important even in the latter case.
> 
> While XP is an interesting methodology, James is in no way an XP
> project.  We are using none of the XP techniques (pair programming,
> rapid rotation of developers to different parts of the code base,
> aggressive refactoring of unclear code etc.) that make internal
> documentation far less important.  And as observation of the changelog
> indicates, leaving javadoc out vs. adding javadoc has not made the
> development any faster.
> 
> I believe that one of the essential things an open source project must
> do is attract developers.  You do that by making the projects
> interesting, and the code easy to understand.  To me, that means
> internal documentation.  That's what allows a new developer to come up
> to speed in a very short time and participate productively in the
> project.  And on this point at least the Apache code standards seem to
> agree with me.  :)
> 
> I also suggested that the internal documentation be tied to a release
> because:
> 
> i) That way it actually gets done
> ii) When the release announcement spurs a few developers to take a look
> at the code base, they'll find a well-documented, inviting code base.
> 
> I'd be happy to continue this discussion offline, but I stand by my
> original wish list entry.  
> 
> --Peter
> 
> 
>>-Original Message-
>>From: Vincent Keunen [mailto:[EMAIL PROTECTED]]
>>Sent: Sunday, August 18, 2002 7:13 AM
>>To: James Developers List
>>Subject: about javadocs (was: Re: FW: What do we need to release 2.1?)
>>
>>Thanks Peter, for your message that makes things move forward.  I'm
>>adding some comments about the specific item of javadocs.  First, I
> 
> must
> 
>>say that I agree with 2 comments from Noel:
>>
>>
>>>Internal Documentation
>>>Absolutely necessary. But NOT to hold up the 2.1 release. We can
>>
>>continue
>>
>>>to upgrade the web site with new documentation, and any serious
>>
>>developer
>>
>>>should be working from the CVS
>>
>>
>>and
>>
>>
>>>At least get the javadoc complete.
>>>
>>>javadocs are for developers. I view 2.1 as a RELEASE build for
>>
> users.
> 
>>Yes,
>>
>>>we need to work on the javadocs, but I would not wait for them
>>
> before
> 
>>>putting out a stable release build if we can do so.
>>>
>>
>>Peter M. Goldstein wrote:
>>
>>
>>>Internal Documentation
>>>
>>>I know some people tend to dismiss internal documentation, but I
>>
> don't
> 
>>>see how a project that is seeking to attract developers can function
>>>without it.  As such I tend to include it in the exit criteria for a
>>>particular release.
>>>
>>>1) All methods and instance variables should be documented.  All
>>
> classes
> 
>>>should be documented.  The documentation doesn't need to be
>>
> extensive,
> 
>>>but it should be present.  It should include issues such as
>>
> class/method
> 
>>>contracts and threading restrictions where appropriate.
>>>2) All public and protected classes, methods, and variables need to
>>
> be
> 
>>>documented using Javadoc style to ensure appropriate Javadoc
>>>3) The Javadoc should build without warnings
>>>4) All packages should have package documentation
>>>
>>>
>>>
>>
>>Peter, I'd like to modify a bit your suggestion.  From my experience
> 
> (15
> 
>>years of OO software developement), doc should be reduced to the
> 
> minimum
> 
>>(and I find XP discussions about documenting the code quite
> 
> appropriate
> 
>>to modern developments).  Some ideas:
>>
>>* code is the only thing that really lives; it changes often
>>  (writing docs is time consuming and is very difficult to keep in
>>  sync with the code; and out of sync doc is useless, and may even
>>  

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Peter M. Goldstein]

Vincent,

I'm not offended, although I disagree almost entirely with your points.
:)

Basically I feel that on distributed, volunteer projects extensive and
appropriate documentation is even more important than on projects being
done by a full-time, localized development team.  And I feel that it is
extremely important even in the latter case.

While XP is an interesting methodology, James is in no way an XP
project.  We are using none of the XP techniques (pair programming,
rapid rotation of developers to different parts of the code base,
aggressive refactoring of unclear code etc.) that make internal
documentation far less important.  And as observation of the changelog
indicates, leaving javadoc out vs. adding javadoc has not made the
development any faster.

I believe that one of the essential things an open source project must
do is attract developers.  You do that by making the projects
interesting, and the code easy to understand.  To me, that means
internal documentation.  That's what allows a new developer to come up
to speed in a very short time and participate productively in the
project.  And on this point at least the Apache code standards seem to
agree with me.  :)

I also suggested that the internal documentation be tied to a release
because:

i) That way it actually gets done
ii) When the release announcement spurs a few developers to take a look
at the code base, they'll find a well-documented, inviting code base.

I'd be happy to continue this discussion offline, but I stand by my
original wish list entry.  

--Peter

> -Original Message-
> From: Vincent Keunen [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 18, 2002 7:13 AM
> To: James Developers List
> Subject: about javadocs (was: Re: FW: What do we need to release 2.1?)
> 
> Thanks Peter, for your message that makes things move forward.  I'm
> adding some comments about the specific item of javadocs.  First, I
must
> say that I agree with 2 comments from Noel:
> 
> > Internal Documentation
> > Absolutely necessary. But NOT to hold up the 2.1 release. We can
> continue
> > to upgrade the web site with new documentation, and any serious
> developer
> > should be working from the CVS
> 
> 
> and
> 
> > At least get the javadoc complete.
> >
> > javadocs are for developers. I view 2.1 as a RELEASE build for
users.
> Yes,
> > we need to work on the javadocs, but I would not wait for them
before
> > putting out a stable release build if we can do so.
> >
> Peter M. Goldstein wrote:
> 
> >Internal Documentation
> >
> >I know some people tend to dismiss internal documentation, but I
don't
> >see how a project that is seeking to attract developers can function
> >without it.  As such I tend to include it in the exit criteria for a
> >particular release.
> >
> >1) All methods and instance variables should be documented.  All
classes
> >should be documented.  The documentation doesn't need to be
extensive,
> >but it should be present.  It should include issues such as
class/method
> >contracts and threading restrictions where appropriate.
> >2) All public and protected classes, methods, and variables need to
be
> >documented using Javadoc style to ensure appropriate Javadoc
> >3) The Javadoc should build without warnings
> >4) All packages should have package documentation
> >
> >
> >
> Peter, I'd like to modify a bit your suggestion.  From my experience
(15
> years of OO software developement), doc should be reduced to the
minimum
> (and I find XP discussions about documenting the code quite
appropriate
> to modern developments).  Some ideas:
> 
> * code is the only thing that really lives; it changes often
>   (writing docs is time consuming and is very difficult to keep in
>   sync with the code; and out of sync doc is useless, and may even
>   lead you to wrong assumptions...)
> * the code (at the class/method level) should be self explicit: if
>   you need doc to explain code, think about rewriting code to make
>   it more explicit; also, good developers read code almost as
easily
>   as the doc (if the code is good, of course)
> * doc is very useful at the package level: "what does this package
>   contain, where to look first" (important classes and methods
>   should be mentionned)
> * important classes/methods may need some doc
> * important here meaning "part of an API, important for external
>   developers" or "part of the basic building blocks of the system,
>   that all developers should be comfortable with"
> 
> I really don't want to start a lengthy discussion on the pros and cons
> 

Re: about javadocs (was: Re: FW: What do we need to release 2.1?)

[Andrew C. Oliver]

Vincent Keunen wrote:
> Thanks Peter, for your message that makes things move forward.  I'm 
> adding some comments about the specific item of javadocs.  First, I must 
> say that I agree with 2 comments from Noel:
> 
>> Internal Documentation
>> Absolutely necessary. But NOT to hold up the 2.1 release. We can continue
>> to upgrade the web site with new documentation, and any serious developer
>> should be working from the CVS
>

I disagree. You wouldn't release Documentation with no code would you? 
Why would you release code with no documentation?  If documentation 
isn't a condition for release, you'll never do it.  So say what you mean
"Absolutely someone else...the mythical someone else..should document 
JAMES, but quality is not important to me so I'd rather get it out the 
door undocumented and hope the mythical someone else comes along"

> 
>> javadocs are for developers. I view 2.1 as a RELEASE build for users. 
>> Yes,
>> we need to work on the javadocs, but I would not wait for them before
>> putting out a stable release build if we can do so.
>>

retranslate:  "Code quality is not important"


> Peter M. Goldstein wrote:
> 
>> Internal Documentation
>>
>> I know some people tend to dismiss internal documentation, but I don't
>> see how a project that is seeking to attract developers can function
>> without it.  As such I tend to include it in the exit criteria for a
>> particular release.
>>
>> 1) All methods and instance variables should be documented.  All classes
>> should be documented.  The documentation doesn't need to be extensive,
>> but it should be present.  It should include issues such as class/method
>> contracts and threading restrictions where appropriate.
>> 2) All public and protected classes, methods, and variables need to be
>> documented using Javadoc style to ensure appropriate Javadoc
>> 3) The Javadoc should build without warnings
>> 4) All packages should have package documentation
>>
>>  
>>
> Peter, I'd like to modify a bit your suggestion.  From my experience (15 
> years of OO software developement), doc should be reduced to the minimum 
> (and I find XP discussions about documenting the code quite appropriate 
> to modern developments).  Some ideas:
> 
>* code is the only thing that really lives; it changes often
>  (writing docs is time consuming and is very difficult to keep in
>  sync with the code; and out of sync doc is useless, and may even
>  lead you to wrong assumptions...)
>* the code (at the class/method level) should be self explicit: if
>  you need doc to explain code, think about rewriting code to make
>  it more explicit; also, good developers read code almost as easily
>  as the doc (if the code is good, of course)
>* doc is very useful at the package level: "what does this package
>  contain, where to look first" (important classes and methods
>  should be mentionned)
>* important classes/methods may need some doc
>* important here meaning "part of an API, important for external
>  developers" or "part of the basic building blocks of the system,
>  that all developers should be comfortable with"
> 
> I really don't want to start a lengthy discussion on the pros and cons 
> of documentation (see the forum related to that), but I believe that 
> docs should not get in the way of developing fast (especially on a 
> volunteer basis, with restrained resources).  And I am convinced that it 
> won't hurt the project's perennity...
> 
> Just my 2 cents (and I hope I did not offense you, Peter).
> 





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

about javadocs (was: Re: FW: What do we need to release 2.1?)

[Vincent Keunen]

Thanks Peter, for your message that makes things move forward.  I'm 
adding some comments about the specific item of javadocs.  First, I must 
say that I agree with 2 comments from Noel:

> Internal Documentation
> Absolutely necessary. But NOT to hold up the 2.1 release. We can continue
> to upgrade the web site with new documentation, and any serious developer
> should be working from the CVS


and

> At least get the javadoc complete.
>
> javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes,
> we need to work on the javadocs, but I would not wait for them before
> putting out a stable release build if we can do so.
>
Peter M. Goldstein wrote:

>Internal Documentation
>
>I know some people tend to dismiss internal documentation, but I don't
>see how a project that is seeking to attract developers can function
>without it.  As such I tend to include it in the exit criteria for a
>particular release.
>
>1) All methods and instance variables should be documented.  All classes
>should be documented.  The documentation doesn't need to be extensive,
>but it should be present.  It should include issues such as class/method
>contracts and threading restrictions where appropriate.
>2) All public and protected classes, methods, and variables need to be
>documented using Javadoc style to ensure appropriate Javadoc
>3) The Javadoc should build without warnings
>4) All packages should have package documentation
>
>  
>
Peter, I'd like to modify a bit your suggestion.  From my experience (15 
years of OO software developement), doc should be reduced to the minimum 
(and I find XP discussions about documenting the code quite appropriate 
to modern developments).  Some ideas:

* code is the only thing that really lives; it changes often
  (writing docs is time consuming and is very difficult to keep in
  sync with the code; and out of sync doc is useless, and may even
  lead you to wrong assumptions...)
* the code (at the class/method level) should be self explicit: if
  you need doc to explain code, think about rewriting code to make
  it more explicit; also, good developers read code almost as easily
  as the doc (if the code is good, of course)
* doc is very useful at the package level: "what does this package
  contain, where to look first" (important classes and methods
  should be mentionned)
* important classes/methods may need some doc
* important here meaning "part of an API, important for external
  developers" or "part of the basic building blocks of the system,
  that all developers should be comfortable with"

I really don't want to start a lengthy discussion on the pros and cons 
of documentation (see the forum related to that), but I believe that 
docs should not get in the way of developing fast (especially on a 
volunteer basis, with restrained resources).  And I am convinced that it 
won't hurt the project's perennity...

Just my 2 cents (and I hope I did not offense you, Peter).

-- 
!try; do()
--
Vincent Keunen, Ir, http://vincent.keunen.net
Manex, rue Wagner 93, BE-4100 Boncelles, Belgium
Our site: http://www.manex.be

Re: FW: What do we need to release 2.1?

[Stephen McConnell]

Peter M. Goldstein wrote:

>All,
>
>Apologies for the cross-post folks - this was supposed to go to
>james-dev, not james-user.
>
>--Peter
>
>-Original Message-
>From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
>Sent: Friday, August 16, 2002 1:56 PM
>To: 'James Users List'
>Subject: What do we need to release 2.1?
>
>All,
>
>There's started to be some agitation on the james-user mailing list for 
>a new release.  While I don't think we're there yet, I think it is
>reasonable for us to ask (and try to come to some sort of consensus)
>what features/fixes do we feel are required for the next release.  To
>kick off the conversation, I'm going to give everybody my personal wish
>list.
>
>New Features:
>
>1) IMAP - I think this one is going to be on most people's list.  I'd
>like to see IMAP at an "Experimental" level.  That means basic
>functionality as specificied in the relevant RFCs will be implemented.
>Certain functionality may be documented as not yet implemented, and the
>system will not necessarily have undergone load or stress tests
>
>Experimental => Stable
>
>1) TLS Support for POP3 - This is really a rather simple piece of
>functionality.  I think this one should be stabilized before we release
>the next revision.
>
>Internal Documentation
>
>I know some people tend to dismiss internal documentation, but I don't
>see how a project that is seeking to attract developers can function
>without it.  As such I tend to include it in the exit criteria for a
>particular release.
>
>1) All methods and instance variables should be documented.  All classes
>should be documented.  The documentation doesn't need to be extensive,
>but it should be present.  It should include issues such as class/method
>contracts and threading restrictions where appropriate.
>

+1

>2) All public and protected classes, methods, and variables need to be
>documented using Javadoc style to ensure appropriate Javadoc
>
+1

>3) The Javadoc should build without warnings
>
+1

>4) All packages should have package documentation
>

+36365

>
>External Documentation
>
>1) Write up specific documentation addressing the top 5 issues listed on
>the TODO list
>2) Start building an organized James "manual" with common
>configurations.
>  
>

This is something I've been thinging about with respect to the Merlin 
based deployment.  In Merlin you can create preconfigured profiles for 
components and in some case totally eliminate the need for user provided 
configuration.  In addition in Merlin you can seperate configuration 
defaults for a particular type from the configuration, context, and 
logging profile.

>Avalon
>
>1) Migrate all Composable to Serviceable
>

+1

>2) Deal with the Mailet API implications by creating a ComponentManager
>wrapper for the ServiceManager.  Note this in documentation, with the
>understanding that we'll be deprecating.
>

Can you expand on the issues here - keeping in mind that I don't knw 
anything about the Mailet API (at least not yet).

>3) Change code so that it doesn't use the TimeScheduler
>
>Enhancements / Bug Fixes
>
>1) Include Andrei's changes to address connection handler
>performance/robustness issues.
>2) Bugs #2288, #4003, #6812, #6928, #8581, #8839, #8861, #9669, #11243,
>#11640.
>3) Address the as of yet unfiled bug about sending emails to an IP
>address.
>4) New bugs will be evaluated on a case by case basis as they are filed.
>
>Thoughts?
>

And - get in place documentation of the dependecies - componet 
interdepdencies, component implementation versions, servce versions, jar 
file extension depedences (including specification and implementation 
versions).

Cheers, Steve.

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

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




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

Re: FW:

[Serge Knystautas]

I assume this is something you see in every day use, not something 
special related to the list.  This looks related to the permanent vs 
temporary failure problem that was cleaned up in the latest alpha release.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Danny Angus wrote:
> Hi,
> 
> This is *really* annoying... is it only me?
> 
> Hi. This is the James mail server at linux.killerbees.co.uk.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
> 
> 
> Unknown SMTP host: mail.apache.org.;
>   nested exception is:
>   java.net.UnknownHostException: mail.apache.org.
> 
> The original message is attached.


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

RE: FW: problem sending email, body in Rich Text Format / Plain Text

[Steve Short]

I tried this out for myself, 'cos I was slightly concerned about it and have
been unable to reproduce the problem.  Do you have any more info about your
configuration that might help narrow this down and resolve it?

Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 03, 2002 10:59 AM
To: James Developers List
Subject: Re: FW: problem sending email, body in Rich Text Format / Plain
Text


Kishore,

This is a bug in JavaMail.  I see this error message occassionally in my 
logs but never had the email source that was causing it.  You'll have to 
follow-up with Sun on this one as we're rather dependent on their 
library for MIME parsing and writing.  I think JavaMail 1.3 is about to 
come out (or maybe already has) so you could test that it could read and 
write that message.  Once JavaMail 1.3 FCS is out, we'll need to upgrade 
James to use this new version of JavaMail, irregardless.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Kishore Metla wrote:
> Hi,
> 
> I did not get any answer and this is kind of important. Can someone please
> help me. 
> 
> Thanks in advance
> -Kishore
> 
> -Original Message-
> From: Kishore Metla [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 01, 2002 11:16 AM
> To: '[EMAIL PROTECTED]'
> Subject: problem sending email, body in Rich Text Format / Plain Text
> 
> 
> 
> Hi,
> 
> I have James set up. I have a problem when sending an email using
Microsoft
> Outlook 2000 Plain Text or Rich Text to the James with an attachment but
> with no message in the body.
> 
> I am choosing the format of the mail in the Outlook by going to Tools >>
> Options >> Mail Format >> 'Choose a format for outgoing mail ...'  and
> choosing the option as 2 or 3 from the available as listed below 
> 1. HTML
> 2. Microsoft Outlook Rich Text
> 3. Plain Text
> 
> When I send an email to the James Server to categorize, choosing HTML
(with
> or without a message in the body) it works fine. If I send an email
choosing
> either Plain Text or Rich Text with some message in the body it works
fine.
> But If no message in the body (sending just an attachment) it fails
throwing
> an exception (see below).
>

>

> 
> javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream; 
> name="example.PDF"
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:851)

> at javax.activation.DataHandler.writeTo(DataHandler.java:305) 
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:635)
> at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:233)
> at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:68)
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:849)
> at javax.activation.DataHandler.writeTo(DataHandler.java:305)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1527)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1503)
> at org.apache.james.core.MailImpl.writeMessageTo(MailImpl.java:198)
> at
>
org.apache.james.mailrepository.AvalonMailRepository.store(AvalonMailReposit
> ory.java:98)
> at org.apache.james.James.sendMail(James.java:298)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
>
org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> at
>
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:152)
> at
>
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:
> 166)
> at
>
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:142)
> at org.apache.avalon.utils.recycle.pool.Worker.run(Worker.java:113)
> Exception in processor 
> javax.mail.MessagingException: Exception spooling message: Exception
caught
> while storing Message Container: javax.activ
> ation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream;
> name="example.PDF"
> at org.apache.james.James.sendMail(James.java:304)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
>
org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> a

Re: FW: problem sending email, body in Rich Text Format / Plain Text

[Serge Knystautas]

Kishore,

This is a bug in JavaMail.  I see this error message occassionally in my 
logs but never had the email source that was causing it.  You'll have to 
follow-up with Sun on this one as we're rather dependent on their 
library for MIME parsing and writing.  I think JavaMail 1.3 is about to 
come out (or maybe already has) so you could test that it could read and 
write that message.  Once JavaMail 1.3 FCS is out, we'll need to upgrade 
James to use this new version of JavaMail, irregardless.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Kishore Metla wrote:
> Hi,
> 
> I did not get any answer and this is kind of important. Can someone please
> help me. 
> 
> Thanks in advance
> -Kishore
> 
> -Original Message-
> From: Kishore Metla [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 01, 2002 11:16 AM
> To: '[EMAIL PROTECTED]'
> Subject: problem sending email, body in Rich Text Format / Plain Text
> 
> 
> 
> Hi,
> 
> I have James set up. I have a problem when sending an email using Microsoft
> Outlook 2000 Plain Text or Rich Text to the James with an attachment but
> with no message in the body.
> 
> I am choosing the format of the mail in the Outlook by going to Tools >>
> Options >> Mail Format >> 'Choose a format for outgoing mail ...'  and
> choosing the option as 2 or 3 from the available as listed below 
> 1. HTML
> 2. Microsoft Outlook Rich Text
> 3. Plain Text
> 
> When I send an email to the James Server to categorize, choosing HTML (with
> or without a message in the body) it works fine. If I send an email choosing
> either Plain Text or Rich Text with some message in the body it works fine.
> But If no message in the body (sending just an attachment) it fails throwing
> an exception (see below).
> 
> 
> 
> javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream; 
> name="example.PDF"
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:851) 
> at javax.activation.DataHandler.writeTo(DataHandler.java:305) 
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:635)
> at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:233)
> at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:68)
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:849)
> at javax.activation.DataHandler.writeTo(DataHandler.java:305)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1527)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1503)
> at org.apache.james.core.MailImpl.writeMessageTo(MailImpl.java:198)
> at
> org.apache.james.mailrepository.AvalonMailRepository.store(AvalonMailReposit
> ory.java:98)
> at org.apache.james.James.sendMail(James.java:298)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
> org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> at
> org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:152)
> at
> org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:
> 166)
> at
> org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:142)
> at org.apache.avalon.utils.recycle.pool.Worker.run(Worker.java:113)
> Exception in processor 
> javax.mail.MessagingException: Exception spooling message: Exception caught
> while storing Message Container: javax.activ
> ation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream;
> name="example.PDF"
> at org.apache.james.James.sendMail(James.java:304)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
> org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> at
> org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:152)
> at
> org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:
> 166)
> at
> org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:142)
> at org.apache.avalon.utils.recycle.pool.Worker.run(Worker.java:113)
> 
> 
> 
> 
> For your information, I tried to check what it is doing. For the email sent
> in HTML (successful case),
> 
> ..
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Content-Type: multipart/mixed;
>   boundary="_=_NextPart_000_01C1D763.B43A2C50"
> Status:   
> This message is in MIME format. Since your

Re: FW: Starting James in same jvm

[Paul Hammant]

Chris,

Make you application a Phoenix block.   on the interfaces 
offered by James for true interaction.

Be in the same VM as Jo!, JabberServer, AvalonDB, Jesktop, etc etc too.

- Paul

>
>> -Original Message-
>>From: Forbes, Chris  
>>Sent: Tuesday, February 19, 2002 9:02 PM
>>To:   '[EMAIL PROTECTED]'
>>Subject:  Starting James in same jvm
>>
>>I am trying out James, version 1.2.1, on NT4.0, patch 6. 
>>
>>I wish to start James from my own Java application and to this end have
>>written a small test java class, StartJames, that instanciates an instance
>>of org.apache.avalon.loader.Main and then calls the main routine with an
>>args vector that has: {"-c", "config path", "-p",
>>"org.apache.xerces.parsers.SAXParser", "-l" "path to avalon.log"}.
>>
>>Of course, the arguments in args are valid paths.  When I run this test
>>program, I get the following output:
>>parser: org.apache.xerces.parsers.SAXParser
>>configurationPath : d:/Program Files/MailServer/James/conf/
>>logFile   : d:/Program Files/MailServer/James/logs/avalon.log
>>libPath   : ../lib/
>>blockPath : ./blocks/
>>
>>The first three items are fine, just as I specified in the args vector.
>>
>>My problem is that the last two items seem to be hard coded, "../lib" and
>>"./blocks".  If I actually put those directories relative to the place
>>where I run my test program, then it works fine.  But that is not very
>>configurable and won't work for the purpose I have in mind.
>>
>>My question is: Is there a way to make org.apache.avalon.loader.Main aware
>>of libPath and blockPath? For instance, via a call to
>>System.setProperty("libPath","path").
>>
>>If not, is there another way to start James programatically?
>>
>>Thanks,
>>
>>Chris Forbes
>>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>




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

RE: FW: current version of James?

[Danny Angus]

thanks Pete.

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 09, 2002 12:17 PM
> To: James Developers List
> Subject: Re: FW: current version of James?
> 
> 
> On Wed, 9 Jan 2002 23:13, Danny Angus wrote:
> > what I can't do, no account on deadalus, is update the website, but if
> > no-one else wants to I can try and get one.
> 
> If you want you can prolly get one. If you are too lazy feel free 
> to update 
> CVS and prod me - usually I will be able tpo update with in 24 hours 
> 
> -- 
> Cheers,
> 
> Pete
> 
> "Artists can color the sky red because they know it's blue.  
> Those of us who
>  aren't artists must color things the way they really are or people might 
>  think we're stupid." -- Jules Feiffer 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: FW: current version of James?

[Peter Donald]

On Wed, 9 Jan 2002 23:13, Danny Angus wrote:
> what I can't do, no account on deadalus, is update the website, but if
> no-one else wants to I can try and get one.

If you want you can prolly get one. If you are too lazy feel free to update 
CVS and prod me - usually I will be able tpo update with in 24 hours 

-- 
Cheers,

Pete

"Artists can color the sky red because they know it's blue.  Those of us who
 aren't artists must color things the way they really are or people might 
 think we're stupid." -- Jules Feiffer 


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