The ultimate goal of O-Parent is to help make the lives of individual projects easier, so that they don't need to expend cycles making changes that need to be applied consistently across all projects. Currently that's just configuration items and static analysis tools. These are things that O-Parent does for you so that you don't have to.

I don't expect things like a common logging framework to get into O-Parent, unless ONAP as a community made a decision that in fact such framework is to be mandated across all projects.

So, in that sense, what gets into O-Parent is determined by what makes things easier for most. If something in O-Parent actually makes people's lives harder in the aggregate, then it would be taken out.

Please don't get me wrong, I understand what problems a parent pom is intended to solve. It's just the way to solve them seems not right given the size and heterogeneity of ONAP projects. I've done some additional research and found out that people raise the same concerns as mine https://stackoverflow.com/questions/27865238/parent-pom-and-microservices. I also don't think the ODL example is applicable here – it's multi-module and a single deployment unit vs. multiple projects, each potentially comprised of a number of microservices.

@Former user, I don't quite follow. Why should a logging framework be the same across all ONAP projects? The same version, too? But even if it should, there are other ways to achieve this.

In any case, as a shared parent pom affects all projects that inherit it, we must take extra care to decide what gets in, and what are the implications of every (future) change. Please share your thoughts on how this can be done.

In my experience the parent pom can have a minimal set of selected common configuration dependencies - like a common logging framework that should be the same across all components - ie https://lf-onap.atlassian.net/browse/LOG-44

At the project level poms - they can include their own version of dependencies like Hibernate version for example - which would make sense since everyone has their own container except for cross-cutting framework or component projects 

With respect to Nexus, I was referring more to the distributionManagement config tags used for artifact deployment.

The use of a single parent POM was a best practice picked up from ODL and applied successfully to OPEN-O.  There was no specific discussion thread on it, but it was part of the Integration project scope as approved by the ONAP TSC.  The experience from OPEN-O was that no project had found a need to override the common configurations, but I do observe that the ECOMP projects are a bit more inclined to do things their own way so I do expect some projects to override some parts.

What would be great is if we can get feedback from each project as to which parts they believe they will want to override, and if there are parts that are being overridden too often (i.e. not useful) then we can remove those parts from oparent.

@Former user I believe settings.xml is more suitable for repositories. And if you won't have dependencyManagement in the parent POM, why use it at all?

As for Checkstyle, there are other ways to do it that treat a Checkstyle configuration as a dependency with a version. You are actually using it in oparent.

I can give you an example when an inherited version might be a problem. In my project, I would like a build to fail on style and static analysis violations as the code shouldn't get into the source control in that case. Warnings/reports are no good because they are often ignored. On the other hand, I don't want the project to fail whenever the parent's Checkstyle rules get updated, because the community may have higher priorities to handle at the moment. I would align with the new rules later, and then upgrade to the new version.

Of course it's always possible to override the configuration, but I believe it will be the case more often than not, which makes the parent configuration pointless.

Could you point me to the thread where the decision to have a single parent POM was discussed, please? It affects the entire project so I want to understand all its pros and cons.