Repository Management Policy
This page describes WebLab team policy to deploy, tag and release of WebLab elements.
SVN access to WebLab repository is:
WebLab repository is separated in three parts: Trunk, Branches and Tags. Developement in each part is guided by a simple set of common rules.
These simple set of rules MUST be applied before each modification of the repository:
- The creation of a new projet or any change in the repository MUST be linked to a Jira request containing rationals (new feature, improvement or bug fix).
- Before any commit, you MUST check that your changes do not break unitary tests of impacted projects.
- Any modification of the hierarchy (sub-hierarchy) MUST be discussed and approved on the WebLab dev mailing list.
- Any architectural change, i.e. anything that goes beyond the internal process of a component (I/O of a service, I/O of a portlet, ...) MUST be discussed and approved on the WebLab dev mailing list.
The trunk part contains active developments. It is divided in 6 sub-parts:
This part contains the exchange model of the WebLab (i.e. XML model, ontologies and simple associated classes).
This part contains helpers to ease RDF work with WebLab Resources.
This parts contains all available components, services and portlets used by the WebLab platform.
This part contains projects to build full WebLab applications. The demo bundle is an exemple.
This part contains service engine for the bus and orchestration engine (PEtALS or Karaf+Camel) of WebLab platform.
This part contains external tools that are not necessary to build the platform but ease development (maven plugin, eclipse plugin ...).
Releases for WebLab Core are based on stable versions of WebLabExchangeModel AND WebLabHelpers.
Releases for WebLab Demo are based on stable versions of WebLab Core, WebLabServices, WebLabEngines AND WebLabApplications.
Branches part follows the same structure that the trunk but it contains projets on previous WebLab Core version that must still be maintained. It also contains WebLab platform applications as examples of WebLab features (i.e. for demonstration purposes)
The same set of rules apply to the Incubation part than ones on the Branches part. Moreover, all issues about incubation project must explicitly refer to an incubation tag.
Incubation projects can be found at the following address in the SVN:
What must I do to propose a new project in incubation:
- Send a mail to the dev mailing list (email@example.com) to explain the project and its rational
- Once the project is accepted, create a FT into jira to publish the creation of the incubation project: http://jira.ow2.org/browse/WEBLAB
- Your project groupid must start with org.ow2.weblab.incubation
How can my incubation project become a WebLab project:
- Make sure you are using lastest stable WebLab Core
- Make sure you have written documentation
- Make an argumented request on the dev mailing list (firstname.lastname@example.org) to ask to become a normal WebLab project
- If it is accepted then you can move your incubation project to make developement line.
Tags part follows the same structure that the trunk but it contains only stable version of sub-projects that have been tested and are documented, or being documented on this website. Each tag must be available as a maven artifact in the official repository or at least be available as an archive or binary to download from the Download page.
An other set of rules also apply on tags part:
- Before tagging a new version;
- you MUST check that tests are not failing
- you MUST write/update the documentation of the project on this website
- you MUST create the corresponding FT for tagging version in Jira
- you MUST make sure that the maven artifact or archive is available (from maven repository or direct download)
- Tagging a new version;
- you MUST keep the existing hierarchy coherent.
For example, if you want to tag the version 1.2.5 of the WebLab model, you must tag it at the following url
The version 1.1 of the simple repository web service must be tagged at the following url:
where X.X.X is the version of the project.
- After tagging a new version:
- you MUST broadcast the release of this version in the dev and user WebLab mailing list.
- you MUST update the Download web page
- you MUST wait a complete day before committing on the trunk again to update to the next version OR contact WebLab team members to perform a release.
This part covers artifact/binary archive/documentation release.
When to deploy a new release
"When it's done !" might not be the best solution. Sometimes, one could prefer make a new release to provides new features or correct crashes without correcting all FTs.
However, before each release, you have to validate that your project is coherent with other WebLab elements:
- for a portlet, check that send and received events are correctly supported by other stable WebLab portlets
- for a service, check that generated WebLab Resources are compatible with all other stable WebLab elements (your searcher must work with the result portlet, your normaliser must add hasNormalisedContent property ...)
- for binary archives, check that is works on the maximum available platforms; Windows, Linux flavours, MacOs...
- for documentation, check with other team members that it is complete and understandable
How to deploy a new release
To deploy a new release, you can release it on OW2:
- for maven artifacts, deploy them on OW 2 maven repository with :
mvn deploy -DperformRelease=true
- for binary archives, you can upload them on the OW forge weblab page : http://forge.ow2.org/project/showfiles.php?group_id=357
- for documentation, you can update this wiki or release your documentation on the OW2 forge: http://forge.ow2.org/docman/?group_id=357