Michael Vorburger <vorburger@...> wrote: No. Watch the results of https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-neon/13/ — that will tell us whether this is good to

I've just tested https://git.opendaylight.org/gerrit/#/c/75675/ with https://git.opendaylight.org/gerrit/#/c/75699/ and https://git.opendaylight.org/gerrit/#/c/74891/ against infrautils, and it seems

Hello, Here are the MoM from today's Kernel Projects call : * Meeting ended Tue Sep 4 16:28:39 2018 UTC * Minutes:

Michael Vorburger <vorburger@...> wrote: I’m beginning to feel like a scratched record... Non-breaking changes can potentially be added during a release, if we get approval for a minor bump

04/03/2019 is the planned deadline to present MRI artifacts for Sodium integration window. That means all odlparent changes should be in by 03/03/2019 (at the latest) to allow for proper integration

Nothing "burning", just wanting to keep up to date, like most of the other upgrades we do. Knowing how slow we have now become in odlparent, I also feel that this is an opportunity we should not miss

I think it is quite late in the game to push for this -- we really should have an odlparent-4.0.0 release very soon so we can have a properly-prepared integration window. Hence my question is: is

Ahoi, I just noticed that maven-bundle-plugin released 4.0.0 last week (we're on still on 3.5.0; there was also a 3.5.1 in the middle). It's hard to come by release notes, and

According to https://lists.apache.org/thread.html/252d5c4772333ab30f9e5fff0b746cc4a92c46ae2dcb03c71d238600@%3Cdev.karaf.apache.org%3E the vote is supposed to happen tomorrow... Regards, Robert

you can try to re-engage on https://bugs.eclipse.org/bugs/show_bug.cgi?id=507612 (I never got to following up on that).

It included running antrun as per the reasons that were explained (by you) in the pom.xmls. Running nested build system, like ant inside maven, runs contrary to "works great" where build system health

+1. So let's remove it and controller can re-introduce it via a blueprint-parent if/when that is needed. https://git.opendaylight.org/gerrit/75180 does that. Regards, Robert

Providing something like "'blueprint-parent' with the specific configuration override, or an alternative solution would for infrautils to depend oncontroller, or removing the configuration override

I think we should eliminate the use of org/opendaylight/blueprint. That was originally introduced to allow the possibility for custom behavior like bundle ordering but we haven't/didn't need that.

Hello Michael, so this is infrautils being different from the rest of the projects. From your description it sounds like it is actually controller who needs to provide something like

it's because for SFT in infrautils the controller BP extender is not available, so BP XML in org/opendaylight/blueprint is ignore- which is what is causing that "Unresolved ref/idref to component:

The target where autowire.xml should be generated is configurable in the new plugin: https://github.com/opendaylight/odlparent/blob/ad7d94ef31c334d26b1dcc744d436d5d382e266c/odlparent/pom.xml#L1295 I

Robert, as promised during the Kernels call before yesterday, I had a closer look into that "Unresolved ref/idref to component: metricProviderImpl" failure we're seeing on the odlparent 4 for

Hello, I have lost the literal input from JB, but the gist of it was that karaf-4.2.1 should hopefully happen this week. If it is this close, I think we should coordinate and wait

Hello everyone, this: during build is rather slow, annoying and prevents repeatable builds. Are there any objections to massaging xtend-maven-plugin so that it does not do this? Thanks, Robert