Skip to end of metadata
Go to start of metadata

Goals

The goals of oparent are to centrally define shared parent POM definitions and configurations such as nexus (distributionManagement) location, coding styles, license checks, coding style checks, sonar setup, etc.

  • Isolate all the common external dependencies, default version, dependency management,plugin management, etc.
  • Avoid duplicate/conflicting settings for each project
  • Each project sets its parent to inherit the defaults from ONAP Parent
  • Project level external dependencies and versions can be overridden if necessary

Ultimately this will ensure consistency across ONAP projects, and free individual projects from redundant work whenever the standard configurations need to be changed.

Release Notes

See the current versions and release notes for O-Parent at https://onap.readthedocs.io/en/latest/submodules/integration.git/docs/release-notes.html#o-parent.

How to Implement for Your Project

Inherit from oparent

To use oparent, make sure that the oparent POM is set as the ultimate parent POM for all your POM files.  If your project already has its own parent POM, then you just need to make this change at that one POM file.

Set the parent POM in your pom.xml as follows.  Be sure to use the current version of oparent as declared in the version manifest; see ONAP Version Manifest Maven Plugin (Decommissioned).

    <parent>
        <groupId>org.onap.oparent</groupId>
        <artifactId>oparent</artifactId>
        <version>1.2.3</version>
        <relativePath/>
    </parent>

Remove redundant configuration items

Once the POMs have been modified to inherit from oparent, you can now remove the redundant configuration items such as nexus (distributionManagement) location, coding styles, license checks, coding style checks, sonar setup, etc. from your own project POM files.  Any necessary changes to the above can now be managed centrally without your project having to incur additional overhead.

Providing Feedback

If the oparent POM does not provide something that you need or causes conflicts, please provide feedback to the Integration team so that we can update oparent accordingly.


Notes on Releasing OPARENT


  1. Update the dependencies/pom.xml with any updated versions of upstream projects.
    1. this should be done with the security team to identify the acceptable or better version
    2. project team repos should also be validated to make sure they understand any implications on client code before they up-rev
    3. The merge of this change should create a maven merge job log that can be referenced
    4. This should be X.Y.Z-SNAPSHOT as the revision.
  2. Discuss at the PTL call that an updated version of OPARENT will be released.
  3. Use the LF self-release process to create the releases/X.Y.Z.yaml file that points to the maven merge job and the release number
    1. https://gerrit.onap.org/r/#/c/oparent/+/94862/
  4. The self release jobs should run and publish the maven artifact for X.Y.Z release.
  5. After that job runs you need to up-rev the version of oparent
    1. https://gerrit.onap.org/r/#/c/oparent/+/94863/
    2. This changes the revision to X.Y.Z+1-SNAPSHOT (or whatever X,Y,Z combination is appropriate) in all the affected files.
  6. oparent repository would now be ready for step 1.



