+odlparent-dev, Robert & Stephen, I suspect this failure may be particular to SingleFeatureTest (SFT) :
On Tue, Mar 7, 2017 at 6:30 PM, Thanh Ha <thanh...@linuxfoundation.org> wrote: > On Tue, Mar 7, 2017 at 11:50 AM, Michael Vorburger <vorbur...@redhat.com> > wrote: > >> On Tue, Mar 7, 2017 at 4:49 PM, Thanh Ha <thanh...@linuxfoundation.org> >> wrote: >> >>> On Tue, Mar 7, 2017 at 10:23 AM, Michael Vorburger <vorbur...@redhat.com >>> > wrote: >>> >>>> On Tue, Mar 7, 2017 at 5:05 AM, Thanh Ha <thanh...@linuxfoundation.org> >>>> wrote: >>>> >>>>> Adding controller-dev, seems to be an issue with install some >>>>> controller bundles. >>>>> >>>> >>>> This is an SFT failure in controller/features/config/features-config >>>> ... I just it ran it locally, and it passed. I suspect this could have been >>>> related to today instabilities re. YANG gen. package move (just a guess) - >>>> please just retry, and shout if still NOK on the build (if though it passed >>>> locally for me right now). >>>> >>>> I'm not sure why we're not seeing the root cause of the exception >>>> thrown in the Activator in SFT BundleTest - that would be very useful in >>>> such cases: >>>> >>>> installFeature(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: >>>> >>>> file:/w/workspace/autorelease-release-carbon/controller/features/config/features-config/target/classes/features.xml, >>>> Feature: odl-config-all 0.6.0-Carbon] Time elapsed: 9.502 sec <<< >>>> ERROR!*00:49:44* java.lang.IllegalStateException: Can't install feature >>>> odl-config-all/0.6.0-Carbon: *00:49:44* Could not start bundle >>>> mvn:org.opendaylight.controller/config-manager/0.6.0-Carbon in feature(s) >>>> odl-config-manager-0.6.0-Carbon: Exception in >>>> org.opendaylight.controller.config.manager.impl.osgi.ConfigManagerActivator.start() >>>> of bundle org.opendaylight.controller.config-manager. >>>> >>>> Sounds good. I forced another autorelease build just now. >>> >>> https://jenkins.opendaylight.org/releng/view/autorelease/job >>> /autorelease-release-carbon/193/ >>> >> >> failed, with the same problem .. On a closer look, in >> https://logs.opendaylight.org/releng/jenkins092/autorelease- >> release-carbon/193/archives/controller/features/config/featu >> res-config/target/surefire-reports/org.opendaylight. >> odlparent.featuretest.SingleFeatureTest-output.txt.gz we find the root >> cause of that Activator failure I was missing above, it's: >> >> java.lang.NoClassDefFoundError: >> org/opendaylight/mdsal/binding/generator/util/BindingRuntimeContext >> >> So this looks related to https://git.opendaylight.org/g >> errit/#/c/52170/12/opendaylight/config/config-manager/src/ >> main/java/org/opendaylight/controller/config/manager/ >> impl/osgi/mapping/BindingContextProvider.java and so clearly this proves >> the failure is related to to today instabilities re. YANG gen. package >> move after all (although with a very different failure message than the >> many yang-maven-plugin fallovers seen elsewhere). >> >> With https://git.opendaylight.org/gerrit/#/c/52170/ merged, I'm not sure >> why it's not finding that BindingRuntimeContext at its new place where >> it was moved to from yangtools to mdsal... as far as I understood, that's >> all merged meanwhile (we're just dealing with some remaining impacts in >> downstream projects), and I've just double checked that >> controller/opendaylight/config/config-manager builds just fine locally.. >> >> So maybe this be one of those problems we've had in the past where >> autorelease was out of sync with latest master - do you want to try doing >> that thing you do in autorelease to force everything to be latest master? >> > > I can confirm that autorelease is not lagging behind on any commits. It's > pulling in the latest of all projects at this time. > > > Or maybe you should just wait for all of https://git.opendaylight.org/g >> errit/#/q/topic:binding-gen-v1-refactoring-package-naming to get merged, >> and then retry... ;-) >> >> If this persists, then for some reason when we run in Karaf with the SFT >> features, contrary to the build (compilation), we're still hitting the old >> code from before the refactoring... >> > > Autorelease does build all org.opendaylight projects from source though so > if this is expected due to the in progress refactoring. > My understanding is that the refactoring is complete enough now that this particular error should be not happening anymore... > That could be the cause of the failure as it will not fallback on SNAPSHOT > artifacts which will happen in local builds. > ah good point, it may well be somehow related to this... and the cause why it's not happening locally. I'm not crystal clear where SFT finds it's bundles - my feeling is that, somehow, it's pulling old bundle versions from before the refactoring, here. I had a quick peek at the SingleFeatureTest code, and there is something re. a "maven.repo.local" property and on https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-carbon/193/consoleFull we can see: -Dmaven.repo.local=/tmp/r -Dorg.ops4j.pax.url.mvn.localRepository=/tmp/r so that all seems about right, yet still this failed (twice) ... I don't understand either why. Not sure why the LOG.info("mvnLocalRepo \"{}\"", mvnRepoLocal); from SingleFeatureTest's mvnLocalRepoOption() doesn't show on https://logs.opendaylight.org/releng/jenkins092/autorelease-release-carbon/193/archives/controller/features/config/features-config/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz ... Regards, > Thanh > > _______________________________________________ > yangtools-dev mailing list > yangtools-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/yangtools-dev > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
