Getting started in OpenDaylight can be a bit intimidating, but most of the infrastructure vanishes into the background pretty quickly as you get things set up and used to the workflow.
New Project Checklist
Here are the tasks you're going to want to do
- Make sure you have a git repository (visible in gerrit)
- Go to https://git.opendaylight.org/
- Click "Projects" on the left under the OpenDaylight logo
- Click "List" under projects
- Verify your project is listed with the right repo name
- Make sure your Jenkins jobs are created
- Go to https://jenkins.opendaylight.org/releng/
- Look for a tab at the top for your project and click on it
- Make sure you have at least <repo-name>-verify-master, <repo-name>-merge-master, and <repo-name>-daily-master jobs
- If the jobs do not exist follow the instructions from the releng/builder Jenkins documentation to configure your jobs. RelEng/Builder Jenkins page
- Verify that your jenkins jobs work
- Test verify by pushing a patch and seeing that the verify job runs and successfully posts a "verified +1" to the gerrit.
- Then merge the patch and make sure that the merge job runs successfully and pushes artifacts in Nexus.
- After the job runs, go to http://nexus.opendaylight.org/
- Search for your project's name and see if the artifacts you expect are there.
- Optionally, test your integration jobs by manually triggering them.
- Make sure you have a bugzilla entry for your project
- Go to https://bugs.opendaylight.org/
- Click "File a Bug"
- Make sure your project appears in the list
- Make sure you have a mailing list, usually just <repo-name>-dev
- Go to https://lists.opendaylight.org/
- Make sure there is a list named <repo-name>-dev
- Subscribe to the list with an e-mail you actually check
- Make a main wiki page using the Project Facts template
- Make sure you're subscribed to:
- Your mailing list (described above) so you get mail about your project
- Your gerrit so you can tell when people push patches to your project (see Communication:Gerrit for how to subscribe to events from your project)
- At least one representative from your project should either (i) attend the TSC calls, (ii) subscribe to the TSC mailing list, or (iii) read the TSC meeting minutes.
- Ideally, a project representative should do all three.
- The Jenkins mailing list, filtered for the topic equal to your project name. Test failures will be reported to this list.
- Set up your pom file structure according to project layout best practice
- A good way to do this to use the Project Startup Archetype, but replace the example module and hello world RPC with the beginnings of your own project
- Your project should have a parent pom file that should be the root of your 'pom tree'
- It's parent should be the odlparent pom file
- All version numbers should be put into one of these two pom files, not hard-coded in other pom files
- Default Version numbers from the "Startup Project Archetype" are not up to date. So, please update the version numbers in all the files generated.
- Example to change the version numbers - https://git.opendaylight.org/gerrit/#/c/28662/
- Certain pom files should use special parent poms, e.g., the karaf-parent in controller to build Karaf distributions. Other useful parent pom files to know about are:
- Set up your JaCoCo code coverage reporting
- See Jacoco plugin Setup below
- Currently, this only works for Java
Taking Advantage of Project Infrastructure
There is a detailed overview of the Development Infrastructure that will give you a good conceptual framework. Most of what is written here is about concrete getting things done stuff :)
Jacoco plugin Setup
Please follow these simple steps to report unit and integration test code coverage to Sonar