This page documents the requirements for building and releasing JBoss community projects.
The purpose of these requirements is the following:
- All software license requirements are met for each JBoss project release, and thirdparty software rebuild
- To ensure build supportability, the release build must be easily reproducible at a later date. This includes releasing a fully buildable source archive with each release.
- There must be no known significant security issues in the release, and there must be minimal risk of security issues introduced during the release process (no tampering).
For each JBoss project, there must be a standard process for verifying that the project license(s) is a valid open source license, and there should be reasonable assurance that all source code contained in the project falls under this license. The results of this verification process must be saved in an easily accessible location such as a database. If any license issue is found with a project, a notification must be sent out to the JBoss community that usage of the artifact must stop until the license issue is resolved.
Source Archive Release
For each project release, a full source archive must be distributed along with any release of binary artifacts. The contents of this archive should match the contents of a source repository tag. This requirement is implied by several common open source licenses such as GPL or the Apache License.
Release Build Configuration
Any one-time build configuration that was used during the release process must be included with the source archive release. For example, any command line parameters that were used during the build, or any configuration file not included in the source repository tag.
Any thirdparty (non JBoss) projects that are distributed with JBoss project releases, must meet the same requirements as JBoss projects. This means that the license must be reviewed and the full buildable source archive must be easily available.
External Build Dependencies
To ensure build reproducibility, released builds must have a limited amount and type of external dependencies. The only external dependency allowed for a release build is an artifact repository (such as Maven) which contains only artifacts which are immutable and are uniquely identifiable (using Maven GAV or other identifier). External systems used only for testing (such as a database or other server) are an exception to this rule, and are not required to be immutable.
This section defines tasks that need to be completed in order to ensure that release builds meet the given requirements.
Create a project information database
This database will contain information about JBoss and thirdparty projects including the name of the project, the license of the project at each version, and the current status of whether the license has been reviewed.
Define a license review process
There must be a process where JBoss project developers (and other contributors) can submit a request for a project license to be reviewed. The review process must include checking the license listed for the project, and at least minimal verification of the license header information in the source files.
Create a source archive verification rule in Nexus
The JBoss.org Maven repository must have automated tools to ensure that all software releases include a fully buildable source archive.
Define a restricted build settings for JBoss and thirdparty release builds
The JBoss.org build team must define a stadard restricted build settings which controls what artifacts a release build has access to.
Define a request process for reviewing and building thirdparty artifacts
In order to ensure productive/efficient software development in the community, there must be a process by which a community member can submit a request for a thirdparty software to be reviewed and rebuilt for use in the JBoss community.
Maven has some known limitations regarding separating build time dependencies from compile and run-time dependencies. Artifacts that are shipped with a binary release must have stricter review requirements than artifacts that are only used for building and testing a release, however it is not always possible to easily separate these two.