I've been advocating that we at least consider this approach for a while now, but I'm don't have the maven knowledge to understand where it falls on the spectrum of good idea vs. bad idea. I think the idea of making it work for one project first and expanding is a really good one.

Some ideas (which I think Devin covers most of) have been aggregated in this bug:
https://bugs.opendaylight.org/show_bug.cgi?id=1494

There are 3 other related bugs:
https://bugs.opendaylight.org/show_bug.cgi?id=1272 (creating odlparent and moving stuff there)
https://bugs.opendaylight.org/show_bug.cgi?id=1599 (providing information about the source code used for weekly builds, we might have solved this with the taglist, but I'm not sure if that's in the weeklies as well as the RC auto-release)
https://bugs.opendaylight.org/show_bug.cgi?id=1450 (document how to use the weekly releases)

I'm also direcly cc'ing the two committers on the odlparent project so that we can get their input.

--Colin

On Fri, Oct 3, 2014 at 4:00 PM, Devin Avery <davery@...> wrote:

Hello All -

During the “Inter-Project Infrastructure Services” meeting hosted by Colin Dixon, Robert Varga and Vasu Srinivasan some problems and questions were raised about the pom structure of our projects and how we might clean them up and possible consolidate to using ODLparent etc. During that session I offered up to start on the first part of the problem which was cleaning up pom structures. During the second day I was very thankful to have 3 folks from the lispflowmapping team join me and together we walked through their pom structure clean up unnecessary code etc. You can see some of the progress on this gerrit: https://git.opendaylight.org/gerrit/#/c/11704. 

During our clean up of the poms we discussed how we might leverage ODLParent and a daily or weekly build system to make it easier for projects to “roll back” if something is introduced that broke things. So, here is a rough outline of the proposal of best practices with regards to ODLParent in hopes that we can ultimately get an easy way to “role back” code:

1. EVERY bundle that is brought in as a dependency in ANY PROJECT should be listed in the dependency management version of the ODL Parent project (both third party and ODL). We should avoid declaring ANY version in projects dependency management or dependency section in any child project or bundle unless absolutely necessary.
1. Advantage 1: We can identify if there are third party version conflicts
2. Advantage 2: Single point definitions allow for reuse and simplified child poms.
2. Variables should be used for all dependency version (especially for ODL project dependencies) so they can be overridden in child poms if needed (say to roll back)
3. We need to make sure that we have a daily stable or weekly stable release artifact getting created for every project, that have a UNIQUE version.
4. If a problem is introduced into a logical parent project, then developers could temporarily override the version in their parent project until the problem is resolved (hence the previous requirement for unique versions for a weekly/daily stable build).

If we go this route, with a little work I think we could achieve:

a) greatly simplified pom files for all projects

b) the ability to quickly and easily role back version if there is a problem

If we want to try and go this route, then one major requirement would be that we make it much easier to contribute to the odl parent pom then it is now. I say this because if we are adding every dependencies version management to the odlparent pom then we can’t rely on just one or two committers to push those changes. In order for this to really work I believe we would want to make every committer a committer on the odlparent project. That way, a committer who is reviewing a change to a child project’s POM file could go review and push a change on the ODLparent pom file allowing for a much faster turn around.

So, to summarize, here is the proposed approach to cleaning up poms and optionally getting ready for the ability to easily roll back:

1. Encourage cleaner poms / structure by placing default configurations for plugins into ODLparent for common plugins (Note: all deps and default bundles would be commented to provide reasoning for their purpose)
1. Set up a model project (lispflowmapping) and change existing projects as time goes.
2. Change the ODL parent project such that any committer on any ODL project is also a committer on ODL parent
3. Work towards easy version “role-back” by placing ALL dependencies into ODLParent with variables, and provide instructions on how developers can role-back to weekly releases
1. May need to look at setting up stable release builds…

I would appreciate peoples thoughts and opinions on this proposal. Ultimately I am going to bring it in front of the TSC to accept the change of committers on the ODL parent project (and as such would appreciate ODLParent committers +1 on this approach).  I am happy to go into more details if folks want as well and discussed this further. It is a first pass.

Thank you!

Devin

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc