Re: FW: [important proposal] Cocoon as official Apache project
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: mailto:james-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:james-dev-help;jakarta.apache.org
RE: FW: [important proposal] Cocoon as official Apache project
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: mailto:james-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:james-dev-help;jakarta.apache.org
RE: FW: [important proposal] Cocoon as official Apache project
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: mailto:james-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:james-dev-help;jakarta.apache.org
RE: about javadocs (was: Re: FW: What do we need to release 2.1?)
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: 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: about javadocs (was: Re: FW: What do we need to release 2.1?)
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... soap-box 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. /soapbox 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: 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?)
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: 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?)
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: 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?)
You did. :-) My question was about soliciting documentation contributions. solicit away. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 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: about javadocs (was: Re: FW: What do we need to release 2.1?)
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: 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?)
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 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 -- To unsubscribe, e
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
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 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
RE: about javadocs (was: Re: FW: What do we need to release 2.1?)
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: 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?)
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: 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?)
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: 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?)
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?)
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: 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?)
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, 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?)
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: What do we need to release 2.1?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 local 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 mail reader does not understand this format, some or all of this message may not be legible.
Re: FW: Starting James in same jvm
Chris,
Make you application a Phoenix block. depend 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: 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?
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]
