Subscribe to our Shark-news- mailing list to get announcements about new releases and patches.
Working with the source code
You can also access Shark framwork source code directly at Github which is open for reading even if your are not registered. The project is open for new developers. Volunteers are welcome. Send an email.
Setting up your development environment for J2SE and Android
You can set up our development environment with the source from GitHub. There are two options: Working with J2SE or Android. In any case, the following folder must be part of your sources:
core (interfaces and platform independent implementations of key Shark concept)
coreApps (platform independent implementations application building blocks)
j2se_android (implementations that work in Android and J2SE)
In most cases, peer should be able to communicate with e-mail. In that case, add
j2seMail to your source path. Also add javamail to your lib folder!
Those packages are sufficient to work at the framework itself. Any code works with J2SE and Android. Graphical user interface (GUI) are usually written for a specific platform. Sometimes, specific classes are required as well. Thus, in some those circumstances additional folders are required:
When working on J2SE applications, add
j2seApps to your source path. Note: Those classes might not work with Android. Also add
j2seTests to your test folder path. There are test suites under revisionTests. Choose the highest number and run the test. The test suite must run with 100% success before committing code.
When working on Android applications, add
android to your source path. Note: Those classes won't work with J2SE.
About version numbers
There is an ongoing work on Shark. In parallel, we keep our developer guide to date. As usually the code is ahead the developer guide. We use a three digit pattern to name our releases:release.major.fixes
Release is a collection of features. Each version of our developers guide describes a release. We plan to make releases backward compatible. For very good reasons we would break the rule, though.
Major number is changed whenever a new feature, methode was added to the framework. A new javadoc is created and published with each new major version.
Major number make the ongoing development process transparent. At some point in development we decide that we have enough new feature to pronounce it a new release. That triggers work on a fresh developer guide.
The final number counts fixes. A new fix release is published whenever a reasonable number of fixes are made.