Papyrus/Papyrus Developer Guide/Build Process

Description of the build

Papyrus MDT project is currently build using the Athena Common Build. 2 hudson jobs are currently dedicated to Papyrus on the server:

• cbi-papyrus-0.7-nightly builds Papyrus from the SVN repository using the branch/0.7.X version of the code. It produces the nightly build (N) of the tool, which is provided as a p2 repository
  
• cbi-papyrus-extra builds extra plugins for Papyrus. It is dedicated for experimental tools, sub-components of the tool that should not be placed in the current distribution, etc.

Nota: A third one should be installed when the Papyrus code will be more stable, building integration (I) builds.This should be the case when the branch will be based on stable releases of Eclipse (Eclipse 3.6 Service releases) and the head will be switch to Eclipse 3.7 betas.

Hudson

Hudson is only a continuous integration build server. That means that it only control the launch of build actions. It does not defined what is inside the job itself.

Hudson also provides a nice web interface in order to:

• manage the configuration,
  
• launch the builds manually
  
• have nice reports about last builds: junit test reports, change notes, build time and size
  
• web interface corresponding to the build workspace on the server, to easilly navigate the workspace from the web.
  

cbi-papyrus-0.7-nightly

The configuration of the job (accessible from the main job page > configure) is divided into 3 parts:

• The begining describes the job itself, the rights attribution on the job, etc.
  
• The second section describes the various parameters for the build. The parameters can have different types: String, Boolean and Choice.
  

When mutli-valued, the first value is selected by default when launching the job automatically.

• The third section describes the management of source code: which repository to watch, when the build should be triggered, etc.
  
• The fourth section is the section that "does" the job: call to ant tasks mainly for Papyrus job
• The last section contains the actions post-build: how to publish the reports, which results should be available, who should receive a mail when build is unstable or broken.

How to add a plugin and or a set of plugins in the build process of Papyrus

The hudson job gathers itself sources from the Eclipse SVN repository. Doing so, the build workspace contains a set of folders, but does not know which folder contains the plugins, the features, etc. This is the role of the map file, placed in the Papyrus releng project, in the maps sub-folder. This map file describes the set of plugins placed in the SVN repository, and which version should be used. In the night build process, we are using trunk version of the plugins/features.

First of all, you have to add a bugin the papyrus bugzilla, under the Add Releng task. So we can have a trace of which plugin has been added, by who and when. See the following bug for example

Adding a plugin

• To add a plugin in the build process, it must be added to the map file of the releng project. The entries in this file are ordered as they are placed on the SVN repository. For maintenance purpose, the new plugin should be placed using this order. As building the papyrus tool, the build process will checkout files using the information of the map file.
  
• The second step is to add it as a packaged plugin to an existing feature or create a new feature that will be added to the build process (See Adding a feature below).
• Commit your modifications to the SVN repository (map file in the releng project, feature referencing this packaged plugin, and your plugin itself)
• You can then manually lauch the build to test the new configuration using the "Launch a build" button on the left side of the window. If you do not see the button, you are not connected as a papyrus commiter.
  

Adding a feature

• To add a feature in the build process, it also has to be added to the map file of the releng project. Do not forget to add also the plugins packaged in this feature, following previous chapter.
  
• You must then reference this feature in the main papyrus feature or the feature requiring your new feature.
  
• Commit your modifications to the SVN repository (map file in the releng project, feature referencing this new feature, and your feature itself)
  
• Finally, manually launch a build to test the configuration.

If the build works, do not forget to close the bugzilla task created in the first point.

Special Thanks

I would like to thank Nick Boldt and the Modisco team for their  help during the initialization of the build process. You can find details about the Athena Build Process in the Modisco Releng part in the Eclipse Wiki