ExoLab     OpenEJB     OpenJMS     OpenORB     Castor     Tyrex     
 

Main
  Home
  Download
  API
  Schema
  Mailing Lists
  CVS / Bugzilla
  Support

XML
  Using XML
  Source Generator
  Schema Support
  XML Mapping
  XML FAQ

JDO
  Using JDO
  JDO Config
  Types
  JDO Mapping
  JDO FAQ
  Other Features

Advanced JDO
  OQL
  Trans. & Locks
  Design
  KeyGen
  Long Trans.
  Nested Attrs.
  Pooling Examples
  Blobs and PostgreSQL

More
  Presentations
  The Examples
  Extras and 3rd Party Tools
  Test Framework -- JDO
  Test Framework -- XML
  Configuration
  Tips & Tricks
  Full JavaDoc

About
  License
  Contributors
  Status, Todo
  Changelog
  Library
  Contact

  



Bugzilla: Bug Reports and Tracking
WebCVS, CVS Snapshots
Anonymous CVS Access
Behind A Firewall?
Guidelines For Code Contribution
Guidelines For Committers
Licensing Policy

Bugzilla: Bug Reports and Tracking

Please use our Bugzilla server for bug reporting/tracking.

Before submitting bugs, please read the Bugzilla Etiguette and Bug Writing Guidelines from Mozilla.org.

WebCVS, CVS Snapshots

To get the latest, most up-to-date source code, you'll need to use CVS, please see Anonymous CVS Access below. If you wish to simply browse the CVS for specific files or to view changes and commit logs use ViewCVS access to the repository.

Or, download the full source distribution for a given release, or the latest daily snapshot of the CVS.

Anonymous CVS Access

The source code, documentation and libraries are available for anonymous access from the Exolab CVS server.

The CVS is updated regularly and may contain an unstable version when you check it out. We commit working code to the CVS immediately prior to putting out a release.

The CVS root is :pserver:anoncvs@castor.exolab.org:/cvs/castor and the password anoncvs.

To login to CVS from the command line and checkout a version of Castor use the following commands:

  $ cvs -d :pserver:anoncvs@castor.exolab.org:/cvs/castor login
  password: anoncvs
  $ cvs -d :pserver:anoncvs@castor.exolab.org:/cvs/castor checkout castor
      

Note: There have been reports of problems using jCVS with ours CVS servers. Please use an alternative CVS client until this problem is resolved.

Behind A Firewall?

Sometimes firewalls are configured in such a way that users behind the firewall cannot access the CVS port. If you fall into this category, don't worry, we're thinking about you! Just download the latest daily snapshot of the CVS at: ftp://ftp.exolab.org/pub/castor/castor_daily_snapshot.tgz

Guidelines For Code Contribution

All code contributions must be under the license and copyright of the project to which you contribute. By contributing code you agree that we can distribute the contribution under the terms of the license, that it can be distributed without any royalties, copyright, trademark, patent or other legal lock ups. Open source means no discrimination against any group or individual that may wish to use the code.

When making a contribution you are granting us a world wide, royalty free, unlimited in time license to re-distribute the code under the Exolab license. In case you wonder, you remain the original author and copyright holder of the contribution, you just give other people a license to use it as well. Thank you.

It's perfectly ok to put your name and e-mail address in the code.

When sending patches, diff files with context (3 lines before, 3 lines after) work best:

  cvs diff -u <file>
againsts the up-to-date cvs version, or
  diff -u <file>

It is very important for sending test cases along with the patch of a new feature and a bug fix.

A test case, showing a feature being added, a bug being fixed, proves that the patch plays along nicely with other code, ensures the committer understands what the patch does and also encourages promptly reviewing and checking in.

Committer commits a patch only if s/he fully understands the patch.

Also, a test case is the easiest way to ensure your contribution will not be broken by another patch later. It becomes even more important if your project depends on a feature that you're contributing.

Guidelines For Committers

Familiarize yourself. Take some time to understand the directory structure, build environment, interaction between components, coding and commenting style. Nothing out of the ordinary, but still not all projects are identical.

Before starting to work please advertise. It's pointless to have two people working on the same feature. Send an e-mail to the developer mailing list and announce what and how. If you don't get a reply within a day, you can assume the coast is clear.

Test before you commit. Before committing any changes run a cvs update to make sure you have the latest code base. Run the test cases to make sure nothing is broken.

Commit all at once. If the change involves more than a single file, make sure to commit all the changes together. A partially committed CVS tree is not a pretty sight. No lunch breaks, meetings or sleep during commits.

Be ready to receive complaints. Hopefully all works fine, but if changes to break existing code, people will complain. Be ready to answer their e-mails and apply the proper fixes. No going on vacation five minutes after a commit.

Put your name so people know who to credit. (Also who to blame). Initials work just fine, your full name and e-mail address are already on the main page. If you've added a new file, feel free to put your name and e-mail address as the author. If you're fixing a file, put your initials on the comment.

Observe release time. We're going to announce a new release five hours prior to making it. That gives you four hours to commit any changes, make sure nothing breaks. Don't leave the computer before the release is done. If you can't make it, there's alway the next release.

Document what you've done. In-code documentation, CVS commit messages, and the changelog. Major changes should always be recorded in the changelog.

Use the document DTD. When adding new documentation use the document DTD. Specify the proper document URL, properties, body and section. Everything inside the body/header/section is XHTML. That means well formed HTML. If it's not, you won't be able to build the docs.

We don't have a particular style for documentation, and we do appreciate a sense of humor, sarcasm and literary expression. Just don't overdue it, and please, no cliche.

Licensing Policy

We have a simple policy regarding distributable code. Either it's open source and compatible in license, or it's an API that is freely distributable.

BSD-like and MPL-like licenses are compatible and can be mixed in the same code base. Liberal licenses and public domain are also fine.

APIs need not be open source, but they must be freely distributable. As a policy we like to stick with standard APIs and never modify them, so the license has little affect. We do favor public domains APIs like SAX over tightly controlled APIs, and hopefully we can all do something about that.

Pay special attention to pre-release availability and trademark issues. Several committees and companies require proper trademark acknowledgement in the documentation. Some of them are available for distribution only once they have been formally released. This policy applies to all APIs coming from Sun.

 
   
  
   
 


Copyright ) 1999-2003 ExoLab Group. All rights reserved.
 
Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners.