This page includes the following guidelines:
Every project will be provided with a subversion repository. The repository will have the following default structure:
- /trunk – for the main line of development
- /branches – used for branch copies
- /tags – used for tag copies
- /apidocs – used for storing your API Documentation pages
It is the Project Captain's responsibility to decide how to use the repository and when to create a new branch or a new tag.
Project Captains (owners) and Space Cadets (contributors) receive read and write permissions to the project repository. Other users have read-only access to the repository using a web-based interface (Fisheye).
The project should conform to a number of guidelines to promote its consistency and usability among community members.
- Build should be done using Apache Ant build scripts. If custom Ant tasks are involved, all of the binaries they require should also be included with the project submission (see Project Directory Structure below).
- Typically, every project should have two build scripts – one for the project itself and one for the examples. Each Ant build script should have at least the following tasks:
- build – builds the project.
- release – creates the project downloadable release. The release will be packaged in ZIP format, along with any scripts and documents required to deploy/run it. If the project is an OpenSpaces plugin or processing unit (and not a standalone application), the distribution should preferably unzip directly into the GigaSpaces distribution to the proper directories of the GigaSpaces product:
- OpenSpaces processing units should be unzipped to the GigaSpaces deploy directory.
- OpenSpaces plug-ins should be unzipped to a directory named plugins under the product root.
- test – runs the project unit tests.
Recommended Project Directory Structure
The following directory structure is recommended for OpenSpaces.org projects. However, if you feel that different directory structure better suits your project you can use it instead.
||Describes the project – what problem it solves, how it is designed, and how it should be built and deployed.
||Describes the supplied examples – how to build and deploy them.
||Contains the implementation files of the project – project sources, project test sources and configuration files.
||Project java sources. Package names should be as follows:
|| (but highly recommended)
||Test sources – test cases should preferably (but not necessarily) use JUnit or TestNG unit test frameworks.
||3rd party libraries required to build the project.
||Project Ant build script.
||Contains the project examples.
||Contains the sources, for example <example_name>
||Examples Ant build script
Maven build support is not currently available; it will be made available when a public GigaSpaces Maven repository is created. To be notified of this change, watch this page.
All project sources should be licensed under the Apache software license version 2.0.
Source code files should include the following snippet:
* Copyright 2002-2006 the original author or authors.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
It is highly recommended to the Project Captain to create sufficient unit and integration test cases for the project and locate them according to the recommended directory structure above. It is therefore expected that every Project Captain will properly ensure the quality of the project.
Other Topics in Captain Guide