This is blocking JDK9 build, as karaf-maven-plugin 4.0.9 fails on JDK9:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.9:assembly (process-resources) on project opendaylight-karaf-resources: Unable to build assembly
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
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.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to build assembly
at org.apache.karaf.tooling.AssemblyMojo.execute(AssemblyMojo.java:243)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.apache.karaf.features.internal.util.MultiException: Error
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:84)
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
at org.apache.karaf.profile.assembly.Builder.loadRepositories(Builder.java:1167)
at org.apache.karaf.profile.assembly.Builder.doGenerateAssembly(Builder.java:448)
at org.apache.karaf.profile.assembly.Builder.generateAssembly(Builder.java:393)
at org.apache.karaf.tooling.AssemblyMojo.doExecute(AssemblyMojo.java:401)
at org.apache.karaf.tooling.AssemblyMojo.execute(AssemblyMojo.java:237)
... 22 more
Suppressed: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at org.apache.karaf.profile.assembly.Builder$4.downloaded(Builder.java:1184)
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:344)
at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:329)
at org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(DefaultFuture.java:255)
at org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.setFile(AbstractDownloadTask.java:61)
at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:61)

According to https://issues.apache.org/jira/browse/KARAF-5029, 4.1.x branch should solve this.

Preliminary patch: https://git.opendaylight.org/gerrit/63272

> Should I open a separate ODL Bug?

opened.

(In reply to Robert Varga from comment #2)
> It will not, but it will speed up feature.xml generation at build time. Boot
> up speed improvement will require more work on our side – MDSAL-235 tracks
> that.

I do not agree.
If you look into a short-ish karaf log [1] from CSIT you see this:

Sep 09, 2017 11:46:52 PM org.apache.karaf.main.Main$KarafLockCallback lockAquired
INFO: Lock acquired. Setting startlevel to 100
2017-09-09 23:50:33,158 | INFO | pool-1-thread-2 | FeaturesServiceImpl | 6 - org.apache.karaf.features.core - 4.0.9 | Adding features: odl-integration-all/[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT], standard/[4.0.9,4.0.9], wrap/[0,0.0.0]

That is almost 4 minutes to figure out list of bundles to be installed. No chance schema context refreshes apply to that.
Although it is an all job, so the list of bundles is quite long.

But when I was fixing [2] the offline job (mostly because of ), I had to add a waiting loop. The result is seen [3] only on Sandbox so far, but it takes almost the same time for the native Karaf ssh server to start responding when there are no ODL features in featuresBoot. The offline job uses feature:install to add the feature to test (odl-integration-all).
I guess the Karaf core was sifting through system/ repository in an ineffective
way.

2017-09-13 15:29:41,785 | INFO | bd4-8e1eaa0a7feb | Main | - - | Karaf started in 0s. Bundle stats: 10 active, 10 total
2017-09-13 15:34:01,050 | INFO | pool-1-thread-2 | FeaturesServiceImpl | 6 - org.apache.karaf.features.core - 4.0.9 | Adding features: standard/[4.0.9,4.0.9], wrap/[0,0.0.0]

Does Karaf project need another contribution to avoid that? Should I open a separate ODL Bug?

[1] https://logs.opendaylight.org/releng/jenkins092/distribution-deploy-nitrogen/46/karaf.log.gz
[2] https://git.opendaylight.org/gerrit/62903
[3] https://jenkins.opendaylight.org/sandbox/job/distribution-offline-nitrogen/5/console

It will not, but it will speed up feature.xml generation at build time. Boot up speed improvement will require more work on our side – MDSAL-235 tracks that.