[INTDIST-36] distribution-karaf fails with error factory already defined Created: 14/Aug/15  Updated: 20/Oct/17  Resolved: 19/Nov/16

Status: Resolved
Project: integration-distribution
Component/s: Build
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Thanh Ha (zxiiro) Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: Text File pom-file-changes-since-li.txt    
External issue ID: 4141

 Description   

See: https://jenkins.opendaylight.org/releng/job/autorelease-daily-lithium/267/

[INFO] — karaf-plugin:1.5.1-Daily-v201508140010:populate-local-repo (populate-local-repo) @ distribution-karaf —
[WARNING] Error injecting: org.opendaylight.odlparent.PopulateLocalRepoMojo
java.lang.Error: factory already defined
at java.net.URL.setURLStreamHandlerFactory(URL.java:1104)
at org.opendaylight.odlparent.PopulateLocalRepoMojo.<clinit>(PopulateLocalRepoMojo.java:51)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108)
at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:92)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:90)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:269)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:36)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:546)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.jvnet.hudson.maven3.launcher.Maven32Launcher.main(Maven32Launcher.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at jenkins.maven3.agent.Maven32Main.launch(Maven32Main.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:136)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:71)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

 Comments   
Comment by Thanh Ha (zxiiro) [ 14/Aug/15 ]

Just noticed some additional logs that seem to indicate that it's trying to copy some vtn components so might be the distribution-karaf from vtn. Here's a full log of the build section that appears just before the karaf-plugin runs to copy dependencies.

[INFO] — maven-dependency-plugin:2.8:unpack-dependencies (unpack-karaf-resources) @ distribution-karaf —
[INFO] Unpacking /opt/jenkins/workspace/autorelease-daily-lithium/controller/karaf/opendaylight-karaf-resources/target/opendaylight-karaf-resources-1.5.1-Daily-v201508131758.jar to /opt/jenkins/workspace/autorelease-daily-lithium/int
egration/distributions/karaf/target/assembly with includes "" and excludes "META-INF\/**"
[INFO]
[INFO] — maven-dependency-plugin:2.8:copy-dependencies (copy-externalapps) @ distribution-karaf —
[INFO] Copying distribution.vtn-coordinator-6.1.0.1-Daily-v201508131758-README.txt to /opt/jenkins/workspace/autorelease-daily-lithium/integration/distributions/karaf/target/assembly/externalapps/distribution.vtn-coordinator-6.1.0.1-
Daily-v201508131758-README.txt
[INFO] Copying distribution.vtn-coordinator-6.1.0.1-Daily-v201508131758-bin.tar.bz2 to /opt/jenkins/workspace/autorelease-daily-lithium/integration/distributions/karaf/target/assembly/externalapps/distribution.vtn-coordinator-6.1.0.1
-Daily-v201508131758-bin.tar.bz2
[INFO]
[INFO] — maven-antrun-plugin:1.7:run (default) @ distribution-karaf —
[WARNING] Parameter tasks is deprecated, use target instead
[INFO] Executing tasks

Comment by Colin Dixon [ 14/Aug/15 ]

After some poke around, the last bundle built is:

463140-[INFO] ------------------------------------------------------------------------
463141-[INFO] Building distribution-karaf 0.3.1-Daily-v201508140010
463142-[INFO] ------------------------------------------------------------------------

(Line numbers are from the full build log of build #267. You can get it by curl/wget-ing https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-daily-lithium/267/consoleText)

Based on the version (0.3.1), I'm pretty sure that's the integration distribution-karaf.

Comment by Colin Dixon [ 14/Aug/15 ]

To confirm my suspicion, the only artifact in nexus named distribution-karaf with version 0.3.1-SNAPSHOT is the integration one:
http://nexus.opendaylight.org/#nexus-search;gav~~distribution-karaf~0.3.1-SNAPSHOT~~

Comment by Colin Dixon [ 14/Aug/15 ]

Some more poking shows it actually part of the karaf-plugin in odlparent that's throwing the error. Not that it means the problem is there, but it is the next breadcrumb.

This line:
https://github.com/opendaylight/odlparent/blob/stable/lithium/karaf-plugin/src/main/java/org/opendaylight/odlparent/PopulateLocalRepoMojo.java#L51

is what's actually throwing the "factory already defined" error which is stopping the build.

Comment by Colin Dixon [ 14/Aug/15 ]

The current operating theory is that this patch is responsible:
https://git.opendaylight.org/gerrit/#/c/24705/

Thanh has a build going that reverts that and the follow on patch:
https://git.opendaylight.org/gerrit/#/c/25167/

The build is running here:
https://jenkins.opendaylight.org/releng/job/autorelease-daily-lithium/270/

Comment by Colin Dixon [ 14/Aug/15 ]

If that turns out not to be the issue, I've produced a list of all the pom.xml file changes (trying to exclude version bumps) since the Lithium release using this command:

./odlutils/for-all.pl odlutils/li-repos.txt 'git diff `git log release/lithium..HEAD --pretty=oneline --reverse | head -2 | tail -1 | egrep -o [0-9a-f]

{40}

` – `find . -name pom.xml` | cat' > ~/Desktop/pom-file-changes-since-li.txt

Using the odlutils repo I have:
https://github.com/nilok/odlutils

The result is the attached file.

Comment by Colin Dixon [ 14/Aug/15 ]

Attachment pom-file-changes-since-li.txt has been added with description: pom file changes between stable/lithium and Lithium-SR1

Comment by Thanh Ha (zxiiro) [ 26/Aug/15 ]

This was confirmed fixed after we backed out the patches to add archetypes to lithium.

https://git.opendaylight.org/gerrit/25318/

Generated at Wed Feb 07 20:02:37 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.