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?

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>

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:

    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>

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>

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!  

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.

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.

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:

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.

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 

Regards

Matthieu

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
> cd <my-repo-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
              onap-java-formatter.xml file

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.