Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RMF/Contributor Guide/Build Process"

< RMF
m (IP Log)
(16 intermediate revisions by 3 users not shown)
Line 12: Line 12:
 
(17-Jan-2012) There has been a lot of discussion on rmf-dev.  Some of the confusion stems from sloppy terminology.  Therefore, here a little glossary:
 
(17-Jan-2012) There has been a lot of discussion on rmf-dev.  Some of the confusion stems from sloppy terminology.  Therefore, here a little glossary:
  
; Release : A Release is a super-official artifact that is typically published after reaching a number of milestones and building a few release candidates.  A Release of RMF is somewhere in the far future and not yet planned.
+
; Release : A Release is a super-official artifact that is typically published after reaching a number of milestones and building a few release candidates.  The first release is planned for April 1st, 2014 (not a joke :-)).
; Milestone :  A milstone is a well-defined point towards a release.  No milestones are yet planned for RMF.
+
; Milestone :  A milstone is a well-defined point towards a release.  For now, we create milestones informally if we need an intermediate well-defined build.
; Release Candidate : After the last milestone before a release, one or more release candidates are built.  No major features may go into a RC, only bug fixes.
+
; Release Candidate : After the last milestone before a release, one or more release candidates are built.  No major features may go into a RC, only bug fixes.  As of this writing, release candidates are not used.
 
; Nightly Built : A nightly built is typically generated by an continuous integration system, based on the latest code in the repository  (''develop'' branch in Git) and may be instable.  It is published, so that daring users can try it out. As we currently don't have a CI system, we don't have nightly builts.
 
; Nightly Built : A nightly built is typically generated by an continuous integration system, based on the latest code in the repository  (''develop'' branch in Git) and may be instable.  It is published, so that daring users can try it out. As we currently don't have a CI system, we don't have nightly builts.
; Snapshot : Similar to a nightly built, but built on demand from the latest sources and published (''master'' branch in Git).
+
; Snapshot : '''Deprecated!''' Similar to a nightly built, but built on demand from the latest sources and published (''master'' branch in Git).
 
; Integration : We use the term "Integration" to mark the end of a development iteration.  We use a schedule-driven (rather than feature-driven) development process.  Integrations are created in the Milestone-Field in Bugzilla.  At the beginning of a development iteration, all bugs are reviewed by the team and assigned to an integration.
 
; Integration : We use the term "Integration" to mark the end of a development iteration.  We use a schedule-driven (rather than feature-driven) development process.  Integrations are created in the Milestone-Field in Bugzilla.  At the beginning of a development iteration, all bugs are reviewed by the team and assigned to an integration.
  
=== Release Process ===
+
=== Milestone Process ===
  
