Skip to content

Midokura's fork of the OpenDaylight Controller project

License

Notifications You must be signed in to change notification settings

Kullu14/odp-controller

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DIRECTORY ORGANIZATION
======================
- third-party: contains all the third-party artifacts than needed
repackaging or needed code modifications.
- third-party/commons: contains all the parent POM files for the
projects under the third-party directory. Only one is expected, which
is the one located under third-party/commons/third-party, but there is
a directory just in case we need to host more with different
variations.
- opendaylight: contains all the artifacts that constitute the
controller project.
- opendaylight/distribution: contains all the distributions that can
be generated by packaging the several artifact. In practice for now
there are two:
      - "opendaylight", which is the full distribution of the controller
The idea of the distribution directory is that more distribution can
be added at will, maybe just composing subsets of the whole controller
artifact set.

HOW TO BUILD
============
In order to build it's required to have JDK 1.7+ and Maven 3+, to get
a build going it's needed to:
1) From the root directory run
   "mvn clean install"
2) On succesfull completion go in the directory:
"opendaylight/distribution/opendaylight/target"

to pick the zip file of the distribution or controller can be executed
right from there going into the distribution directory.

Please note that this way no integration tests but only UT will be
executed, if you are planning on committing code be aware that the
code will be tested also for Integrations tests hence make sure before
submitting a patch to build using the command:
   "mvn clean install -Pintegrationtests"
to get IT executed.

HOW TO RELEASE ARTIFACTS
========================
Artifacts can be released in a bulk fashion or one by one depending on
the need. Bulk release works well when in the need of establishing a
baseline, for example on an upcoming major release. Single artifact
release is useful for example for API bundles which are supposed to be
used by others, this in fact seal the contract for that given version
and others can rest assured won't change because the maven repository
will not allow a the same artifact with the same version to be
re-deployed.

HOW TO BULK RELEASE ARTIFACTS
-----------------------------
Bulk release of the artifacts MUST be done only and exclusively by
using the pom.xml present in the same directory of this
README.OPENDAYLIGHT file. The pom.xml is just a pointer to the main
distribution directory or in general to the one containing all the
modules needs release.
To perform the release from the top level just run:

mvn -B release:prepare release:perform -Dgoals=deploy

Well this is not supposed to be executed by a human but by an apposite
Jenkins job because no committer or contributor has the necessary
privileges to escape the code review process needed by the release
process, but this is the logic behind.

HOW TO RELEASE ONE ARTIFACT
---------------------------
1) Make sure the artifact doesn't depend on SNAPSHOT  artifacts, as a
corollary it means that also the parent pom must be a released
artifact which then will not be present in the repo, so for this kind
of artifacts it's mandatory to provide a repository section to let it
download the parent from Opendaylight maven repository
2) Make sure all the dependencies are also non-SNAPSHOT
3) Via apposite Jenkins job make sure that the goals:

mvn -B release:prepare release:perform -Dgoals=deploy

is called.

[NOTE WELL]
The pom.xml in the root level is simply a pointer to the main
distribution but is needed to overcome some of the limitations in the
release process.

Thanks!!

About

Midokura's fork of the OpenDaylight Controller project

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 88.5%
  • JavaScript 6.0%
  • Xtend 4.6%
  • CSS 0.5%
  • Shell 0.2%
  • ApacheConf 0.1%
  • Scala 0.1%