27 Comments

  1. Some projects - like SDNC - have a need to include a parent POM from an external source, like the OpenDaylight parent POM, in order to inherit critical plugin settings, etc. Maven has no concept of multiple inheritance - you can have only one parent POM. So, such projects would not be able to use O-parent directly without breaking the build.

    I had been planning to provide parent POMs suitable for use by SDN controllers as part of the CCSDK project. Those POMs would have the OpenDaylight POMs (there are different ones depending on what type of component you're building) and would include common settings for ONAP controllers. Would it make more sense to include those POMs in the o-parent project?

    1. APPC used to inherit from the OpenDaylight parent POM, but we were able to change it to inherit from oparent instead: [https://gerrit.onap.org/r/#/c/5177/3/pom.xml].  Can you take a look and see if something similar might be possible for SDNC?

      If it's not possible to have SDNC inherit from oparent, then I guess we'll have to leave it as an exception.

      For CCSDK: Ideally these controller parent POMs themselves can inherit from oparent wherever possible, just to minimize redundancies.  If there are CCSDK common settings that are generally applicable to all ONAP projects, it would make sense to have those settings defined in oparent.

    2. A Portal sub-project is in a similar situation, it's a Spring-Boot application that uses a Spring-provided artifact as the parent.  Please advise if OParent/OVersion features can be used somehow.

  2. Please advise if special repositories must be specified, or other changes to support using this parent.  On my first attempt  maven fails with this message:

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (check-license) on project ecompportal-be-os: Execution check-license of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.onap.oparent:checkstyle:jar:1.0.0-SNAPSHOT, org.onap.oparent:onap-license:jar:1.0.0-SNAPSHOT: Could not find artifact org.onap.oparent:checkstyle:jar:1.0.0-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]

    I can reproduce the problem with the following POM in a new, empty maven Java project created with an Eclipse wizard.

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.att.research.onap.portal</groupId>
        <artifactId>poc-parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>

        <parent>
            <groupId>org.onap.oparent</groupId>
            <artifactId>oparent</artifactId>
            <version>1.0.0-SNAPSHOT</version>
        </parent>

        <repositories>
            <repository>
                <id>onap-snapshots</id>
                <name>ONAP Snapshot Repository</name>
                <url>http://nexus.onap.org/content/repositories/snapshots</url>
            </repository>
        </repositories>

    </project>

    1. Chris,

          I did see this artifact update failure the first time I ran oparent/pom.xml - your mail caught my eye - I was excluding oparent from my root pom.xml - reran again and was OK - there are a couple projects that may get this transient update issue.

          Try setting up the recommended m2 settings.xml which defines all 6 recommended repositories (4 ONAP, 2 ODL)

      https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment#SettingUpYourDevelopmentEnvironment-MavenExamplesettings.xml

           Actually, I confused myself, checkstyle-1.0.0-SNAPSHOT.jar is a reactor project target jar - not a 3rd party repo download.


      obrienbiometrics:oparent michaelobrien$ mvn clean install -U  -DskipTests=true -Dmaven.test.skip=true -Dmaven.javadoc.skip=true

      [INFO] Scanning for projects...

      [INFO] ------------------------------------------------------------------------

      [INFO] Reactor Build Order:

      [INFO]

      [INFO] oparent/version

      [INFO] oparent/checkstyle

      [INFO] oparent/license

      [INFO] oparent

      [INFO]

      [INFO] ------------------------------------------------------------------------

      [INFO] Building oparent/version 1.0.0-SNAPSHOT

      [INFO] ------------------------------------------------------------------------

      [INFO]

      [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ version ---

      [INFO]

      [INFO] --- maven-install-plugin:2.4:install (default-install) @ version ---

      [INFO] Installing /Users/michaelobrien/wse_onap/onap_11/oparent/version/pom.xml to /Users/michaelobrien/.m2/repository/org/onap/oparent/version/1.0.0-SNAPSHOT/version-1.0.0-SNAPSHOT.pom

      [INFO]

      [INFO] ------------------------------------------------------------------------

      [INFO] Building oparent/checkstyle 1.0.0-SNAPSHOT

      [INFO] ------------------------------------------------------------------------

      [INFO]

      [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ checkstyle ---

      [INFO]

      [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ checkstyle ---

      [INFO] Using 'UTF-8' encoding to copy filtered resources.

      [INFO] Copying 3 resources

      [INFO]

      [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ checkstyle ---

      [INFO] No sources to compile

      [INFO]

      [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ checkstyle ---

      [INFO] Not copying test resources

      [INFO]

      [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ checkstyle ---

      [INFO] Not compiling test sources

      [INFO]

      [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ checkstyle ---

      [INFO] Tests are skipped.

      [INFO]

      [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ checkstyle ---

      [INFO] Building jar: /Users/michaelobrien/wse_onap/onap_11/oparent/checkstyle/target/checkstyle-1.0.0-SNAPSHOT.jar

      [INFO]

      [INFO] --- maven-install-plugin:2.4:install (default-install) @ checkstyle ---

      [INFO] Installing /Users/michaelobrien/wse_onap/onap_11/oparent/checkstyle/target/checkstyle-1.0.0-SNAPSHOT.jar to /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/checkstyle-1.0.0-SNAPSHOT.jar

      ......

      ......

      [INFO] Installing /Users/michaelobrien/wse_onap/onap_11/oparent/checkstyle/pom.xml to /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/checkstyle-1.0.0-SNAPSHOT.pom

      [INFO] --- maven-install-plugin:2.4:install (default-install) @ oparent ---

      [INFO] Installing /Users/michaelobrien/wse_onap/onap_11/oparent/pom.xml to /Users/michaelobrien/.m2/repository/org/onap/oparent/oparent/1.0.0-SNAPSHOT/oparent-1.0.0-SNAPSHOT.pom

      [INFO] ------------------------------------------------------------------------

      [INFO] Reactor Summary:

      [INFO]

      [INFO] oparent/version .................................... SUCCESS [  0.268 s]

      [INFO] oparent/checkstyle ................................. SUCCESS [  0.646 s]

      [INFO] oparent/license .................................... SUCCESS [  0.020 s]

      [INFO] oparent ............................................ SUCCESS [  1.936 s]

      [INFO] ------------------------------------------------------------------------

      [INFO] BUILD SUCCESS

      [INFO] ------------------------------------------------------------------------

      [INFO] Total time: 2.976 s

      [INFO] Finished at: 2017-08-01T09:52:15-04:00

      [INFO] Final Memory: 22M/318M

      [INFO] ------------------------------------------------------------------------


      obrienbiometrics:oparent michaelobrien$ cat ~/.m2/settings.xml


            <activeProfile>10_nexus</activeProfile>

            <activeProfile>20_openecomp-public</activeProfile>

            <activeProfile>30_openecomp-staging</activeProfile>

            <activeProfile>40_openecomp-release</activeProfile>

            <activeProfile>50_openecomp-snapshots</activeProfile>

            <activeProfile>60_opendaylight-release</activeProfile>

            <activeProfile>70_opendaylight-snapshots</activeProfile>

      Jar is there

      obrienbiometrics:oparent michaelobrien$ ls /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/*.jar

      /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/checkstyle-1.0.0-20170710.230428-1.jar

      /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/checkstyle-1.0.0-SNAPSHOT.jar


      thank you

      /michael

  3. Thanks.  If possible I prefer to have POM files standalone, specifying everything they need.  I'm reluctant to assume that every build machine will have exactly the right entries in its global Maven settings file.  The following POM file works, it just adds a pluginRepositories block to what was above.  HTH

    --

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.att.research.onap.portal</groupId>
        <artifactId>poc-parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>

        <parent>
            <groupId>org.onap.oparent</groupId>
            <artifactId>oparent</artifactId>
            <version>1.0.0-SNAPSHOT</version>
        </parent>

        <repositories>
            <repository>
                <id>onap-jar-snapshots</id>
                <url>https://nexus.onap.org/content/repositories/snapshots</url>
            </repository>
        </repositories>

        <pluginRepositories>
            <pluginRepository>
                <id>onap-plugin-snapshots</id>
                <url>https://nexus.onap.org/content/repositories/snapshots/</url>
            </pluginRepository>
        </pluginRepositories>

    </project>
  4. Ideally ~/.m2/settings.xml should already include onap snapshots as a pluginRepository, then the builds should work properly by pulling the POM artifacts from Nexus.  Having the global settings.xml defined properly is the typical expectation for Linux Foundation projects like ODL, OPEN-O, etc. so that we don't need to re-define all those repos in all the project POM files.

  5. Using OParent makes Eclipse show the following error marker:

        Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (execution: check-style, phase: process-sources)

    The following addition to my pom silences the M2E plugin's complaints:

        <build>
            <pluginManagement>
                <plugins>
                    <plugin>
                        <groupId>org.eclipse.m2e</groupId>
                        <artifactId>lifecycle-mapping</artifactId>
                        <version>1.0.0</version>
                        <configuration>
                            <lifecycleMappingMetadata>
                                <pluginExecutions>
                                    <pluginExecution>
                                        <pluginExecutionFilter>
                                            <groupId>org.apache.maven.plugins</groupId>
                                            <artifactId>maven-checkstyle-plugin</artifactId>
                                            <versionRange>2.17,)</versionRange>
                                            <goals>
                                                <goal>check</goal>
                                            </goals>
                                        </pluginExecutionFilter>
                                        <action>
                                            <ignore />
                                        </action>
                                    </pluginExecution>
                                </pluginExecutions>
                            </lifecycleMappingMetadata>
                        </configuration>
                    </plugin>
                </plugins>
            </pluginManagement>
        </build>
  6. would it be appropriate to add the distributionManagement to the settings.xml or the oparent pom.xml???

    <distributionManagement>

    <repository>

    <id>ecomp-releases</id>

    <name>ONAP Release Repository</name>

    <url>${nexusproxy}/${releases.path}</url>

    </repository>

    <snapshotRepository>

    <id>ecomp-snapshots</id>

    <name>ONAP Snapshot Repository</name>

    <url>${nexusproxy}/${snapshots.path}</url>

    </snapshotRepository>

    <site>

    <id>ecomp-site</id>

    <url>dav:${nexusproxy}${sitePath}</url>

    </site>

    </distributionManagement>


    1. distributionManagement is already in the oparent POM files.  I don't think distributionManagement can go into settings.xml.

      1. Ok thanks - I needed to do a new git pull to see it.

  7. Hello Gary, wanted to report that the introduction of the "version-check-maven-plugin" has been pretty disruptive for the policy team today, the two main issues are (1)  the issue of not being able to work behind ih proxies as you know (per INT-125), and (2) this is the most disrupting, the introduction of the dependencies.dependency section to include the version-check-maven-plugin that affects the runtime classpaths for our deliveries, more specifically, the transitive dependencies that come with it and get picked up in the classpath underneath.   The drools libraries used by policy intersects in some dependencies but in different versions, the end result was a combo classpath of transitive dependencies from the 2 projects in different incompatible versions, creating some obscure errors at runtime.   The issue was fixed when in our poms when I excluded all dependencies in our own pams from the inherited ones from version-check-maven-plugin in order to get a sane classpath of libraries in compatible versions.   Note that while the version-check-maven-plugin is only need it at "build" time as they were specified, made it all the way to the final installation products classpaths if left as is.

    My point being that introduction of oparent dependencies I believe should be fairly controlled due to the impact of propagation by all projects underneath.  In the best case, there may be additional unused libraries in the runtime classpath, but in the worse, it will happen same than to us, it will create obscure runtime problems.

    I would suggest not to add invasive dependencies.dependency, but especially towards the end of the release, without verification that none of the underlying projects are impacted.

    Sorry for the long write up!  (smile)

    1. Hi Jorge, thanks for the feedback.  The main issue is that even when O-Parent was just experimenting with different solutions internally, those changes show up in the SNAPSHOT artifacts, which breaks downstream projects that have SNAPSHOT dependencies.

      Incidentally, this is why we are working towards the Independent Versioning and Release Process, so that every team can freely mess up their own SNAPSHOT artifacts without impacting other teams.

      On the version checks: based on your feedback and other considerations, we're reworking the strategy on the version checks, and should have the solution shortly.

  8. Please help with the license audit plugin configuration.  Per email from "CLOSSET, CHRISTOPHE" <cc697w@intl.att.com> on 29 August 2017 I have applied license text that has these as lines 1 and 2:

    /*
    * ============LICENSE_START==========================================

    But when the audit plugin runs it complains that line 2 has more than just a single asterisk:

    [INFO] --- maven-checkstyle-plugin:2.17:check (check-license) @ epsdk-app-common ---
    [INFO] Starting audit...
    /path../...blah.../AdminController.java:2: warning: Line does not match expected header line of '^ \*( )?$'.

    What needs to change here - the license or the audit config?  Thanks in advance.

    1. We will modify the audit config.  Can you send me a link to the email thread that Christophe sent out so that I can ensure a good match?

      1. The email went to PTLs (not to onap-discuss), I've forwarded the email to you directly.  Headers:

        From: "CLOSSET, CHRISTOPHE" <cc697w@intl.att.com>
        Subject: ONAP License.txt approved change by LF council
        Date: Tue, 29 Aug 2017 13:51:28 +0000
  9. I revised the Portal/SDK project to inherit from OParent, the build works locally but fails in ONAP Jenkins with the following error:

    [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.4:display-dependency-updates 
    (check-dependencies-version) on project epsdk-project: Could not load specified rules from
    https://git.onap.org/oparent/plain/versions/src/main/resources/onap-versions/ruleset.xml:
    File: https://git.onap.org/oparent/plain/versions/src/main/resources/onap-versions/ruleset.xml ,
    ReasonPhrase:Not found. -> [Help 1]

    Could there be some kind of network restriction blocking Jenkins from reaching git.onap.org? Please advise, thanks.

    1. Can you give me a link to the specific Jenkins job in question?  The ruleset.xml stuff should have already been fully removed a day or two ago, so I'm curious to see the logs.

        1. Re-triggered your job and it has completed successfully now.  I guess the previous run must have occurred before the ruleset.xml stuff was removed.

          1. Moving this conversation to email.

  10. For a local build in a dev environment, what values should be set in settings.xml?  (would help if this was in the body of the article since these comments contain examples and it is unclear whether they are necessary or correct)

    Answered my own question.

    Pre-requisite: Setting Up Your Development Environment#MavenExamplesettings.xml

  11. What exactly is the release process for artifacts?  We know how source code would branch out.  But for artifacts, in particular for non-jar artifacts.  will they just be built from release source code, and pushed to the release repos?  

    For example, for releasing a Docker image, somewhere in the build process the image needs to be tagged with the release docker registry and pushed there.  How is the identity of the release docker registry communicated?  Will oparent be the right place for such property, just like nexus_proxy?

    In addition, is there a standard ONAP naming scheme for tagging docker images?  SNAPSHOT v.s STAGING?  

  12. Currently the checkstyle settings in oparent with tag 1.2.0 does not work well with Eclipse Oxygen. This is because the Eclipse checkstyle plugin does not like the "maxLineLength" property. In order to get the checkstyle plugin working correctly with Eclipse Oxygen, do the following:

    1. Clear the checkstyle settings from your local .m2
      rm -fr ~/.m2/repository/org/onap/oparent/checkstyle/
    2. Clone a fresh oparent
      git clone https://gerrit.onap.org/r/oparent
    3. Find out what version of oparent you're using
      1.2.0
    4. Check out that oparent tag
      cd oparent
      git checkout tags/1.2.0
    5. go into the checkstyle module
      cd checkstyle
    6. Hack the checkstyle pom.xml to remove the -SNAPSHOT from the version
    7. Hack the checkstyle XML file
      src/main/resources/onap-checkstyle/onap-java-style.xml
    8. comment out the line
      <property name="maxLineLength" value="120"/>
      to
      <!--property name="maxLineLength" value="120"/-->
    9. Build the hacked checkstyle to your local .m2
      mvn clean install
    10. maven->update project on your projects in Eclipse

    Note: If you clear your .m2 or rebuild oparent you will, of course, have to repeat the above steps.

    The steps above are for use on Linux, use similar steps on Windows/Mac as appropriate.

    1. I have been meaning to ask Gary Wu about this. There seems to be a bug with that rcurly left bracket property.

    2. I had to perform a similar work-around to stop Eclipse (m2e) applying the onap-license check to Java classes under generated-sources. Here is a reference to the required updates: https://git.opendaylight.org/gerrit/#/c/48715/

  13. Trying to use the oparent 2.0.0-snapshot, but quickly got some errors, it seems relative to settings.xml, how externalapi/nbi master branch can work fine localy, with ~/.m2/settings.xml and jenkins build ? A sample java project will help (smile)

    Regards

    Matthieu