> Why is the merge https://git.opendaylight.org/gerrit/#/c/65941/ that went in 10 days ago popping up as a problem only now?
I now understand the https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-validate-autorelease-oxygen/243 job on https://git.opendaylight.org/gerrit/#/c/65941/ could not have detected this; this is one problem we would only hit after merge. (And that's bad and we should think about how to improve that.) What I still do not understand is how autorelease was ignored in the last 10 days. Heck, if I understand https://jenkins.opendaylight.org/releng/job/autorelease-release-oxygen/buildTimeTrend correctly, did we not have a working autorelease in Oxygen in 30 days?? The short term fix https://git.opendaylight.org/gerrit/#/c/67821/ is already merged (thanks Stephen); read on for the real fix: On Thu, Feb 1, 2018 at 3:57 PM, Robert Varga <n...@hq.sk> wrote: > On 01/02/18 15:26, Stephen Kitt wrote: > > On Thu, 1 Feb 2018 15:11:07 +0100 > > Michael Vorburger <vorbur...@redhat.com> wrote: > >> On Thu, Feb 1, 2018 at 12:50 PM, Robert Varga <n...@hq.sk> wrote: > >>> The project does not list a dependency on mdsal-model-sources, hence > >>> that artifact is not built in autorelease until after the archetype: > >> So where would we best add these dependencies we need to "help" Maven > >> figure out the dependency tree correctly? Are we saying we need to > >> (today and remember in the future...) put everything that the > >> archetype needs into a <dependencies> in > >> controller/opendaylight/archetypes/pom.xml ? > > Heh, this is what we discussed in the kernel call a couple of weeks > > ago: we ultimately need to move the archetype out of controller... (Or > > is this already the simplified archetype?) > > > > However in this case, yes, we probably need additional mdsal > > dependencies in the archetype (which is OK since controller depends on > > mdsal anyway). > > ... so essentially you need to scope=test dependencies which are used by > the test, which includes all base ODL artifacts referenced by whatever > the artifact generates. I suspect this will end up being a short list > due to transitive dependencies. > FYI I've finally managed to reproduce this locally; documented how to on https://github.com/vorburger/opendaylight-repo#how-to-build-odl-autorelease. https://git.opendaylight.org/gerrit/#/c/67833/ fixes it for good (and un-does the disable quick fix c/67821). That POM could possibly do with a bit of clean up, but I've had (more than) enough of this; let's get this in as-is, please; if it can be cleaned up, others are welcome to raise follow up changes. But remember, your follow-up change will pass but autorelease could then still break after merge... ;-) > Heh, this is what we discussed in the kernel call a couple of weeks > ago: we ultimately need to move the archetype out of controller... (Or > is this already the simplified archetype?) I actually don't think this would help for the specific problem here; even if it was a separate project, that was part of autorelease, it would need this (c/67833). What would help, I think, is not having the archetype as controller/opendaylight/archetypes/opendaylight-startup/src/main/resources/archetype-resources/, but as a "real project" ... That would also make it much easier to maintain, and then using http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html (during the build) to create the archetype from that live real project. Anyone wants to explore that? ;-)
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
