Differences between revisions 2 and 3
Revision 2 as of 2013-04-03 16:07:13
Size: 5877
Editor: RobertMuir
Comment: move this to contribution guidelines
Revision 3 as of 2013-04-03 17:04:19
Size: 6144
Editor: UweSchindler
Comment: java 6/7
Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
  * All code to be included in trunk, from which 4.0 will be released, should be compatible with Java 6.   * All code to be included in 4.X releases should be compatible with Java 6.
  * All code to be included in trunk, from which 5.0 will be released, should be compatible with Java 7. As most code is currently committed also to the 4.x branch it is a good idea to only use Java 6 code features (no diamond operators instead of full generics,...) unless explicitly needed.

Tips for developers

Dependencies

Building Lucene requires that you have Apache Ant installed. Starting with 3.6, Apache Ivy is also required for fetching dependency jars to compile against.

Once you have ant working, you can use the "ant ivy-bootstrap" build target to have ivy automatically downloaded and installed for you in your ${user.home}/.ant/lib directory

Tips to configure IDEs

Instructions to configure IntelliJ: HowtoConfigureIntelliJ. For Eclipse, see HowtoConfigureEclipse.

Contribution guidelines

Before you start, send a message to the developer mailing list (Note: you have to subscribe before you can post), or file a bug report in Jira. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.

Modify the source code and add some (very) nice features using your favorite IDE.

But take care about the following points:

  • Code compatibility:
    • All code to be included in 3.X releases should be compatible with Java 5.
    • All code to be included in 4.X releases should be compatible with Java 6.
    • All code to be included in trunk, from which 5.0 will be released, should be compatible with Java 7. As most code is currently committed also to the 4.x branch it is a good idea to only use Java 6 code features (no diamond operators instead of full generics,...) unless explicitly needed.
  • All public classes and methods should have informative Javadoc comments.

  • Code should be formatted according to Sun's conventions with one exception:

    • indent two spaces per level, not four.
  • Contributions should pass existing unit tests.
  • New unit tests should be provided to demonstrate bugs and fixes (http://www.junit.org).

  • The java source code is in the directory lucene/src/java and the java test code is in the directory lucene/src/test.

Please do not:

  • reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.
  • comment out code that is now obsolete: just remove it.
  • insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.
  • make things public which are not required by end users.
  • Add @author tags to your code. (Instead, give yourself credit in the CHANGES.txt file.)

Please do:

  • try to adhere to the coding style of files you edit;
  • comment code whose function or rationale is not obvious;
  • update documentation (e.g., package.html files, this wiki, etc.)

Please use the LUCENE-NNNN.patch naming pattern when creating patches for uploading to JIRA. Once you create a new JIRA issue, note its name and use that name when naming your patch file. For example, if you are creating a patch for a JIRA issue named LUCENE-3456, then name your patch filename LUCENE-3456.patch. If you are creating a new version of an existing patch, use the existing patch's file name. JIRA will automatically "gray out" the old patch and clearly mark your newly uploaded patch as the latest.

European SVN Mirror

Depending on where you are located the European mirror might be faster or slower:

svn checkout http://svn.eu.apache.org/repos/asf/lucene/dev/trunk/ lucene-trunk

Problems with Ivy?

Some people have reported problems getting Ivy to work when installed in ${user.home}/.ant/lib

The majority of these issues seem to be people using installations of ant packaged by linux disto providers that either do not provide a full ant install (ie: additional RPMs are required) or explicitly disable the ability to use "user lib" feature of ant in their configs, or have some other problems.

Suggested fixes for people who still have problems getting Ivy to work after running "ant ivy-bootstrap"...

  • try using the "--noconfig" option when running ant
  • try adding "rpm_mode=false" to your ~/.ant/ant.conf
  • try removing "rpm_mode=true" from your /etc/ant.conf
  • try installing a clean version of Apache Ant downloaded directly from the Apache mirrors

For more details:

Pre-commit check

Committers run this check before they commit something. But you can help them out by running it yourself first and fixing anything it catches.

Before constructing your patch, please run the top-level pre-commit check, which finds problems like tabs and @author tags in source files, broken links in javadocs, files not controlled by Subversion (a.k.a. "unversioned files"), etc.

To run the pre-commit checks from ant, run the following from the top-level directory -- the directory containing lucene/ and solr/ -- in your working copy:

ant precommit

Other Helpful Resources

The following resources may prove helpful when developing Lucene contributions. (These are not an endorsement of any specific development tools)

DeveloperTips (last edited 2013-12-10 16:03:40 by SteveRowe)