README.OPENDAYLIGHT

   1 DIRECTORY ORGANIZATION
   2 ======================
   3 - third-party: contains all the third-party artifacts than needed
   4 repackaging or needed code modifications.
   5 - third-party/commons: contains all the parent POM files for the
   6 projects under the third-party directory. Only one is expected, which
   7 is the one located under third-party/commons/third-party, but there is
   8 a directory just in case we need to host more with different
   9 variations.
  10 - opendaylight: contains all the artifacts that constitute the
  11 controller project.
  12 - opendaylight/distribution: contains all the distributions that can
  13 be generated by packaging the several artifact. In practice for now
  14 there are two:
  15       - "opendaylight", which is the full distribution of the controller
  16 The idea of the distribution directory is that more distribution can
  17 be added at will, maybe just composing subsets of the whole controller
  18 artifact set.
  19
  20 HOW TO BUILD
  21 ============
  22 In order to build it's required to have JDK 1.7+ and Maven 3+, to get
  23 a build going it's needed to:
  24 1) From the root directory run
  25    "mvn clean install"
  26 2) On succesfull completion go in the directory:
  27 "opendaylight/distribution/opendaylight/target"
  28
  29 to pick the zip file of the distribution or controller can be executed
  30 right from there going into the distribution directory.
  31
  32 Please note that this way no integration tests but only UT will be
  33 executed, if you are planning on committing code be aware that the
  34 code will be tested also for Integrations tests hence make sure before
  35 submitting a patch to build using the command:
  36    "mvn clean install -Pintegrationtests"
  37 to get IT executed.
  38
  39 HOW TO RELEASE ARTIFACTS
  40 ========================
  41 Artifacts can be released in a bulk fashion or one by one depending on
  42 the need. Bulk release works well when in the need of establishing a
  43 baseline, for example on an upcoming major release. Single artifact
  44 release is useful for example for API bundles which are supposed to be
  45 used by others, this in fact seal the contract for that given version
  46 and others can rest assured won't change because the maven repository
  47 will not allow a the same artifact with the same version to be
  48 re-deployed.
  49
  50 HOW TO BULK RELEASE ARTIFACTS
  51 -----------------------------
  52 Bulk release of the artifacts MUST be done only and exclusively by
  53 using the pom.xml present in the same directory of this
  54 README.OPENDAYLIGHT file. The pom.xml is just a pointer to the main
  55 distribution directory or in general to the one containing all the
  56 modules needs release.
  57 To perform the release from the top level just run:
  58
  59 mvn -B release:prepare release:perform -Dgoals=deploy
  60
  61 Well this is not supposed to be executed by a human but by an apposite
  62 Jenkins job because no committer or contributor has the necessary
  63 privileges to escape the code review process needed by the release
  64 process, but this is the logic behind.
  65
  66 HOW TO RELEASE ONE ARTIFACT
  67 ---------------------------
  68 1) Make sure the artifact doesn't depend on SNAPSHOT  artifacts, as a
  69 corollary it means that also the parent pom must be a released
  70 artifact which then will not be present in the repo, so for this kind
  71 of artifacts it's mandatory to provide a repository section to let it
  72 download the parent from Opendaylight maven repository
  73 2) Make sure all the dependencies are also non-SNAPSHOT
  74 3) Via apposite Jenkins job make sure that the goals:
  75
  76 mvn -B release:prepare release:perform -Dgoals=deploy
  77
  78 is called.
  79
  80 [NOTE WELL]
  81 The pom.xml in the root level is simply a pointer to the main
  82 distribution but is needed to overcome some of the limitations in the
  83 release process.
  84
  85 Thanks!!