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.
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 using the appropriate version:
<parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.2.0</version> <relativePath/> </parent>
Formatting Plugin Now Available Starting in guilin-
Oparent now has a formatting plugin available for projects that need to get their source code formatted to meet checkstyle guidelines. Instructions are in the pom.xml on how to use it.
# Clone oparent somewhere local > git clone https://github.com/onap/oparent.git # 1st - your project should be inheriting from this oparent java dependency > cd <my-repo> > vi pom.xml # ensure pom.xml is pointing to 3.1.0-SNAPSHOT or later # 2nd - go into your project's source directory you wish to reformat > cd <my-repo-to-reformat> # 3rd - type in the following and make sure you set the path to where you have oparent cloned and its onap-java-formatter.xml file > mvn formatter:format spotless:apply process-sources -Dproject.parent.basedir=<oparent-clone-location> # formatter will re-format your source files # check that the source compiles > mvn clean install # the source changes can now be uploaded via git review process
CVE Profile Now Available starting in guilin-
This profile can be used offline to check a repository for CVE issues in the codebase. Useful for contributors to check a new dependency without waiting for code to be merged and a CLM report job to be run.
NOTE: Downloading the CVE database can take awhile and require some bandwidth.
# # Be sure your project is inheriting from oparent java dependency # > mvn verify -P cve # should start seeing the following output: [INFO] Processing Complete for NVD CVE - 2019 (50630 ms) [INFO] Download Started for NVD CVE - Modified [INFO] Download Complete for NVD CVE - Modified (594 ms) [INFO] Processing Started for NVD CVE - Modified [INFO] Processing Complete for NVD CVE - Modified (592 ms) [INFO] Begin database maintenance [INFO] Updated the CPE ecosystem on 661 NVD records ... # # Look for these types of messages # apache-log4j-extras-1.2.17.jar (pkg:firstname.lastname@example.org, cpe:2.3:a:apache:log4j:1.2.17:*:*:*:*:*:*:*) : CVE-2019-17571, CVE-2020-9488 dme2-3.1.200-oss.jar/META-INF/maven/com.google.guava/guava/pom.xml (pkg:email@example.com, cpe:2.3:a:google:guava:19.0:*:*:*:*:*:*:*) : CVE-2018-10237 dme2-3.1.200-oss.jar/META-INF/maven/com.hazelcast/hazelcast-client-protocol/pom.xml (pkg:firstname.lastname@example.org, cpe:2.3:a:hazelcast:hazelcast:1.2.0:*:*:*:*:*:*:*) : CVE-2016-10750 dme2-3.1.200-oss.jar/META-INF/maven/com.hazelcast/hazelcast/pom.xml (pkg:email@example.com, cpe:2.3:a:hazelcast:hazelcast:3.7.2:*:*:*:*:*:*:*) : CVE-2016-10750 dme2-3.1.200-oss.jar/META-INF/maven/commons-beanutils/commons-beanutils/pom.xml (pkg:firstname.lastname@example.org, cpe:2.3:a:apache:commons_beanutils:1.9.2:*:*:*:*:*:*:*) : CVE-2019-10086 dme2-3.1.200-oss.jar/META-INF/maven/commons-collections/commons-collections/pom.xml (pkg:email@example.com, cpe:2.3:a:apache:commons_collections:3.2.1:*:*:*:*:*:*:*) : CVE-2015-6420, CVE-2017-15708, Remote code execution dme2-3.1.200-oss.jar/META-INF/maven/org.eclipse.jetty.websocket/websocket-core/pom.xml (pkg:firstname.lastname@example.org.M2, cpe:2.3:a:eclipse:jetty:9.0.0:m2:*:*:*:*:*:*, cpe:2.3:a:jetty:jetty:9.0.0:m2:*:*:*:*:*:*) : CVE-2017-7656, CVE-2017-7657, CVE-2017-7658, CVE-2018-12536 dme2-3.1.200-oss.jar/META-INF/maven/org.eclipse.jetty/jetty-server/pom.xml (pkg:email@example.com, cpe:2.3:a:eclipse:jetty:9.3.12:20160915:*:*:*:*:*:*, cpe:2.3:a:jetty:jetty:9.3.12:20160915:*:*:*:*:*:*) : CVE-2017-7656, CVE-2017-7657, CVE-2017-7658, CVE-2017-9735, CVE-2018-12536, CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 dme2-3.1.200-oss.jar/META-INF/maven/org.eclipse.jetty/jetty-xml/pom.xml (pkg:firstname.lastname@example.org, cpe:2.3:a:eclipse:jetty:9.3.12:20160915:*:*:*:*:*:*, cpe:2.3:a:jetty:jetty:9.3.12:20160915:*:*:*:*:*:*) : CVE-2017-7656, CVE-2017-7657, CVE-2017-7658, CVE-2018-12536, CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 kotlin-stdlib-1.3.20.jar (pkg:email@example.com, cpe:2.3:a:jetbrains:kotlin:1.3.20:*:*:*:*:*:*:*) : CVE-2019-10101, CVE-2019-10102, CVE-2019-10103
Previous Versions of Oparent
<!-- RELEASED VERSION WILL BE AVAILABLE 1st HALF 2022 --> <!-- AVAILABLE SNAPSHOT --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.3.0-SNAPSHOT</version> <relativePath/> </parent>
<!-- RELEASED VERSION --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.2.1</version> <relativePath/> </parent> <!-- AVAILABLE SNAPSHOT --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.2.2-SNAPSHOT</version> <relativePath/> </parent>
<!-- RELEASED VERSION --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.1.0</version> <relativePath/> </parent>
<!-- RELEASED VERSION --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.1.0</version> <relativePath/> </parent>
<!-- LAST AVAILABLE RELEASE --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>3.0.2</version> <relativePath/> </parent>
<!-- LAST AVAILABLE RELEASE --> <parent> <groupId>org.onap.oparent</groupId> <artifactId>oparent</artifactId> <version>2.1.0</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.
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
- Update the dependencies/pom.xml and dependencies-clm/pom.xml with any updated versions of upstream projects.
- this should be done with the security team to identify the acceptable or better version
- project team repos should also be validated to make sure they understand any implications on client code before they up-rev
- The merge of this change should create a maven merge job log that can be referenced
- This should be X.Y.Z-SNAPSHOT as the revision.
- Discuss at the PTL call that an updated version of OPARENT will be released.
- 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
- The self release jobs should run and publish the maven artifact for X.Y.Z release.
- After that job runs you need to up-rev the Patch version of oparent
- This changes the revision to X.Y.Z+1-SNAPSHOT (or whatever X,Y,Z combination is appropriate) in all the affected files.
- oparent repository would now be ready for step 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?
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.
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.
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.
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)
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] Reactor Build Order:
[INFO] Building oparent/version 1.0.0-SNAPSHOT
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ version ---
[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] Building oparent/checkstyle 1.0.0-SNAPSHOT
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ checkstyle ---
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ checkstyle ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ checkstyle ---
[INFO] No sources to compile
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ checkstyle ---
[INFO] Not copying test resources
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ checkstyle ---
[INFO] Not compiling test sources
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ checkstyle ---
[INFO] Tests are skipped.
[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] --- 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] Reactor Summary:
[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] BUILD SUCCESS
[INFO] Total time: 2.976 s
[INFO] Finished at: 2017-08-01T09:52:15-04:00
[INFO] Final Memory: 22M/318M
obrienbiometrics:oparent michaelobrien$ cat ~/.m2/settings.xml
Jar is there
obrienbiometrics:oparent michaelobrien$ ls /Users/michaelobrien/.m2/repository/org/onap/oparent/checkstyle/1.0.0-SNAPSHOT/*.jar
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
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.
Using OParent makes Eclipse show the following error marker:
The following addition to my pom silences the M2E plugin's complaints:
would it be appropriate to add the distributionManagement to the settings.xml or the oparent pom.xml???
<name>ONAP Release Repository</name>
<name>ONAP Snapshot Repository</name>
distributionManagement is already in the oparent POM files. I don't think distributionManagement can go into settings.xml.
Ok thanks - I needed to do a new git pull to see it.
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!
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.
Please help with the license audit plugin configuration. Per email from "CLOSSET, CHRISTOPHE" <firstname.lastname@example.org> on 29 August 2017 I have applied license text that has these as lines 1 and 2:
But when the audit plugin runs it complains that line 2 has more than just a single asterisk:
What needs to change here - the license or the audit config? Thanks in advance.
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?
The email went to PTLs (not to onap-discuss), I've forwarded the email to you directly. Headers:
I revised the Portal/SDK project to inherit from OParent, the build works locally but fails in ONAP Jenkins with the following error:
Could there be some kind of network restriction blocking Jenkins from reaching git.onap.org? Please advise, thanks.
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.
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.
Moving this conversation to email.
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
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?
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:
rm -fr ~/.m2/repository/org/onap/oparent/checkstyle/
git clone https://gerrit.onap.org/r/oparent
git checkout tags/1.2.0
<property name="maxLineLength" value="120"/>
<!--property name="maxLineLength" value="120"/-->
mvn clean install
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.
I have been meaning to ask Gary Wu about this. There seems to be a bug with that rcurly left bracket property.
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/
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
Trying to follow the instructions for "Formatting Plugin Now Available Starting in guilin-", but have problems. Firstly, the 2nd instruction is unclear to me:
# 2nd - go into your project's source directory you wish to reformat
It says in the instruction that one should go to the source directory, but in the command line it says the repo. Which one should it be?
Secondly, the 3rd instruction seems to be missing something:
# 3rd - type in the following and make sure you set the path to where you have oparent cloned and its
I tries by creating a symlink to the
onap-java-formatter.xml: ln -s ../../oparent/onap-java-formatter.xml onap-java-formatter.xml
Thirdly, when I try to run I get the following error:
[ERROR] No plugin found for prefix 'formatter' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/henan/.m2/repository), central (http://repo1.maven.org/maven2/), onap-public (https://nexus.onap.org/content/repositories/public/), onap-releases (https://nexus.onap.org/content/repositories/releases/), onap-snapshots (https://nexus.onap.org/content/repositories/snapshots/), onap-staging (https://nexus.onap.org/content/groups/staging), onap-snapshot (https://nexus.onap.org/content/repositories/snapshots), JCenter (http://jcenter.bintray.com), Restlet (http://maven.restlet.com)] -> [Help 1]
Can someone please help carify this? It would be really good to be able to use the common formatting.
"No plugin found" is the root issue, those are usually caused by firewall, vpn or proxy issues. Check to make sure you can download from public maven repository. For example:
You can use the settings.xml file located in the oparent repo.