The RMF build process is inspired by the [http://nvie.com/posts/a-successful-git-branching-model/ Git Flow Process]. Most of the text used in this chapter are citations from [http://nvie.com/posts/a-successful-git-branching-model/]. In general, this section describes a step by step instruction how to create a new snapshot version of RMF.
+
Milestones are identified by a tag in git and by being located in the milestone folder, for binaries. Milestones are marked as follows, assuming Milestone 1 of RMF 0.10.0:
  
===== Prepare release =====
+
* '''git Tag name:''' milestone-0.10.0-M1
 +
* '''Subfolder  name for binaries''' (somewhere underneath a '''milestone''' folder): 0.10.0-M1
  
Review and revise the [[RMF/Roadmap|Roadmap]]. Review open issues (bugs and feature requests) and check if all bugs have been fixed and all feature requests have been implemented scheduled for this snapshot release. Not fixed bugs and not implemented feature request are assigned to the upcoming snapshot release.
+
=== Release Process ===
  
===== Creating a release branch =====
+
The RMF build process is inspired by the [http://nvie.com/posts/a-successful-git-branching-model/ Git Flow Process]. Most of the text used in this chapter are citations from [http://nvie.com/posts/a-successful-git-branching-model/]. In general, this section describes a step by step instruction how to create a new release of RMF.
  
Release branches are created from the ''develop'' branch. For example, say the next snapshot version is 0.4.0. Use the following git command to create a new release branch:
+
===== '''(1) Prepare release''' =====
  
  $ git checkout -b snapshot-release-0.4.0 develop
+
* Review and revise the [[RMF/Roadmap|Roadmap]]. Review open issues (bugs and feature requests) and check if all bugs have been fixed and all feature requests have been implemented scheduled for this release. Not fixed bugs and not implemented feature request are assigned to the upcoming release.
 +
* Check if the rmf-nightly build ([https://hudson.eclipse.org/hudson/job/rmf-nightly/]) builds without errors. Please fix the build, in case of an corrupt build.
  
====== Bump version numbers ======
+
===== '''(2) Merge develop branch into master branch''' =====
  
After creating a new release branch and switching to it, we bump the version number. This is still a manual task which is cumbersome and error prone, since, there are many places to bump the version number. We have to improve this. There is already a bug entry for this task: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388421
+
Use the following git commands to merge the develop branch into the master branch:
 
+
At the following places you have to bump the version number:
+
 
+
* In all '''plugin.xml''' and '''feature.xml''' files in the corresponding org.eclipse.rmf.* plugin or features respectively. '''PLEASE NOTE: you have to keep the ''.qualifier'' postfix of all version numbers.'''
+
* In all '''pom.xml''' files in the corresponding org.eclipse.rmf.* plugin or features respectively. '''PLEASE NOTE: you have to keep the ''-SNAPSHOT'' postfix of all version numbers.'''
+
* In the '''rmf-pror-standalone.product''' file in the org.eclipse.rmf.releng.product.
+
* In the '''category.xml''' file in the org.eclipse.rmf.releng.repository.
+
* Take care of the dependencies: In the '''MANIFEST.MF''' files in the corresponding org.eclipse.rmf.* plugin or features respectively.
+
 
+
Finally, commit the bumped version numbers:
+
 
+
$ git commit -a -m "Bumped version number to 0.4.0"
+
 
+
====== Apply additional bug fixes ======
+
 
+
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.
+
 
+
===== Finishing a release branch =====
+
 
+
When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.
+
 
+
Use the following git commands to finish the release branch:
+
  
 
  $ git checkout master
 
  $ git checkout master
  $ git merge --no-ff snapshot-release-0.4.0
+
  $ git merge --no-ff develop
 
+
To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:
+
 
+
$ git checkout develop
+
$ git merge --no-ff snapshot-release-0.4.0
+
 
+
This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.
+
 
+
Now we are really done and the release branch may be removed (since we don’t need it anymore) and the develop and master branch can be pushed:
+
 
+
$ git branch -d snapshot-release-0.4.0
+
 
  $ git push
 
  $ git push
  
===== Creating a tag =====
+
Now check that the Git revision ID on Hudson is still the one you have now in the master branch.
  
The next step consists of creating a tag for the snapshot release. In Git:
+
===== '''(3) Creating a tag''' =====
  
$ git tag -a snapshot-0.4.0-yyyymmddhhmm
+
The next step consists of creating a tag for the release. In Git:
  
The question is: How to find out yyyymmddhhmm? Well, this is currently also a cumbersome task. However, this is our current process: Since, we pushed in the last step our changes to the develop and master branch, our RMF jenkins build is triggered. Checkout the last successful build and get for instance the time stamp from the product file name. For instance, if the file name is ''eclipse-rmf-pror-0.3.2-nightly-201208292301-incubation-win32.win32.x86.zip'' the time stamp to be used is: ''201208292301''.
+
  $ git tag -a release-0.4.0
 
+
'''PLEASE NOTE: Switch back to the master branch in order to create a tag!'''
+
 
+
So the final Git command would be:
+
 
+
  $ git tag -a snapshot-0.4.0-201208292301
+
  
 
No we have to push our tag. In Git:
 
No we have to push our tag. In Git:
  
  $ git push origin snapshot-0.4.0-201208292301
+
  $ git push origin release-0.4.0
  
===== Publish Artifacts =====
+
===== '''(4) Publish Artifacts''' =====
  
In the last step you have to publish the different artifacts, which can be found in jenkins in the last successful build section:
+
In the next step you have to publish the different artifacts, which can be found in Jenkins in the last successful build section:
  
* ProR Standalone zip files
 
 
* RMF Feature update site
 
* RMF Feature update site
* RMF Product update site
 
 
Download all files on your local machine and replace the ''nightly'' to ''snapshot'' in all ProR standalone product zip files. For instance, ''eclipse-rmf-pror-0.3.2-nightly-201208292301-incubation-linux.gtk.x86.zip'' will be renamed to ''eclipse-rmf-pror-0.3.2-snapshot-201208292301-incubation-linux.gtk.x86.zip''.
 
  
 
Put the different files in the correct folders on the eclipse server. The RMF download folder structure is well documented: [[RMF/Contributor_Guidline/Build_Process#Download_Folder_Structure]].
 
Put the different files in the correct folders on the eclipse server. The RMF download folder structure is well documented: [[RMF/Contributor_Guidline/Build_Process#Download_Folder_Structure]].
  
Edit the two files ''compositeArtifacts.xml'' and ''compositeContent.xml'' in the ''updates'' and ''product-updates'' folders and add a new line in the ''children'' section pointing to the new snapshot version.
+
Edit the two files ''compositeArtifacts.xml'' and ''compositeContent.xml'' in the ''updates'' folder and add a new line in the ''children'' section pointing to the new release version.
  
Here is an example, showing the ''compositeContent.xml'' file, where we added the new snapshot version 0.4.0:
+
Here is an example, showing the ''compositeContent.xml'' file, where we added the new release version 0.4.0:
  
 
  <?xml version='1.0' encoding='UTF-8'?>
 
  <?xml version='1.0' encoding='UTF-8'?>
Line 116: Line 75:
 
   </properties>
 
   </properties>
 
   <children size='3'>
 
   <children size='3'>
  <child location='snapshot/0.3.1'/>
+
  <child location='releases/0.3.1'/>
  <child location='snapshot/0.3.2'/>
+
  <child location='releases/0.3.2'/>
         <child location='snapshot/0.4.0'/>
+
         <child location='releases/0.4.0'/>
 
   </children>
 
   </children>
 
  </repository>
 
  </repository>
Line 124: Line 83:
 
'''PLEASE NOTE: You have to increase the ''size'' attribute of the ''children'' tag!'''
 
'''PLEASE NOTE: You have to increase the ''size'' attribute of the ''children'' tag!'''
  
Repeat this for the other files in the ''updates'' and ''product-updates'' folders.
+
===== '''(5) Bump version numbers''' =====
 +
 
 +
'''PLEASE NOTE: Switch back do the deveop branch!'''
 +
 
 +
In the last you have to bump the version numbers to the next version (in our case version 0.5.0). This is still a manual task which is cumbersome and error prone, since, there are many places to bump the version number. We have to improve this. There is already a bug entry for this task: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388421
 +
 
 +
At the following places you have to bump the version number:
 +
 
 +
* In all '''plugin.xml''' and '''feature.xml''' files in the corresponding org.eclipse.rmf.* plugin or features respectively. '''PLEASE NOTE: you have to keep the ''.qualifier'' postfix of all version numbers.'''
 +
* In all '''pom.xml''' files in the corresponding org.eclipse.rmf.* plugin or features respectively. '''PLEASE NOTE: you have to keep the ''-SNAPSHOT'' postfix of all version numbers.'''
 +
* In the '''rmf-pror-standalone.product''' file in the org.eclipse.rmf.releng.product.
 +
* In the '''category.xml''' file in the org.eclipse.rmf.releng.repository.
 +
* Take care of the dependencies: In the '''MANIFEST.MF''' files in the corresponding org.eclipse.rmf.* plugin or features respectively.
 +
 
 +
Finally, commit and push the bumped version numbers:
 +
 
 +
$ git commit -a -m "Bumped version numbers to 0.5.0"
 +
$ git push
  
 
We are done! :)
 
We are done! :)
Line 193: Line 169:
 
*rmf (root folder)
 
*rmf (root folder)
 
**updates (Contains the different feature updates sites)
 
**updates (Contains the different feature updates sites)
***snapshot (Contains the update sites for the snapshot builds)
+
***snapshot (Contains the update sites for the snapshot builds) ('''Since version 0.10.0 deprecated!''')
 
**** <version number> (e.g. 0.1.0)
 
**** <version number> (e.g. 0.1.0)
**product-updates (Contains the different product updates sites)
+
***releases (Contains the update sites for the release builds)
***snapshot (Contains the update sites for the snapshot builds)
+
 
**** <version number> (e.g. 0.1.0)
 
**** <version number> (e.g. 0.1.0)
**downloads (Contains all other artifacts like RCP builds)
+
***latest (Contains the update site for the latest build from Jenkins)
**** drops
+
**** This folder contains a reference to [https://hudson.eclipse.org/hudson/job/rmf-nightly/lastSuccessfulBuild/artifact/update-site/].
***** <version number> (e.g. 0.1.0)
+
***milestones (Contains the milestone builds)
****** S<buildstamp> (Snapshot build artifacts)
+
**** <version number> (e.g. 0.1.0-M1 for milestone build version 0.1.0 M1)
 +
**product-updates (Contains the different product updates sites) ('''Since version 0.10.0 deprecated!''')
 +
**downloads (Contains all other artifacts like RCP builds) ('''Since version 0.10.0 deprecated!''')
  
 
Since, the RMF download page is automatically build based on this structure, it is important to keep it!
 
Since, the RMF download page is automatically build based on this structure, it is important to keep it!
Line 254: Line 231:
 
For the sake of evaluation an initial build system that is based on Tycho is now available in the development branch for the RMF repository.
 
For the sake of evaluation an initial build system that is based on Tycho is now available in the development branch for the RMF repository.
 
In order to make use of the Tycho build scripts in your local workspace please install the Maven support for Eclipse m2eclipse. In the workspace you will find the following projects that are related to building the projects
 
In order to make use of the Tycho build scripts in your local workspace please install the Maven support for Eclipse m2eclipse. In the workspace you will find the following projects that are related to building the projects
* '''org.eclipse.rmf.releng''' contains the parent pom file which is the starting point for the build. When starting the pom file, you will need to select a target platform. This is done by selecting the profile INDIGO_3_7_1.target
+
* '''org.eclipse.rmf.releng''' contains the parent pom file which is the starting point for the build. When starting the pom file, you will need to select a target platform. This is done by selecting the profile platform-juno, platform-kepler, kepler-luna or platform-mars
 
* '''org.eclipse.rmf.releng.target''' contains the target definition
 
* '''org.eclipse.rmf.releng.target''' contains the target definition
 
* '''org.eclipse.rmf.releng.repository''' contains the configuration for generating a p2 repository (update-site) (the update site is created into /target/repository)
 
* '''org.eclipse.rmf.releng.repository''' contains the configuration for generating a p2 repository (update-site) (the update site is created into /target/repository)

Revision as of 04:52, 19 March 2015

We're still in the incubator phase - therefore, the release process is still being developed. Here are our guidelines so far:

The Most Important Stuff

  • Our release manager is Lukas Ladenberger. Please coordinate with Lukas.
  • We use the Git Flow Process as our release process
  • Important: Never commit to master! (unless you are the release manager). Development takes place on the develop branch.
  • The only branches on the server are master and develop. All other branches that are mentioned in git-flow are local branches

Glossary

(17-Jan-2012) There has been a lot of discussion on rmf-dev. Some of the confusion stems from sloppy terminology. Therefore, here a little glossary:

Release 
A Release is a super-official artifact that is typically published after reaching a number of milestones and building a few release candidates. The first release is planned for April 1st, 2014 (not a joke :-)).
Milestone 
A milstone is a well-defined point towards a release. For now, we create milestones informally if we need an intermediate well-defined build.
Release Candidate 
After the last milestone before a release, one or more release candidates are built. No major features may go into a RC, only bug fixes. As of this writing, release candidates are not used.
Nightly Built 
A nightly built is typically generated by an continuous integration system, based on the latest code in the repository (develop branch in Git) and may be instable. It is published, so that daring users can try it out. As we currently don't have a CI system, we don't have nightly builts.
Snapshot 
Deprecated! Similar to a nightly built, but built on demand from the latest sources and published (master branch in Git).
Integration 
We use the term "Integration" to mark the end of a development iteration. We use a schedule-driven (rather than feature-driven) development process. Integrations are created in the Milestone-Field in Bugzilla. At the beginning of a development iteration, all bugs are reviewed by the team and assigned to an integration.

Milestone Process

Milestones are identified by a tag in git and by being located in the milestone folder, for binaries. Milestones are marked as follows, assuming Milestone 1 of RMF 0.10.0:

  • git Tag name: milestone-0.10.0-M1
  • Subfolder name for binaries (somewhere underneath a milestone folder): 0.10.0-M1

Release Process

The RMF build process is inspired by the Git Flow Process. Most of the text used in this chapter are citations from [1]. In general, this section describes a step by step instruction how to create a new release of RMF.

(1) Prepare release
  • Review and revise the Roadmap. Review open issues (bugs and feature requests) and check if all bugs have been fixed and all feature requests have been implemented scheduled for this release. Not fixed bugs and not implemented feature request are assigned to the upcoming release.
  • Check if the rmf-nightly build ([2]) builds without errors. Please fix the build, in case of an corrupt build.
(2) Merge develop branch into master branch

Use the following git commands to merge the develop branch into the master branch:

$ git checkout master
$ git merge --no-ff develop
$ git push

Now check that the Git revision ID on Hudson is still the one you have now in the master branch.

(3) Creating a tag

The next step consists of creating a tag for the release. In Git:

$ git tag -a release-0.4.0

No we have to push our tag. In Git:

$ git push origin release-0.4.0
(4) Publish Artifacts

In the next step you have to publish the different artifacts, which can be found in Jenkins in the last successful build section:

  • RMF Feature update site

Put the different files in the correct folders on the eclipse server. The RMF download folder structure is well documented: RMF/Contributor_Guidline/Build_Process#Download_Folder_Structure.

Edit the two files compositeArtifacts.xml and compositeContent.xml in the updates folder and add a new line in the children section pointing to the new release version.

Here is an example, showing the compositeContent.xml file, where we added the new release version 0.4.0:

<?xml version='1.0' encoding='UTF-8'?>
<?compositeArtifactRepository version='1.0.0'?>
<repository name='"RMF Feature Update Site"'
    type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository' version='1.0.0'>
  <properties size='1'>
    <property name='p2.timestamp' value='1243822502440'/>
  </properties>
  <children size='3'>
	<child location='releases/0.3.1'/>
	<child location='releases/0.3.2'/>
        <child location='releases/0.4.0'/>
  </children>
</repository>

PLEASE NOTE: You have to increase the size attribute of the children tag!

(5) Bump version numbers

PLEASE NOTE: Switch back do the deveop branch!

In the last you have to bump the version numbers to the next version (in our case version 0.5.0). This is still a manual task which is cumbersome and error prone, since, there are many places to bump the version number. We have to improve this. There is already a bug entry for this task: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388421

At the following places you have to bump the version number:

  • In all plugin.xml and feature.xml files in the corresponding org.eclipse.rmf.* plugin or features respectively. PLEASE NOTE: you have to keep the .qualifier postfix of all version numbers.
  • In all pom.xml files in the corresponding org.eclipse.rmf.* plugin or features respectively. PLEASE NOTE: you have to keep the -SNAPSHOT postfix of all version numbers.
  • In the rmf-pror-standalone.product file in the org.eclipse.rmf.releng.product.
  • In the category.xml file in the org.eclipse.rmf.releng.repository.
  • Take care of the dependencies: In the MANIFEST.MF files in the corresponding org.eclipse.rmf.* plugin or features respectively.

Finally, commit and push the bumped version numbers:

$ git commit -a -m "Bumped version numbers to 0.5.0"
$ git push

We are done! :)

Conventions

Version Numbers

We have version numbers for:

  • Plugins
  • Features
  • Product
  • Project

We have the following rules:

  • While in the incubation phase, all major version numbers remain 0.
  • While in the incubation phase, we will always generate qualifiers.
  • Plugins: The minor and service numbers are incremented according to the Eclipse version rules.
  • Features: The minor and service numbers are incremented according to the Eclipse version rules.

We have not decided yet what to do about the version number of product and project. One suggestion is:

  • Create an "overarching" feature that aggregates all other features (e.g. an SDK Feature). Once such a feature is created, its version number is incremented according to the Eclipse version rules. Use the same version number for the product.

(mj) I don't quite like this, as it feels arbitrary and rather meaningless. OTOH, it would work and is kind of predictable.

Once we leave incubator phase, we will join the Eclipse release train and therefore conform the the relase train requirements. The major version number will graduate beyond zero, once we leave incubation. For now, the plugin and feature name must follow a (Incubation) mark.

GIT

  • We will tag snapshots as snapshot-0.1.0-yyyymmddhhmm (yyyymmddhhmm <=> qualifier).
  • Only the release manager creates tags.

Publishing Artifacts

Only snapshots artifacts will be published, both as stand-alone builds and update site builds. Nightly builds are available via Jenkins and won't be published!

Snapshot-Release Checklist: Before publishing a snapshot, update the snapshot release checklist (it is located in the dump folder in git). (HTML version)

We still have to figure out how the version number is constructed, the git tag is appended. Examples for the ProR standalone version:

  • eclipse-rmf-pror-0.1.0-snapshot-yyyymmddhhmm-incubation-linux.gtk.x86.zip
  • eclipse-rmf-pror-0.1.0-nightly-yyyymmddhhmm-incubation-linux.gtk.x86.zip

yyyymmddhhmm <=> qualifier

Product and Update Site Structure

Rmf product update structure.jpg

Development Process

For now, we use a schedule-driven, iterative development process. An iteration is 8 weeks long and consists of the following steps:

  • Review and revise the Roadmap
  • Review open issues (bugs and feature requests) and decide which issues should be resolved in the upcoming iteration. Those issues will be assigned to the corresponding integration (e.g. i12.03 for the March 2012 integration).
  • Developers get busy implementing.
  • At the end of the iteration, a snapshot is published, both in the form of a product built and update site (Bonus: once we have a CI system, this is probably just a link to the corresponding nightly built).
  • Rinse, repeat.

Download Folder Structure

Currently, we have the following download folder structure:

  • rmf (root folder)
    • updates (Contains the different feature updates sites)
      • snapshot (Contains the update sites for the snapshot builds) (Since version 0.10.0 deprecated!)
        • <version number> (e.g. 0.1.0)
      • releases (Contains the update sites for the release builds)
        • <version number> (e.g. 0.1.0)
      • latest (Contains the update site for the latest build from Jenkins)
        • This folder contains a reference to [3].
      • milestones (Contains the milestone builds)
        • <version number> (e.g. 0.1.0-M1 for milestone build version 0.1.0 M1)
    • product-updates (Contains the different product updates sites) (Since version 0.10.0 deprecated!)
    • downloads (Contains all other artifacts like RCP builds) (Since version 0.10.0 deprecated!)

Since, the RMF download page is automatically build based on this structure, it is important to keep it!

More information: [4].

Release Reviews

All official Releases must have a successful Release Review before being made available for download. The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse [5]. More information about a Release Review can be found at: Development_Resources/HOWTO/Release_Reviews.

IP Log

The Development_Resources/IP_Log is an important artifact within the release review. The log tracks

  • Licenses;
  • Past and present committers;
  • Third-party libraries; and
  • Contributions from outside the project (i.e. non-committers)

The Eclipse Ecosystem provides a tool for automatically generating the IP Log from git, bugzilla, ipzilla, etc. The automatic IP Log of the RMF project is available at: [6]

To fully leverage the value of the Automated IP Log Tool, you need to:

Notes
  • The IP Contribution Review Tool [8] can help finding IP issues in Bugzilla.
  • To look up if a contributor has a valid Contributor License Agreement: [9]
  • To check if all required CQs are available please check the content of the dowload directory: [10]

Release Engineering

Note: This is an initial PROPOSAL for the RMF build system. It is still under discussion.

Requirements

  • The build system shall run on the local workstation as well as on the Eclipse build server [11]
  • The build system shall create the following artifacts:
    • update site
    • standalone executables for windows, linux, mac
  • The build system shall support automated
    • test execution
    • static code analysis
    • javadoc generation
  • The build system shall be based on a technology that is recommended by the Eclipse foundation. This will reduce maintenance costs and it is more likely to get support and find documentation.

Build Infrastructure

In order to be able to maintain Eclipse Software for a long period of time, the Eclipse Foundation has started the Long Term Support Program LTS. Although it is acceptable to have different build systems within the Eclipse Community Build Technologies it is recommended to use the Eclipse Common Build Infrastructure CBI. From a technology point of view, the CBI is a combination of Hudson, Maven, Tycho, and build signing.

For the sake of evaluation an initial build system that is based on Tycho is now available in the development branch for the RMF repository. In order to make use of the Tycho build scripts in your local workspace please install the Maven support for Eclipse m2eclipse. In the workspace you will find the following projects that are related to building the projects

  • org.eclipse.rmf.releng contains the parent pom file which is the starting point for the build. When starting the pom file, you will need to select a target platform. This is done by selecting the profile platform-juno, platform-kepler, kepler-luna or platform-mars
  • org.eclipse.rmf.releng.target contains the target definition
  • org.eclipse.rmf.releng.repository contains the configuration for generating a p2 repository (update-site) (the update site is created into /target/repository)
  • org.eclipse.rmf.releng.product contains the configuration for generating the RMF standalone products (the products are created into /target/products)

All other features, plugins and tests are extended by a pom file. Project specific configuration should be done here. For adding new test cases to the build system, please create a test suite class that follows the naming pattern 'All*Tests.java'

Back to the top