Versions Compared

Old Version 29

changes.mady.by.user Chris Wilper

Saved on

compared with

New Version 30

changes.mady.by.user Chris Wilper

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Send the following information to cwilper (at) duraspace.org:
    • Your duraspace.org userid. This is used to grant you committer-level permission on the resources hosted on the website (JIRA, Confluence, Bamboo, etc)
    • Your sourceforge.net userid (If you don't have one, create one here). The code repository is currently hosted at We use sourceforge.net to distribute releases, so we need your userid there in order to grant you write access.
    • Your GitHub userid (If you don't already have one, sign up here. GitHub hosts our source code repositories for the project; we'll need your id to grant you write access.
    • If you're a Skype user, your Skype userid.  If you don't use Skype, please provide a phone # and/or Instant Messaging info.
  2. Sign up to the Fedora Development list.
  3. Sign up to the Fedora Codewatch list using your userid@sourceforge.net address.  This is a public list that all committers subscribe to.  It's used solely for automatic notification of Subversion commits and automated test results.  It is necessary to sign up using your sourceforge.net id; commit notification will not work otherwise.  Make sure you have set up your Sourceforge account so that emails to userid@sourceforge.net are forwarded to your usual address.

...

  • Code Style
    The project's coding style is currently best described by the Eclipse settings in src/build.  Here are the major rules:
    • Four space indents for Java, and 2-space indents for XML. NO TABS.
    • K&R style braces:
      Code Block
      if (code) {
  // code
} else {
  // code
}
    • Dont use wildcard imports
    • Write Javadocs for public methods and classes.  Keep it short and to the point.
    • Avoid public instance variables; use accessors.
    • Use public methods sparingly; implementation details are not public.
  • Logging
    We currently use SLF4J for logging. When writing log messages (especially INFO, FATAL, and WARN), consider your audience.  Don't over-use INFO; these messages are always logged by default.
  • Testing
    Use JUnit for unit, integration, and system tests.  When making changes, please take the time to write tests as needed.  We are not looking for 100% coverage here, but the developers will have a lot more confidence in your code if you can show that it works.  See the readme.txt in the root of the source tree as a jumping-off point for adding your tests to one of the suites.  Here's a brief description of the basic types of tests we run:
    • Unit - Tests a single class.  These tests are typically very quick to run, and therefore get the most use by developers.  Unit tests don't touch the disk or interface with classes other than mocks.  If you can cover a scenario adequately in a unit test, you should prefer implementing it as such (and not as an integration or system test)
    • Integration - Tests multiple classes working together.  May touch disk or interact with a "test" database.
    • System - Works against a running Fedora server in a given configuration.  These are "block box" style tests against the public APIs of Fedora.  These take much longer to run than unit or integration tests because they require significant setup.

Working in a Branch

If you're a new committer, or you're working on a substantial body of code, you should create a branch to work on it.  Here's a guide to branching in subversion if you're not already familiar.

Branches should be created as fedora/branches/fcrepo-123, where "fcrepo-123 is the JIRA id of the issue you're working on.

When it's time to merge your branch down to trunk, you may request a review by another committer.  Request a review via email, then assign them as the reviewer for the issue (or Code Task) in JIRA and click "Start Review".  When the reviewer is finished, they'll let you know so you can merge your branch down to trunk.

When you've successfully merged your branch, it's useful life is over.  You should therefore remove it from the /branches directory in subversion.

Committing to Trunk

Whether you're merging down from a branch or making changes directly to the trunk, you should be reasonably certain that your change won't break existing code.  One way to quickly check is to run "ant junit" prior to check-in.  If you're still not sure, you may also run several of the system tests as described in the readme.txt in the root of the source tree.

Using Git

Please see Git Guidelines and Best PracticesSoon after you commit a change to the trunk, a set of automated tests will begin running on our test server.  You should get an email within an hour indicating whether the test succeeded or failed.  If the tests failed, other developers will be notified via the codewatch list so that they know not to do a "svn update" until you have committed a fix.

Closing an Issue

Once the relevant code has been committed and passes the automated tests, you can resolve the issue in JIRA.  Prior to resolving an issue, double check to make sure the metadata is accurate in the tracker.

...