Apache Jakarta James - Contributors How To - Java Mail and News server, SMTP POP3 NNTP

James

- Overview
- James FAQ

Translated

- Japanese (web)

Downloads

- Binaries
- Source Code

Current Documentation

- James 2.1 Documentation
- James Javadocs
- Mailet API
- James and sendmail
- Useful RFCs

Older Documentation

- James Document Archive

Project

- Bug Database
- How Can I Contribute?
- Coding Standards
- License
- TODO
- Changelog
- Who We Are

Jakarta Information (web)

- Front Page
- News & Status
- Mailing Lists
- Get Involved
- CVS Repositories
- Reference Library
- FAQs

Related Projects (web)

- Jakarta
- Ant
- Avalon

Introduction

> Anyone can contribute
> That's right, we always want to hear from people with contributions to the code, the documentation, the website, and bug reports.
> The rest of this document outlines the way to go about these to maximum effect.

> If you are new to this you may be interested in some of these resources.
> A good, full, summary of links to guidelines
> Subscribe to the relevant mailing lists (link on the left).
> Craig R. McClanahan's advice how to get involved
> How Jakarta projects run

Code Patches

> Patches should be submitted to the developers mailing list.
> Always use diff -u to generate patches, make sure you are patching the latest cvs (the HEAD).
> Make your patch from the jakarta-james directory and make sure it conforms to the code standards, otherwise it may be ignored. It is OK to make a single patch covering several files, but please only one issue at a time.
> Prefix the mail subject with [PATCH]
> Briefly outline the reason for your patch, the solution your patch implements, why a patch is needed and why your code will solve the problem. Note any bug numbers your patch addresses.

> The reason for these is so that the commiters can easily see what you are trying to achieve, it is their resonsibility to manage the code and review submissions, if you make it easy for them to see what you are doing your patch is more likely to be commited quickly (or at all).

Adding New Code

> Like the principles for patch submission, mark your mail [PATCH] and ensure your submission conforms to the code standards. Provide a Brief outline of your intentions, as above, so that your code can be reviewed easily, and a note of any relevant bug numbers.
> New files must contain a reference to the Apache licence, copy the header from an existing file.
> It also helps if you send your files in an archive (tar, zip) which preserves directories, make it from the jakarta-james directory so we can un-tar your files into the right place.

Reporting and Fixing Bugs

> Many improvements come as a direct result of bug reports, and contributed fixes, often by the same person. It is sometimes said that Apache projects evolve because users become so fed-up waiting for bugs to be addressed that they fix them themselves. :)
> If you report a bug, here we'd appreciate it if you could send a mail to the users or developers mailing lists, so that we can discuss it with you, bugzilla isn't a great way for mediating communication.
> If you want to fix a bug, please contribute your changes according to the guidelines above, in the Code Patches section. It is much simpler to deal with submissions if they all come through the same channel. If you still really want to attach patches to bug submissions, please do send us a mail tagged [PATCH] too, so that we notice your patch.

Documentation

> While we are glad to accept contributions to documentation from anyone, in almost any format, because its much better than none, please consider these guidelines to help us to assimilate your contribution.
> To edit an existing document try to edit the xml version in src/xdocs (check it out from cvs) and if you can, submit a patch as for Code Patches.
> If you want to contribute new files please try to use the simple xml format we use.
> If this means nothing to you please try to contribute HTML or plain text documents without any styling, so that we can get at the words and easily convert them into our xml format.
> If all this seems like unnecessary nonsense, send us whatever you like, we'd still be happy to receive good documentation.

Copyright © 1999-2002, Apache Software Foundation