Creating and maintaining a mathematical and statistical library that is
accurate requires a greater degree of communication than might be the
case for other components. It is important that developers follow
guidelines laid down by the community to ensure that the code they create
can be successfully maintained by others.
Developers are asked to comply with the following development guidelines.
Code that does not comply with the guidelines including the word must
will not be committed. Our aim will be to fix all of the exceptions to the
"should" guidelines prior to a release.
Here are some steps to take to get starting contributing to commons-math:
Start by reviewing the overall objectives stated in the
proposal upon which the project is
founded.
Download the commons math source code. Follow the instructions
under the heading "Anonymous Subversion"
here (and
also have a look
here) to check out the commons math code base from Subversion
(Jakarta Commons now uses Subversion as our source control system). The
svn url for the current development sources of commons-math
is
https://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk
Have a look at the new features that users and developers have requested
on the
Math Wish List Wiki Page.
Be sure to join the commons-dev and commons-user
email lists and use them appropriately (make sure the string
"[math]" starts the Subject line of all your postings).
Make any proposals here where the group can comment on them.
Setup an account on Bugzilla and use it to submit patches and
identify bugs. Read the
directions for submitting bugs and search the database to
determine if an issue exists or has already been dealt with.
Generating patches: The requested format for generating patches is the Unified Diff format,
which can be easily generated using the svn client or Eclipse IDE.
svn diff > patch
Commons-math follows Code
Conventions for the Java Programming Language. As part of the maven
build process, style checking is performed using the Checkstyle plugin,
using the properties specified in checkstyle.xml.
Committed code should generate no Checkstyle errors.
Committed code must include full javadoc.
All component contracts must be fully specified in the javadoc class,
interface or method comments, including specification of acceptable ranges
of values, exceptions or special return values.
External references or full statements of definitions for all mathematical
terms used in component documentation must be provided.
Implementations should use standard algorithms and
references or full descriptions of all algorithms should be
provided.
Committed code must include unit tests.
Unit tests should provide full path coverage.
Unit tests should verify all boundary conditions specified in
interface contracts, including verification that exceptions are thrown or
special values (e.g. Double.NaN, Double.Infinity) are returned as
expected.
All new source file submissions must include the Apache Software
License in a comment that begins the file
Patches must be accompanied by a clear reference to a "source"
- if code has been "ported" from another language, clearly state the
source of the original implementation. If the "expression" of a given
algorithm is derivative, please note the original source (textbook,
paper, etc.).
References to source materials covered by restrictive proprietary
licenses should be avoided.
Here is a list of relevant materials. Much of the discussion surrounding
the development of this component will refer to the various sources
listed below, and frequently the Javadoc for a particular class or
interface will link to a definition contained in these documents.