[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710262#comment-17710262
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
Sure, I am willing. I think that I may be only one user at the moment with this
problem, but there are going to be *lots* of others, since my use case is not
particularly complicated, so anything to prevent users from having to
repeatedly destroy their local repositories is a good thing.
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M8
>
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:123)
>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (
[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710245#comment-17710245
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
Thank you; I see now. Unfortunately as a previous commenter noted above I
cannot ensure that all builds of everything will always use the Maven Resolver
approach, so those zero-byte site descriptors may keep showing up. Is the
remedy nevertheless still to repeatedly destroy my local repository, over and
over again? If so, I guess I'll just roll back to the 3.12.1 version of the
maven-site-plugin to avoid this.
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:123)
>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.a
[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710223#comment-17710223
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
I see. So if some process ever places a zero-byte site descriptor anywhere in
my {{~/.m2/repository}} (in my project graph) for any reason, subsequent usage
of (for example) the maven-site-plugin version 4.0.0-M6 will fail? I am not
trying to criticize, just trying to understand the scope of the problem.
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:123)
>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecyc
[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710201#comment-17710201
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
Thank you. As noted above, the parent was created with maven-site-plugin
version 4.0.0-M6, so it is not, to my knowledge, an "older version" as
described in the documentation. Would you agree?
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:123)
>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecuto
[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710192#comment-17710192
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
I can't provide the output. The command was just mvn site.
I think I can see from the output what is going on. There is a parent project,
which consists only of a pom. It was built and installed with (among other
plugins) maven-site-plugin version 4.0.0-M6. In my local repository, I see
.../project-name-20-site.xml. It has no bytes in it.
The project I'm building inherits from the parent. I see during mvn site:
{{[DEBUG] Looking for site descriptor of level 1 parent project:
com.foo:project-name:pom:20}}
{{[DEBUG] Reading parent level 1 site descriptor from
/Users/ljnelson/.m2/repository/com/foo/project-name/20/project-name-20-site.xml}}
The build fails with SiteToolException: Error reading site descriptor: input
contained no data.
As noted above, this file has no bytes in it so my project build fails.
Perhaps when you said "all site.xml files" you meant "all files in your .m2
repository that end with 'site.xml'"?
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingCont
[jira] [Comment Edited] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710051#comment-17710051
]
Laird Nelson edited comment on DOXIASITETOOLS-301 at 4/10/23 4:30 AM:
--
I ran into this issue and thank the original poster for trying to refine this
issue from the original "just remove ~/.m2/repository" comment.
I see that the recommendation is to remove all site.xml files found in
~/.m2/repository. In my case there are no such files. I'm running Nexus in
case it matters. What is the recommendation here?
was (Author: ljnelson):
I ran into this issue and thank the original poster for trying to refine this
issue from the original "just remove ~/.m2/repository" comment.
I see that the recommendation is to remove all site.xml files found in
~/.m2/repository. In my case there are no such files. I'm running Nexus.
What is the recommendation here?
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (S
[jira] [Commented] (DOXIASITETOOLS-301) Automatically remove the 0-byte site descriptors from the local repo
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710051#comment-17710051
]
Laird Nelson commented on DOXIASITETOOLS-301:
-
I ran into this issue and thank the original poster for trying to refine this
issue from the original "just remove ~/.m2/repository" comment.
I see that the recommendation is to remove all site.xml files found in
~/.m2/repository. In my case there are no such files. I'm running Nexus.
What is the recommendation here?
> Automatically remove the 0-byte site descriptors from the local repo
>
>
> Key: DOXIASITETOOLS-301
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-301
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 2.0.0-M6
>Reporter: Konrad Windszus
>Priority: Major
>
> As older versions created 0-byte site descriptors in the local repo those
> should be automatically removed if detected. Otherwise you run into the
> following error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor: input contained no data -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site
> (generate-site) on project openmeetings-parent: SiteToolException:
> Error reading site descriptor
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
>at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
>at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
>at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
>at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
>at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
>at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
>at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
>at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
>at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke (Method.java:568)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
>at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
>at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> SiteToolException: Error reading site descriptor
>at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel
> (AbstractSiteDescriptorMojo.java:94)
>at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext
> (AbstractSiteRenderingMojo.java:246)
>at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:138)
>at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:123)
>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
>at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
>at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
>at org.apa
[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909306#comment-16909306
]
Laird Nelson commented on MNG-6735:
---
I'll let you guys figure it out or close this issue; I can get around this
issue by using the {{useBaseVersion}} configuration parameter. Thanks!
> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot:
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we
> need to copy this pinned snapshot using the Maven dependency plugin's
> {{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned
> snapshot, and although the Maven shared archiver constructs the manifest
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to
> infer that the pinned version is in fact a snapshot version, and so when the
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result
> is that although the {{Class-Path:}} header is correct, no such pinned
> snapshot version jar file exists. Instead, a jar file with {{-SNAPSHOT}} as
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version
> string as a snapshot, and "helpfully" erases it, turning the resulting jar
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem. Is there a reason for this
> helpful behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909123#comment-16909123
]
Laird Nelson commented on MNG-6735:
---
Oh, I'm well aware of that. But Narayana 5.9.6.Final isn't:
[https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot:
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we
> need to copy this pinned snapshot using the Maven dependency plugin's
> {{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned
> snapshot, and although the Maven shared archiver constructs the manifest
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to
> infer that the pinned version is in fact a snapshot version, and so when the
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result
> is that although the {{Class-Path:}} header is correct, no such pinned
> snapshot version jar file exists. Instead, a jar file with {{-SNAPSHOT}} as
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version
> string as a snapshot, and "helpfully" erases it, turning the resulting jar
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem. Is there a reason for this
> helpful behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908697#comment-16908697
]
Laird Nelson commented on MNG-6735:
---
After some more research, I see that this may be the very problem that the
inscrutably named {{useBaseVersion}} parameter was invented to solve. I find
that when I set this to {{false}}, the issues go away. I'm not sure what "base
version" is, and if I had to guess based on the English, I would have thought
that given a pinned snapshot version, then I would want that version to be
used, so intuitively I'd expect that {{useBaseVersion}} should be set to
{{true}}. But it appears that I have this exactly backwards!
> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot:
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we
> need to copy this pinned snapshot using the Maven dependency plugin's
> {{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned
> snapshot, and although the Maven shared archiver constructs the manifest
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to
> infer that the pinned version is in fact a snapshot version, and so when the
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result
> is that although the {{Class-Path:}} header is correct, no such pinned
> snapshot version jar file exists. Instead, a jar file with {{-SNAPSHOT}} as
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version
> string as a snapshot, and "helpfully" erases it, turning the resulting jar
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem. Is there a reason for this
> helpful behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
Laird Nelson created MNG-6735:
-
Summary: ArtifactUtils#toSnapshotVersion problem with pinned
snapshots
Key: MNG-6735
URL: https://issues.apache.org/jira/browse/MNG-6735
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.6.1
Reporter: Laird Nelson
I apologize in advance for the vagueness.
In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
I am using a project whose released version depends on a pinned snapshot:
[https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
This works fine for things like unit tests and so on.
For various reasons, some of which are good and some of which are bad, we need
to copy this pinned snapshot using the Maven dependency plugin's
{{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
file's manifest that refers to this pinned snapshot version.
When we do so, we discover that although this project depends on a pinned
snapshot, and although the Maven shared archiver constructs the manifest
{{Class-Path:}} entry properly, i.e. referring to the pinned version, not
anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to infer
that the pinned version is in fact a snapshot version, and so when the jar file
is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result is that
although the {{Class-Path:}} header is correct, no such pinned snapshot version
jar file exists. Instead, a jar file with {{-SNAPSHOT}} as a suffix is there
instead, and we get classloading errors.
I've traced the problem to {{ArtifactUtils}} where its
{{toSnapshotVersion(String)}} method appears to recognize this pinned version
string as a snapshot, and "helpfully" erases it, turning the resulting jar file
back into a {{-SNAPSHOT}} suffixed jar file.
I don't see any workaround to this problem. Is there a reason for this helpful
behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MJAVADOC-597) maven-javadoc-plugin can't deal with single-digit maven-compiler-plugin source versions
[
https://issues.apache.org/jira/browse/MJAVADOC-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809275#comment-16809275
]
Laird Nelson commented on MJAVADOC-597:
---
I'd say close it.
> maven-javadoc-plugin can't deal with single-digit maven-compiler-plugin
> source versions
> ---
>
> Key: MJAVADOC-597
> URL: https://issues.apache.org/jira/browse/MJAVADOC-597
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Laird Nelson
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> The {{maven-javadoc-plugin}} indicates that it detects which Java version is
> being used by looking at the {{source}} configuration element of the
> {{maven-compiler-plugin}}.
> If that version is, say, {{8}} instead of *{{1}}*{{.8}}, the
> {{maven-javadoc-plugin}} no longer produces links to the relevant JDK
> Javadocs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated SUREFIRE-1605:
---
Comment: was deleted
(was: Indeed, it must be environmental; the build succeeds. How it can be
environmental is beyond me!)
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-junit4/3.0.0-M1/su
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16706017#comment-16706017
]
Laird Nelson commented on SUREFIRE-1605:
[~tibor17] Oh, thank goodness! I was going crazy! Let me update the Travis
build correspondingly.
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16706016#comment-16706016
]
Laird Nelson commented on SUREFIRE-1605:
Indeed, it must be environmental; the build succeeds. How it can be
environmental is beyond me!
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/su
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705991#comment-16705991
]
Laird Nelson commented on SUREFIRE-1605:
I'm going to set up a Travis build and see if we can get a "neutral party" to
fail the build.
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/suref
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705989#comment-16705989
]
Laird Nelson commented on SUREFIRE-1605:
!!
I certainly hope not; they work in all my other projects (e.g. Junit, which is
the only dependency in question).
Did you ensure that the toolchain is active when you went to reproduce?
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705972#comment-16705972
]
Laird Nelson commented on SUREFIRE-1605:
Done.
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-junit4/3.0.0-M1/surefire-junit4-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apach
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705971#comment-16705971
]
Laird Nelson commented on SUREFIRE-1605:
That's odd; the parent is in Maven central. OK, I'll cut and paste the
relevant contents of the parent into the {{pom.xml}}.
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
> --class-path
> /Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository
[jira] [Commented] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705966#comment-16705966
]
Laird Nelson commented on SUREFIRE-1605:
Certainly; it's effortless: [https://github.com/ljnelson/surefire-1605]
Running {{mvn test}} in this simple environment yields the same error.
You can do {{mvn help:effective-pom}} to see the full {{pom.xml}}; I used pom
inheritance for convenience.
[~tibor17]: I don't understand what you're saying. I am following
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html.]
There is no mention of having to do anything different for version 3.0.0-M1;
the same test (with {{module-info.java}}) works fine under Surefire 2.22.1. In
other words, merely specifying a new version of the Surefire plugin causes the
failure.
> NoClassDefFoundError (RunNotifier) with JDK 11
> --
>
> Key: SUREFIRE-1605
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
>Reporter: Laird Nelson
>Priority: Major
>
> I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK
> 11 via toolchains and the Surefire plugin version 3.0.0-M1.
> {{mvn test}} fails with the following dump indicating that JDK 11's
> {{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
> {{org.junit.runner.notification.RunNotifier}} class:
> {code:java}
> # Created at 2018-11-30T14:30:40.517
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
> at java.base/java.lang.Class.getConstructor0(Class.java:3343)
> at java.base/java.lang.Class.getConstructor(Class.java:2152)
> at
> org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
> at
> org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
> at
> org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.ClassNotFoundException:
> org.junit.runner.notification.RunNotifier
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 11 more{code}
> I see no workaround.
> The contents of the arguments file are:
> {code:java}
> --module-path
> /Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-a
[jira] [Updated] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated SUREFIRE-1605:
---
Description:
I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK 11
via toolchains and the Surefire plugin version 3.0.0-M1.
{{mvn test}} fails with the following dump indicating that JDK 11's
{{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
{{org.junit.runner.notification.RunNotifier}} class:
{code:java}
# Created at 2018-11-30T14:30:40.517
java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
at java.base/java.lang.Class.getConstructor0(Class.java:3343)
at java.base/java.lang.Class.getConstructor(Class.java:2152)
at
org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
at
org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
at
org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.ClassNotFoundException:
org.junit.runner.notification.RunNotifier
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 11 more{code}
I see no workaround.
The contents of the arguments file are:
{code:java}
--module-path
/Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
--class-path
/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-junit4/3.0.0-M1/surefire-junit4-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-java5/3.0.0-M1/common-java5-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-junit3/3.0.0-M1/common-junit3-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-junit4/3.0.0-M1/common-junit4-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar
--patch-module
org.microbean.ristretto.bean=/Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/test-classes
--add-exports
org.microbean.ristretto
[jira] [Updated] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
[
https://issues.apache.org/jira/browse/SUREFIRE-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated SUREFIRE-1605:
---
Description:
I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK 11
via toolchains and the Surefire plugin version 3.0.0-M1.
{{mvn test}} fails with the following dump indicating that JDK 11's
{{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
{{org.junit.runner.notification.RunNotifier}} class:
{code:java}
# Created at 2018-11-30T14:30:40.517
java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
at java.base/java.lang.Class.getConstructor0(Class.java:3343)
at java.base/java.lang.Class.getConstructor(Class.java:2152)
at
org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
at
org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
at
org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.ClassNotFoundException:
org.junit.runner.notification.RunNotifier
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 11 more{code}
I see no workaround.
The contents of the arguments file are:
{code}
--module-path
/Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/classes:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-context/0.0.1-SNAPSHOT/microbean-ristretto-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-context-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-context-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject-spi/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-spi-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-el/0.0.1-SNAPSHOT/microbean-ristretto-javax-el-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-event/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-event-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-enterprise-util/0.0.1-SNAPSHOT/microbean-ristretto-javax-enterprise-util-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-inject/0.0.1-SNAPSHOT/microbean-ristretto-javax-inject-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-ristretto-javax-interceptor/0.0.1-SNAPSHOT/microbean-ristretto-javax-interceptor-0.0.1-SNAPSHOT.jar:/Users/LANELSON/.m2/repository/org/microbean/microbean-development-annotations/0.2.2/microbean-development-annotations-0.2.2.jar:/Users/LANELSON/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar
--class-path
/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M1/surefire-booter-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M1/surefire-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1/surefire-logger-api-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/surefire-junit4/3.0.0-M1/surefire-junit4-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-java5/3.0.0-M1/common-java5-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-junit3/3.0.0-M1/common-junit3-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/surefire/common-junit4/3.0.0-M1/common-junit4-3.0.0-M1.jar:/Users/LANELSON/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar
--patch-module
org.microbean.ristretto.bean=/Users/LANELSON/Projects/github/microbean/ristretto/microbean-ristretto-bean/target/test-classes
--add-exports
org.microbean.ristretto.bean
[jira] [Created] (SUREFIRE-1605) NoClassDefFoundError (RunNotifier) with JDK 11
Laird Nelson created SUREFIRE-1605:
--
Summary: NoClassDefFoundError (RunNotifier) with JDK 11
Key: SUREFIRE-1605
URL: https://issues.apache.org/jira/browse/SUREFIRE-1605
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 3.0.0-M1
Reporter: Laird Nelson
I have a JUnit 4 test. JUnit 4.12 is on the test classpath. I'm using JDK 11
via toolchains and the Surefire plugin version 3.0.0-M1.
{{mvn test}} fails with the following dump indicating that JDK 11's
{{jdk.internal.loader.BuiltinClassLoader}} cannot find the JUnit 4 class
{{org.junit.runner.notification.RunNotifier}} class:
{code:java}
# Created at 2018-11-30T14:30:40.517
java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
at java.base/java.lang.Class.getConstructor0(Class.java:3343)
at java.base/java.lang.Class.getConstructor(Class.java:2152)
at
org.apache.maven.surefire.util.ReflectionUtils.getConstructor(ReflectionUtils.java:83)
at
org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:122)
at
org.apache.maven.surefire.booter.ForkedBooter.createProviderInCurrentClassloader(ForkedBooter.java:403)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.ClassNotFoundException:
org.junit.runner.notification.RunNotifier
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 11 more{code}
I see no workaround.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564276#comment-16564276
]
Laird Nelson commented on MNG-6435:
---
Compatibility is tricky here. Thanks to the design, I _think_ if you had some
stuff in your {{settings.xml}} like this:
{code:java}
<${project.artifactId}>hello
{code}
…it should work (which is a little crazy). The serialization, in other words,
dumps the whole {{settings.xml}} (XML tokens and all) into a {{String}} and
then performs interpolation on the resulting {{String}}. I'm not sure there's
any other solution than my approach above if that behavior has to be maintained.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Minor
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564197#comment-16564197
]
Laird Nelson commented on MNG-6435:
---
That's a bit of a strange request; I'm not sure what constitutes "harm". I can
give an example of someone (me) trying to write a settings reader and realizing
that I had to also write a settings writer even though there is no case where I
or any other part of the tool needs to write settings.
To do this, I had to jump through a lot of hoops. Please see:
https://github.com/microbean/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/YamlSettingsBuilder.java
Note that I shouldn't have to implement a {{SettingsBuilder}} but only a
{{SettingsReader}}. But I can't simply implement a {{SettingsReader}} because
the {{DefaultSettingsBuilder}} forces me needlessly to also implement a
{{SettingsWriter}}. In my case, I simply reimplemented the {{SettingsBuilder}}
to bypass this limitation.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Minor
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6447) maven-javadoc-plugin can't deal with single-digit maven-compiler-plugin source versions
[
https://issues.apache.org/jira/browse/MNG-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16548569#comment-16548569
]
Laird Nelson commented on MNG-6447:
---
This may be a false alarm related to [Maven toolchain
support|https://maven.apache.org/guides/mini/guide-using-toolchains.html].
Investigating further.
> maven-javadoc-plugin can't deal with single-digit maven-compiler-plugin
> source versions
> ---
>
> Key: MNG-6447
> URL: https://issues.apache.org/jira/browse/MNG-6447
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.5.4
>Reporter: Laird Nelson
>Priority: Minor
>
> The {{maven-javadoc-plugin}} indicates that it detects which Java version is
> being used by looking at the {{source}} configuration element of the
> {{maven-compiler-plugin}}.
> If that version is, say, {{8}} instead of *{{1}}*{{.8}}, the
> {{maven-javadoc-plugin}} no longer produces links to the relevant JDK
> Javadocs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6447) maven-javadoc-plugin can't deal with single-digit maven-compiler-plugin source versions
Laird Nelson created MNG-6447:
-
Summary: maven-javadoc-plugin can't deal with single-digit
maven-compiler-plugin source versions
Key: MNG-6447
URL: https://issues.apache.org/jira/browse/MNG-6447
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.5.4
Reporter: Laird Nelson
The {{maven-javadoc-plugin}} indicates that it detects which Java version is
being used by looking at the {{source}} configuration element of the
{{maven-compiler-plugin}}.
If that version is, say, {{8}} instead of *{{1}}*{{.8}}, the
{{maven-javadoc-plugin}} no longer produces links to the relevant JDK Javadocs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MNG-6435:
--
Description:
On or around line 234, interpolation of settings assumes XML:
{code}
interpolator.addPostProcessor( new InterpolationPostProcessor()
{
@Override
public Object execute( String expression, Object value )
{
if ( value != null )
{
// we're going to parse this back in as XML so we need to escape XML
markup
value = value.toString().replace( "&", "&" ).replace( "<", "<"
).replace( ">", ">" );
return value;
}
return null;
}
} );
{code}
The value being interpolated here is the result of a {{SettingsWriter}}'s
output. Obviously this kind of escaping doesn't make any sense if the
{{SettingsWriter}} in question is not XML-based.
was:
On or around line 234, interpolation of settings assumes XML:
{code}
interpolator.addPostProcessor( new InterpolationPostProcessor()
{
@Override
public Object execute( String expression, Object value )
{
if ( value != null )
{
// we're going to parse this back in as XML so we need to escape XML
markup
value = value.toString().replace( "&", "&" ).replace( "<", "<"
).replace( ">", ">" );
return value;
}
return null;
}
} );
{code}
The expression being interpolated here is the result of a {{SettingsWriter}}'s
output. Obviously this kind of escaping doesn't make any sense if the
{{SettingsWriter}} in question is not XML-based.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Major
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
Laird Nelson created MNG-6435:
-
Summary: DefaultSettingsBuilder assumes all SettingsReader/Writer
impls will use XML
Key: MNG-6435
URL: https://issues.apache.org/jira/browse/MNG-6435
Project: Maven
Issue Type: Bug
Components: Settings
Affects Versions: 3.5.3
Reporter: Laird Nelson
On or around line 234, interpolation of settings assumes XML:
{code}
interpolator.addPostProcessor( new InterpolationPostProcessor()
{
@Override
public Object execute( String expression, Object value )
{
if ( value != null )
{
// we're going to parse this back in as XML so we need to escape XML
markup
value = value.toString().replace( "&", "&" ).replace( "<", "<"
).replace( ">", ">" );
return value;
}
return null;
}
} );
{code}
The expression being interpolated here is the result of a {{SettingsWriter}}'s
output. Obviously this kind of escaping doesn't make any sense if the
{{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-483) Needs support for https.proxySet etc.
[
https://issues.apache.org/jira/browse/MJAVADOC-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011486#comment-16011486
]
Laird Nelson commented on MJAVADOC-483:
---
Here are changes I made (I cannot get the plugin to compile; I figure something
here is better than nothing). This starts at line {{3536}} in
{{AbstractJavadocMojo.java}}. As mentioned, I cannot tell if this compiles but
you should get the idea:
{code:title=AbstractJavadocMojo.java line 3536}
List proxies = settings.getProxies();
if ( proxies != null && !proxies.isEmpty() )
{
for ( Proxy activeProxy : proxies )
{
if (activeProxy != null && activeProxy.isActive())
{
String protocol = StringUtils.isNotEmpty( activeProxy.getProtocol()
) ? activeProxy.getProtocol() + "." : "";
if ( StringUtils.isNotEmpty( activeProxy.getHost() ) )
{
cmd.createArg().setValue( "-J-D" + protocol + "proxySet=true" );
cmd.createArg().setValue( "-J-D" + protocol + "proxyHost=" +
activeProxy.getHost() );
if ( activeProxy.getPort() > 0 )
{
cmd.createArg().setValue( "-J-D" + protocol + "proxyPort="
+ activeProxy.getPort() );
}
if ( StringUtils.isNotEmpty( activeProxy.getNonProxyHosts() ) )
{
cmd.createArg().setValue("-J-D" + protocol +
"nonProxyHosts=\"" + activeProxy.getNonProxyHosts() + "\"" );
}
if ( StringUtils.isNotEmpty( activeProxy.getUsername() ) )
{
cmd.createArg().setValue( "-J-D" + protocol +
"proxyUser=\"" + activeProxy.getUsername() + "\"" );
if ( StringUtils.isNotEmpty( activeProxy.getPassword() ) )
{
cmd.createArg().setValue( "-J-D" + protocol +
"proxyPassword=\"" + activeProxy.getPassword() + "\"" );
}
}
}
}
}
}
{code}
> Needs support for https.proxySet etc.
> -
>
> Key: MJAVADOC-483
> URL: https://issues.apache.org/jira/browse/MJAVADOC-483
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Laird Nelson
>
> I work at a ginormous company that has a proxy server. I have an active
> {{}} in my {{.m2/settings.xml}} for the {{http}} protocol. The
> {{maven-javadoc-plugin}} picks this up fine.
> Weirdly, the {{javadoc}} invocation _also_ requires the {{https}} proxy to be
> set. There is no way to accomplish this with the {{maven-javadoc-plugin}}.
> IMHO it should see if there is an active {{}} element whose protocol
> is {{https}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAVADOC-483) Needs support for https.proxySet etc.
[
https://issues.apache.org/jira/browse/MJAVADOC-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011462#comment-16011462
]
Laird Nelson commented on MJAVADOC-483:
---
Huh; I notice in {{Settings#getActiveProxy()}} that there is an assumption that
there is [only one active
proxy|http://maven.apache.org/ref/3.5.0/maven-settings/apidocs/org/apache/maven/settings/Settings.html#getActiveProxy()]
with (presumably?) one protocol. Probably the section in
{{AbstractJavadocMojo}} that calls this method should be amended to get _all_
proxies and select active ones with the {{http}} or {{https}} protocols. I'll
see if I can put together a PR.
> Needs support for https.proxySet etc.
> -
>
> Key: MJAVADOC-483
> URL: https://issues.apache.org/jira/browse/MJAVADOC-483
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Laird Nelson
>
> I work at a ginormous company that has a proxy server. I have an active
> {{}} in my {{.m2/settings.xml}} for the {{http}} protocol. The
> {{maven-javadoc-plugin}} picks this up fine.
> Weirdly, the {{javadoc}} invocation _also_ requires the {{https}} proxy to be
> set. There is no way to accomplish this with the {{maven-javadoc-plugin}}.
> IMHO it should see if there is an active {{}} element whose protocol
> is {{https}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MJAVADOC-483) Needs support for https.proxySet etc.
Laird Nelson created MJAVADOC-483:
-
Summary: Needs support for https.proxySet etc.
Key: MJAVADOC-483
URL: https://issues.apache.org/jira/browse/MJAVADOC-483
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 2.10.4
Reporter: Laird Nelson
I work at a ginormous company that has a proxy server. I have an active
{{}} in my {{.m2/settings.xml}} for the {{http}} protocol. The
{{maven-javadoc-plugin}} picks this up fine.
Weirdly, the {{javadoc}} invocation _also_ requires the {{https}} proxy to be
set. There is no way to accomplish this with the {{maven-javadoc-plugin}}.
IMHO it should see if there is an active {{}} element whose protocol is
{{https}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MINDEXER-81) Make ArtifactInfo extensible
[
https://issues.apache.org/jira/browse/MINDEXER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949969#comment-15949969
]
Laird Nelson commented on MINDEXER-81:
--
I have a concrete use case that I'll elaborate here. I am a new user of Lucene
(no idea what I'm doing :-)) and of the Maven Indexer. Hopefully my
explanation below will give you insight into how a person new to this project
approaches it.
I'd like to write an {{IndexCreator}} that, in the abstract, adds fields to the
index that represent certain contents of {{META-INF/MANIFEST.MF}} files. I'd
like to let users search, for example, for artifacts containing
{{META-INF/MANIFEST.MF}} files with {{Fred}} in their {{Class-Path}} headers.
I see no way to simply write an {{IndexCreator}} (and no other code) to do
this. It seems that I would (with the current architecture) have to edit
{{ArtifactInfo}} to have some new instance variables to store this information.
It also looks like other {{IndexCreator}} implementations that work with
{{META-INF/MANIFEST.MF}} files, like the {{OsgiArtifactIndexCreator}}, do
exactly this: I note that {{ArtifactInfo}}, though it would seem to _want_ to
be a generic sort of class, has fields in it like
[{{bundleSymbolicName}}|https://github.com/apache/maven-indexer/blob/master/indexer-core/src/main/java/org/apache/maven/index/ArtifactInfo.java#L236],
suggesting that for every indexer an edit to {{ArtifactInfo}}'s source code is
necessary. This shouldn't be the case.
> Make ArtifactInfo extensible
>
>
> Key: MINDEXER-81
> URL: https://issues.apache.org/jira/browse/MINDEXER-81
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Cservenak, Tamas
> Fix For: 6.0
>
>
> Make ArtifactInfo extensible, a followup of MINDEXER-32
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6190) maven-resolver-provider's DefaultArtifactDescriptorReader has mismatched constructor and initService methods
Laird Nelson created MNG-6190:
-
Summary: maven-resolver-provider's DefaultArtifactDescriptorReader
has mismatched constructor and initService methods
Key: MNG-6190
URL: https://issues.apache.org/jira/browse/MNG-6190
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.5.0-alpha-1
Reporter: Laird Nelson
In {{DefaultArtifactDescriptorReader.java}}, the constructor annotated with
{{@Inject}} differs in the parameters it takes from its {{initService()}}
method.
This discrepancy means among other things that its {{versionRangeResolver}}
field is never initialized when a DI container is doing injection.
Here is the relevant code, starting at line 112, with a comment where the
problem is:
{code}
@Inject
DefaultArtifactDescriptorReader( RemoteRepositoryManager
remoteRepositoryManager, VersionResolver versionResolver,
ArtifactResolver artifactResolver,
ModelBuilder modelBuilder,
RepositoryEventDispatcher
repositoryEventDispatcher, LoggerFactory loggerFactory )
{
setRemoteRepositoryManager( remoteRepositoryManager );
setVersionResolver( versionResolver );
// XXX <-- Note: no versionRangeResolver
setArtifactResolver( artifactResolver );
setModelBuilder( modelBuilder );
setLoggerFactory( loggerFactory );
setRepositoryEventDispatcher( repositoryEventDispatcher );
}
public void initService( ServiceLocator locator )
{
setLoggerFactory( locator.getService( LoggerFactory.class ) );
setRemoteRepositoryManager( locator.getService(
RemoteRepositoryManager.class ) );
setVersionResolver( locator.getService( VersionResolver.class ) );
setVersionRangeResolver( locator.getService( VersionRangeResolver.class
) );
setArtifactResolver( locator.getService( ArtifactResolver.class ) );
setRepositoryEventDispatcher( locator.getService(
RepositoryEventDispatcher.class ) );
modelBuilder = locator.getService( ModelBuilder.class );
if ( modelBuilder == null )
{
setModelBuilder( new DefaultModelBuilderFactory().newInstance() );
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MRESOLVER-19) DefaultRepositorySystem resolveDependencies() line 370 can yield a NullPointerException
[
https://issues.apache.org/jira/browse/MRESOLVER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MRESOLVER-19:
--
Description:
If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
Starting from line 366:
{code}
ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
DependencyFilter filter = request.getFilter();
DependencyVisitor visitor = ( filter != null ) ? new
FilteringDependencyVisitor( builder, filter ) : builder;
visitor = new TreeDependencyVisitor( visitor );
result.getRoot().accept( visitor ); // <-- if getRoot() is null: kaboom!
List requests = builder.getRequests();
{code}
This is the relevant section of my code that causes the error:
{code}
final CollectRequest collectRequest = new CollectRequest();
collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
collectRequest.setRepositories(Collections.singletonList(mavenCentral));
final DependencyRequest dependencyRequest = new
DependencyRequest(collectRequest, classpathFilter);
final DependencyResult dependencyResult =
repositorySystem.resolveDependencies(repositorySystemSession,
dependencyRequest);
{code}
>From looking inside {{DefaultRepositorySystem.java}}, it looks like the
>collection result never gets its root set. At line 340 and following you see
>this:
{code}
if ( request.getRoot() != null )
{
result.setRoot( request.getRoot() );
}
else if ( request.getCollectRequest() != null )
{
CollectResult collectResult;
try
{
request.getCollectRequest().setTrace( trace );
collectResult = dependencyCollector.collectDependencies( session,
request.getCollectRequest() );
}
catch ( DependencyCollectionException e )
{
dce = e;
collectResult = e.getResult();
}
result.setRoot( collectResult.getRoot() );
result.setCycles( collectResult.getCycles() );
result.setCollectExceptions( collectResult.getExceptions() );
}
{code}
Note in particular this line:
{code}
result.setRoot( collectResult.getRoot() );
{code}
Unless I'm missing something there's no guarantee that
{{collectResult.getRoot()}} will be non-{{null}} if the collection request
failed.
was:
If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
Starting from line 366:
{code}
ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
DependencyFilter filter = request.getFilter();
DependencyVisitor visitor = ( filter != null ) ? new
FilteringDependencyVisitor( builder, filter ) : builder;
visitor = new TreeDependencyVisitor( visitor );
result.getRoot().accept( visitor ); // <-- if getRoot() is null: kaboom!
List requests = builder.getRequests();
{code}
This is the relevant section of my code that causes the error:
{code}
final CollectRequest collectRequest = new CollectRequest();
collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
collectRequest.setRepositories(Collections.singletonList(mavenCentral));
final DependencyRequest dependencyRequest = new
DependencyRequest(collectRequest, classpathFilter);
final DependencyResult dependencyResult =
repositorySystem.resolveDependencies(repositorySystemSession,
dependencyRequest);
{code}
>From looking inside {{DefaultRepositorySystem.java}}, it looks like the
>collection result never gets its root set. At line 357 and following you see
>this:
{code}
if ( request.getRoot() != null )
{
result.setRoot( request.getRoot() );
}
else if ( request.getCollectRequest() != null )
{
CollectResult collectResult;
try
{
request.getCollectRequest().setTrace( trace );
collectResult = dependencyCollector.collectDependencies( session,
request.getCollectRequest() );
}
catch ( DependencyCollectionException e )
{
dce = e;
collectResult = e.getResult();
}
result.setRoot( collectResult.getRoot() );
result.setCycles( collectResult.getCycles() );
result.setCollectExceptions( collectResult.getExceptions() );
}
{code}
Note in particular this line:
{code}
result.setRoot( collectResult.getRoot() );
{code}
Unless I'm missing something there's no guarantee that
{{collectResult.getRoot()}} will be non-{{null}} if the collection request
failed.
> DefaultRepositorySystem resolveDependencies() line 370 can yield a
> NullPointerException
> ---
>
> Key: MRESOLVER-19
> URL: https://issues.apache.org/jira/browse/MRESOLVER-19
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Laird Nelson
>
> If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
> Starting from line 366:
> {code}
> ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
> Dependen
[jira] [Created] (MRESOLVER-19) DefaultRepositorySystem resolveDependencies() line 370 can yield a NullPointerException
Laird Nelson created MRESOLVER-19:
-
Summary: DefaultRepositorySystem resolveDependencies() line 370
can yield a NullPointerException
Key: MRESOLVER-19
URL: https://issues.apache.org/jira/browse/MRESOLVER-19
Project: Maven Resolver
Issue Type: Bug
Components: resolver
Affects Versions: Maven Artifact Resolver 1.0.3
Reporter: Laird Nelson
If a transfer of an artifact fails, then a {{NullPointerException}} is thrown.
Starting from line 366:
{code}
ArtifactRequestBuilder builder = new ArtifactRequestBuilder( trace );
DependencyFilter filter = request.getFilter();
DependencyVisitor visitor = ( filter != null ) ? new
FilteringDependencyVisitor( builder, filter ) : builder;
visitor = new TreeDependencyVisitor( visitor );
result.getRoot().accept( visitor ); // <-- if getRoot() is null: kaboom!
List requests = builder.getRequests();
{code}
This is the relevant section of my code that causes the error:
{code}
final CollectRequest collectRequest = new CollectRequest();
collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
collectRequest.setRepositories(Collections.singletonList(mavenCentral));
final DependencyRequest dependencyRequest = new
DependencyRequest(collectRequest, classpathFilter);
final DependencyResult dependencyResult =
repositorySystem.resolveDependencies(repositorySystemSession,
dependencyRequest);
{code}
>From looking inside {{DefaultRepositorySystem.java}}, it looks like the
>collection result never gets its root set. At line 357 and following you see
>this:
{code}
if ( request.getRoot() != null )
{
result.setRoot( request.getRoot() );
}
else if ( request.getCollectRequest() != null )
{
CollectResult collectResult;
try
{
request.getCollectRequest().setTrace( trace );
collectResult = dependencyCollector.collectDependencies( session,
request.getCollectRequest() );
}
catch ( DependencyCollectionException e )
{
dce = e;
collectResult = e.getResult();
}
result.setRoot( collectResult.getRoot() );
result.setCycles( collectResult.getCycles() );
result.setCollectExceptions( collectResult.getExceptions() );
}
{code}
Note in particular this line:
{code}
result.setRoot( collectResult.getRoot() );
{code}
Unless I'm missing something there's no guarantee that
{{collectResult.getRoot()}} will be non-{{null}} if the collection request
failed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345435#comment-345435
]
Laird Nelson edited comment on MJAVADOC-393 at 4/27/14 1:29 PM:
Added a link to the [JDK bug|https://bugs.openjdk.java.net/browse/JDK-8038976]
that requires a trailing slash for the {{-link}} option to javadoc.
was (Author: ljnelson):
Link to JDK bug that requires a trailing slash for the {{-link}} option to
javadoc.
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch
>
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Patch Submitted: Yes
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: MJAVADOC-395.patch
>
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Attachment: MJAVADOC-395.patch
Submitted a patch file (from the root of the {{maven-javadoc-plugin}} source
tree using {{diff -runP}}) that incorporates the changes necessary to include
javadoc 8 support.
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: MJAVADOC-395.patch
>
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Description:
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
{{src/main/resources}} to enable existing tests to pass.
Patch forthcoming.
was:
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Patch forthcoming.
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-393:
--
Patch Submitted: Yes
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch
>
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-393:
--
Attachment: AbstractJavadocMojo.java.MJAVADOC-393.patch
Submitted a patch correcting the trailing-slash-stripping behavior now that
javadoc 1.8 no longer deals properly with non-slash-terminated {{-link}}
options.
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch
>
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
Laird Nelson created MJAVADOC-395:
-
Summary: Add JDK8 support to maven-javadoc-plugin
Key: MJAVADOC-395
URL: https://jira.codehaus.org/browse/MJAVADOC-395
Project: Maven Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Laird Nelson
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345156#comment-345156
]
Laird Nelson commented on MJAVADOC-394:
---
For completeness, a workaround without changing code is to define the following
in your {{$HOME/.mavenrc}} file (on OSX only, obviously):
{code:lang=none}
export JAVA_HOME=`/usr/libexec/java_home`
{code}
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as well--anyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-394:
--
Description:
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as well--anyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
was:
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as wellâanyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
Patch Submitted: Yes
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as well--anyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-394:
--
Attachment: AbstractJavadocMojo.java.patch
Submitted a patch file ensuring that the proper default resolution of the
{{javadoc}} script occurs on Mac OSX.
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as wellâanyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
Laird Nelson created MJAVADOC-394:
-
Summary: javadoc is not found properly by default under Oracle's
JDK 7+ on Mac OSX
Key: MJAVADOC-394
URL: https://jira.codehaus.org/browse/MJAVADOC-394
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Mac OSX, JDK 1.7+
Reporter: Laird Nelson
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as wellâanyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345095#comment-345095
]
Laird Nelson commented on MJAVADOC-393:
---
Line 3932, sorry.
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
Laird Nelson created MJAVADOC-393:
-
Summary: -link option values have their trailing slash removed;
breaks javadoc 8
Key: MJAVADOC-393
URL: https://jira.codehaus.org/browse/MJAVADOC-393
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Laird Nelson
The version of {{javadoc}} that ships with Java 8 has changed such that any
value supplied to the {{-link}} option must have a trailing slash (at least on
my Mac).
Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the trailing
slashes from the {{links}} property elements, ensuring that {{javadoc}} version
8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGINTESTING-34) Documentation: sample code using MojoRule doesn't work
Laird Nelson created MPLUGINTESTING-34:
--
Summary: Documentation: sample code using MojoRule doesn't work
Key: MPLUGINTESTING-34
URL: https://jira.codehaus.org/browse/MPLUGINTESTING-34
Project: Maven Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Affects Versions: 3.0.0
Reporter: Laird Nelson
The cookbook reachable from
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
includes code like this:
{code:java}
File pom = rule.getTestFile( "src/test/resources/unit/project-to-test/pom.xml"
);
{code}
This method does not exist on {{MojoRule}}
(http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/apidocs/org/apache/maven/plugin/testing/MojoRule.html).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-620) The dependencySet/includes/include format is documented incorrectly
Laird Nelson created MASSEMBLY-620:
--
Summary: The dependencySet/includes/include format is documented
incorrectly
Key: MASSEMBLY-620
URL: https://jira.codehaus.org/browse/MASSEMBLY-620
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Laird Nelson
The proper format for {{}} elements should be:
{code}
groupId:artifactId:type:classifier[:version]
{code}
The
[documentation|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet]
given by the {{maven-assembly-plugin}} says (incorrectly):
{quote}
Artifact coordinatess may be given in simple groupId:artifactId form, or they
may be fully qualified in the form groupId:artifactId:type:version[:classifier].
{quote}
Additionally, the Sonatype book
[says|http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-controlling-contents.html#assemblies-sect-fine-tune]
(incorrectly? or maybe just confusingly):
{quote}
groupId:artifactId:type[:classifier]:version - full artifact identity
If you need to get really specific, you can specify all the coordinates.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-332) unpack-dependencies needs a skip parameter like unpack
unpack-dependencies needs a skip parameter like unpack
--
Key: MDEP-332
URL: https://jira.codehaus.org/browse/MDEP-332
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack-dependencies
Affects Versions: 2.3
Reporter: Laird Nelson
Assignee: Brian Fox
The {{unpack}} goal has a {{skip}} parameter that skips execution. The
{{unpack-dependencies}} goal does not have such a parameter. It should.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-712) Either tag option is ignored in branch goal or documentation is incomplete
Either tag option is ignored in branch goal or documentation is incomplete
--
Key: MRELEASE-712
URL: https://jira.codehaus.org/browse/MRELEASE-712
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.2.1
Reporter: Laird Nelson
The plugin documentation for the branch goal [specifies a "tag"
option|http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html#tag].
It is not clear what this tag option is for.
If you supply it during a branch operation, it appears to be ignored.
I attempted in this command line to create a branch named foobar-0.5.X from a
tag named foobar-0.5. Instead the branch was created from the trunk:
{code}
mvn release:branch -DbranchName=foobar-0.5.X -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -Dtag=foobar-0.5
{code}
The output included this:
{code}
[INFO] Executing: /bin/sh -c cd /Users/ljnelson/Projects/foobar && svn
--non-interactive copy --file
/var/folders/BT/BT0U2CqlGHuq-S5z-Xo+6E+++TI/-Tmp-/maven-scm-1493371414.commit
--revision 964 http://blargh.com/svnrepos/foobar/trunk/foobar
http://blargh.com/svnrepos/foobar/branches/foobar-0.5.X
{code}
Note the copy from the trunk to the new branch. I was expecting the copy to be
from {{^/tags/foobar-0.5}} to the new branch.
Perhaps this is not what the tag option is for in the branch goal. If so, then
the documentation for the tag option needs to be clarified.
Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson closed MEAR-143.
-
Resolution: Not A Bug
[This StackOverflow
answer|http://stackoverflow.com/questions/7588492/maven-dependency-resolution-and-scope-overriding-not-just-another-newbie-questio/7597596#7597596]
helped educate me on the fact that dependency management trumps dependency
mediation even for scope, which I had not realized.
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280178#comment-280178
]
Laird Nelson edited comment on MEAR-143 at 9/28/11 9:05 AM:
I assume you're trying to point me to the text that reads:
{quote}
In addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.
{quote}
But I was under the impression that if I "overrode" the scope the overridden
scope would be honored? Note that the document to which you referred me does
not address scope overriding.
Note as well that the {{}} section initially defines
{{mear-143-leaf}}'s scope to be {{test}}. But the actual {{}}
information in {{mear-143-middle}} overrides the scope to be {{runtime}}.
Shouldn't the scope of the ear file's transitive {{mear-143-leaf}} dependency
therefore be {{runtime}}? No?
I based my theory off of
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management,
specifically the section that begins "A second and very important use...".
Note that in project B in that section project B overrides the scope of {{c}}
to be {{runtime}}.
was (Author: ljnelson):
I assume you're trying to point me to the text that reads:
{quote}
In addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.
{quote}
But I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
I based my theory off of
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management,
specifically the section that begins "A second and very important use...".
Note that in project B in that section project B overrides the scope of {{c}}
to be {{runtime}}.
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280178#comment-280178
]
Laird Nelson edited comment on MEAR-143 at 9/28/11 9:03 AM:
I assume you're trying to point me to the text that reads:
{quote}
In addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.
{quote}
But I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
I based my theory off of
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management,
specifically the section that begins "A second and very important use...".
Note that in project B in that section project B overrides the scope of {{c}}
to be {{runtime}}.
was (Author: ljnelson):
I assume you're trying to point me to the text that reads:
{quote}
In addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.
{quote}
But I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280178#comment-280178
]
Laird Nelson edited comment on MEAR-143 at 9/28/11 8:53 AM:
I assume you're trying to point me to the text that reads:
{quote}
In addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.
{quote}
But I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
was (Author: ljnelson):
I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280178#comment-280178
]
Laird Nelson edited comment on MEAR-143 at 9/28/11 8:48 AM:
I was under the impression that if I "overrode" the scope the overridden scope
would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in mear-143-middle
overrides the scope to be runtime. Shouldn't the scope of the ear file's
transitive mear-143-leaf dependency therefore be runtime? No?
was (Author: ljnelson):
I was under the impression that if I "overrode" the scope the overridden
scope would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in the ear file
overrides the scope to be runtime. Shouldn't the scope of the dependency
therefore be runtime? No?
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280178#comment-280178
]
Laird Nelson commented on MEAR-143:
---
I was under the impression that if I "overrode" the scope the overridden scope
would be honored?
Note that the dependencyManagement section initially defines mear-143-leaf's
scope to be "test". But the actual dependency information in the ear file
overrides the scope to be runtime. Shouldn't the scope of the dependency
therefore be runtime? No?
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MEAR-143:
--
Attachment: mear-143.zip
A test case demonstrating the problem, or demonstrating my misunderstanding
(one or the other).
Unzip and run mvn clean install and then look at the resulting .ear project
(and study the pom.xml files).
Note that the .ear project does not contain mear-143-leaf.jar. It is my
understanding that it should.
When dependency management of mear-143-leaf.jar is eliminated, this works as
expected. Is this a bug or a misunderstanding on my part about how dependency
management works?
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280168#comment-280168
]
Laird Nelson commented on MEAR-143:
---
Ha, got a test case that reproduces it; will attach it in a moment. The
problem is with dependency management and scope overriding.
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280167#comment-280167
]
Laird Nelson commented on MEAR-143:
---
Yes; interestingly the simple test case I'm putting together does not manifest
this bug. There must be another wrinkle to it as this is demonstrable in our
main product. I will (hopefully) attach my test case shortly or close the bug
and chalk it up to magic. I am thinking that dependency management plays a
part here.
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-143) Plugin does not respect transitive dependency scopes properly
Plugin does not respect transitive dependency scopes properly
-
Key: MEAR-143
URL: https://jira.codehaus.org/browse/MEAR-143
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Laird Nelson
The [Introduction to the Dependency Mechanism
page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
has a handy table for deciding what to do with transitive dependencies and
various scopes. The Maven ear plugin does not honor it in all cases.
Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
{{runtime}} dependency on {{a.jar}}.
Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
dependency on {{b.jar}}.
By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
dependency (transitively) of the {{.ear}}, and should be included in the
{{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml
No way to programmatically generate env-entry elements in generated
application.xml
---
Key: MEAR-141
URL: https://jira.codehaus.org/browse/MEAR-141
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Laird Nelson
The maven-ear-plugin offers the {{security}} element for declaring
security-role-names in a generated application.xml. It does not offer such a
facility for generating {{env-entry}} elements. It should.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
https://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274931#comment-274931
]
Laird Nelson commented on MNG-4687:
---
No, please do not do automatic local resolution.
In a large project where pom.xml changes are made relatively frequently,
sometimes users do not do, say, an {{svn update}}. In such a case a local
build will reference what is effectively an out-of-date pom. If automatic
filesystem resolution were turned on, there would be no way to force Maven to
go get the pom from the repo. Unless, of course, I'm missing something.
> Maven should not warn about incorrect parent path when no relativePath is
> specified
> ---
>
> Key: MNG-4687
> URL: https://jira.codehaus.org/browse/MNG-4687
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 3.0-beta-1
>Reporter: Paul Gier
>Priority: Minor
> Attachments: MNG-relativePath.zip
>
>
> If a module pom uses a parent other than the one in the parent directory,
> maven logs a warning. In some cases it is necessary that a module pom has an
> external parent pom, and there is no way to refer to this external pom in the
> relativePath. If nothing is specified in the relativePath, Maven should not
> log the warning.
> {noformat}
> [WARNING] 'parent.relativePath' of POM
> org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
> (/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
> org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
> please verify your project structure @
> {noformat}
> The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-359) fail on mvn install with a archetype created from create-from-project command having required property in archetype-metadata.xml
[
http://jira.codehaus.org/browse/ARCHETYPE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated ARCHETYPE-359:
---
Attachment: archetype359.tar.gz
Oh for goodness' sake. Here's a small project that reproduces (trivially) the
problem.
I assembled the project by doing this:
mvn clean archetype:create-from-project
(edited
target/generated-sources/archetype/src/main/resources/META-INF/maven/archetype-metadata.xml;
added required properties section)
To reproduce the issue, go into target/generated-sources/archetype and do mvn
install.
> fail on mvn install with a archetype created from create-from-project command
> having required property in archetype-metadata.xml
>
>
> Key: ARCHETYPE-359
> URL: http://jira.codehaus.org/browse/ARCHETYPE-359
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 2.0
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
> Java version: 1.6.0_21
> Java home: C:\Program Files\Java\jdk1.6.0_18\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Abhishek Sharma
>Priority: Blocker
> Attachments: archetype359.tar.gz, output.txt
>
>
> mvn install fails when archetype-metadata.xml having required property entry.
> {noformat}[INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building quipoz-qte-project-archetype-archetype
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 25 resources
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 2 resources
> [INFO] [archetype:jar {execution: default-jar}]
> [INFO] [archetype:add-archetype-metadata {execution:
> default-add-archetype-metadata}]
> [INFO] [archetype:integration-test {execution: default-integration-test}]
> [ERROR] Archetype
> quipoz-qte-project-archetype:quipoz-qte-project-archetype-archetype:0.0.1-SNAPSHOT
> is not configured
> Property check is missing.
> org.apache.maven.archetype.exception.ArchetypeNotConfigured: Archetype
> quipoz-qte-project-archetype:quipoz-qte-project-archetype-archetype:0.0.1-SNAPSHOT
> is not configured
> Property check is missing.
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype(DefaultFilesetArchetypeGenerator.java:128)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype(DefaultArchetypeGenerator.java:136)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:106)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:149)
> at
> org.apache.maven.archetype.mojos.IntegrationTestMojo.processIntegrationTest(IntegrationTestMojo.java:237)
> at
> org.apache.maven.archetype.mojos.IntegrationTestMojo.execute(IntegrationTestMojo.java:108)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> a
[jira] Commented: (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element
[
http://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=237572#action_237572
]
Laird Nelson commented on SUREFIRE-649:
---
I neglected to set the priority down from major, as the workaround is simply to
continue to use the deprecated systemProperties stanza. My apologies.
> Might be impossible to have empty strings in systemPropertyVariables element
>
>
> Key: SUREFIRE-649
> URL: http://jira.codehaus.org/browse/SUREFIRE-649
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: surefireEmptyStringIssue.tar.gz
>
>
> This stanza:
>
>
> emptyProperty
>
>
>
> ...yields "" from System.getProperty("emptyProperty").
> This (supposedly better) stanza:
>
>
>
> ...yields null from System.getProperty("emptyProperty").
> A test case is attached that demonstrates the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element
Might be impossible to have empty strings in systemPropertyVariables element
Key: SUREFIRE-649
URL: http://jira.codehaus.org/browse/SUREFIRE-649
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Attachments: surefireEmptyStringIssue.tar.gz
This stanza:
emptyProperty
...yields "" from System.getProperty("emptyProperty").
This (supposedly better) stanza:
...yields null from System.getProperty("emptyProperty").
A test case is attached that demonstrates the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225995#action_225995 ] Laird Nelson commented on MNG-2258: --- This bug is still present in Maven 2.2.1. My project runs a goal from maven-dependency-plugin, maven-resources-plugin and maven-jar-plugin during the prepare-package phase. These are listed in that order. They are executed in an arbitrary order. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Blocker > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4601) More options for activating profiles, specifically file in path
More options for activating profiles, specifically file in path --- Key: MNG-4601 URL: http://jira.codehaus.org/browse/MNG-4601 Project: Maven 2 & 3 Issue Type: New Feature Components: Profiles Affects Versions: 3.0-alpha-7, 3.0-alpha-6, 2.2.1 Reporter: Laird Nelson Priority: Minor It would be nice to test for the presence of a given command or file in the user's PATH as a condition for activating a profile. My specific use case is that I want to change the way Javadocs are output if graphviz's dot.exe program is in the path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4479) [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638 ] Laird Nelson commented on MNG-4479: --- Perhaps consider applying the fix to the 2.1 branch? > [regression] Project-level plugin dependencies ignored for direct CLI > invocation if plugin key uses properties > -- > > Key: MNG-4479 > URL: http://jira.codehaus.org/browse/MNG-4479 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading, Dependencies, Plugins and Lifecycle >Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1 >Reporter: Laird Nelson >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-2 > > Attachments: mng-4479.zip > > > I have a plugin that makes use of the implementation attribute in its > configuration. That is, one of its parameters is a plexus tag that specifies > an implementation class to use. > The implementation class comes from a jar that is the plugin's dependency, > but that dependency is included as part of the plugin configuration, not as > part of the stock plugin. > This setup works fine when I bind the plugin's configuration via an execution > to a normal phase (generate-sources as it happens). > When I bind the plugin's configuration to the default-cli execution, plexus > cannot configure the component, claiming that the classname it encounters in > the "implementation" attribute cannot be found (even though, again, if I bind > it to the generate-sources phase instead, via another execution, same > configuration, everything works fine. > I tried to debug this using mvn -X, but the output was totally baffling; > sorry. My raw take is that it looks like dependency resolution in the > default-cli execution is somehow performed differently than when the plugin > is run bound to a phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4479) [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638 ] Laird Nelson edited comment on MNG-4479 at 12/7/09 7:07 PM: Perhaps consider applying the fix to the 2.2.1 branch? was (Author: ljnelson): Perhaps consider applying the fix to the 2.1 branch? > [regression] Project-level plugin dependencies ignored for direct CLI > invocation if plugin key uses properties > -- > > Key: MNG-4479 > URL: http://jira.codehaus.org/browse/MNG-4479 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading, Dependencies, Plugins and Lifecycle >Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1 >Reporter: Laird Nelson >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-2 > > Attachments: mng-4479.zip > > > I have a plugin that makes use of the implementation attribute in its > configuration. That is, one of its parameters is a plexus tag that specifies > an implementation class to use. > The implementation class comes from a jar that is the plugin's dependency, > but that dependency is included as part of the plugin configuration, not as > part of the stock plugin. > This setup works fine when I bind the plugin's configuration via an execution > to a normal phase (generate-sources as it happens). > When I bind the plugin's configuration to the default-cli execution, plexus > cannot configure the component, claiming that the classname it encounters in > the "implementation" attribute cannot be found (even though, again, if I bind > it to the generate-sources phase instead, via another execution, same > configuration, everything works fine. > I tried to debug this using mvn -X, but the output was totally baffling; > sorry. My raw take is that it looks like dependency resolution in the > default-cli execution is somehow performed differently than when the plugin > is run bound to a phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4479) Dependency resolution for plugins with default-cli execution happens too late
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201209#action_201209 ] Laird Nelson commented on MNG-4479: --- Quite right of course. See attachment. Now hopefully it won't hang around for quite some time! :-) > Dependency resolution for plugins with default-cli execution happens too late > - > > Key: MNG-4479 > URL: http://jira.codehaus.org/browse/MNG-4479 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading, Dependencies, Plugins and Lifecycle >Affects Versions: 2.2.1 >Reporter: Laird Nelson > Attachments: mng-4479.zip > > > I have a plugin that makes use of the implementation attribute in its > configuration. That is, one of its parameters is a plexus tag that specifies > an implementation class to use. > The implementation class comes from a jar that is the plugin's dependency, > but that dependency is included as part of the plugin configuration, not as > part of the stock plugin. > This setup works fine when I bind the plugin's configuration via an execution > to a normal phase (generate-sources as it happens). > When I bind the plugin's configuration to the default-cli execution, plexus > cannot configure the component, claiming that the classname it encounters in > the "implementation" attribute cannot be found (even though, again, if I bind > it to the generate-sources phase instead, via another execution, same > configuration, everything works fine. > I tried to debug this using mvn -X, but the output was totally baffling; > sorry. My raw take is that it looks like dependency resolution in the > default-cli execution is somehow performed differently than when the plugin > is run bound to a phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4479) Dependency resolution for plugins with default-cli execution happens too late
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laird Nelson updated MNG-4479: -- Attachment: mng-4479.zip Reproducible test projects attached. To build and reproduce: mvn clean install in mng-4479-plugin mvn clean install in mng-4479-implementations Then in mng-4479-harness: First do mvn generate-sources. Observe that the build completes normally. Next do mvn mavenbugs:mng-4479-plugin:frobnicate. Observe that the build fails with the dependency resolution behavior described in this bug. > Dependency resolution for plugins with default-cli execution happens too late > - > > Key: MNG-4479 > URL: http://jira.codehaus.org/browse/MNG-4479 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading, Dependencies, Plugins and Lifecycle >Affects Versions: 2.2.1 >Reporter: Laird Nelson > Attachments: mng-4479.zip > > > I have a plugin that makes use of the implementation attribute in its > configuration. That is, one of its parameters is a plexus tag that specifies > an implementation class to use. > The implementation class comes from a jar that is the plugin's dependency, > but that dependency is included as part of the plugin configuration, not as > part of the stock plugin. > This setup works fine when I bind the plugin's configuration via an execution > to a normal phase (generate-sources as it happens). > When I bind the plugin's configuration to the default-cli execution, plexus > cannot configure the component, claiming that the classname it encounters in > the "implementation" attribute cannot be found (even though, again, if I bind > it to the generate-sources phase instead, via another execution, same > configuration, everything works fine. > I tried to debug this using mvn -X, but the output was totally baffling; > sorry. My raw take is that it looks like dependency resolution in the > default-cli execution is somehow performed differently than when the plugin > is run bound to a phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4479) Dependency resolution for plugins with default-cli execution happens too late
Dependency resolution for plugins with default-cli execution happens too late - Key: MNG-4479 URL: http://jira.codehaus.org/browse/MNG-4479 Project: Maven 2 Issue Type: Bug Components: Class Loading, Dependencies, Plugins and Lifecycle Affects Versions: 2.2.1 Reporter: Laird Nelson I have a plugin that makes use of the implementation attribute in its configuration. That is, one of its parameters is a plexus tag that specifies an implementation class to use. The implementation class comes from a jar that is the plugin's dependency, but that dependency is included as part of the plugin configuration, not as part of the stock plugin. This setup works fine when I bind the plugin's configuration via an execution to a normal phase (generate-sources as it happens). When I bind the plugin's configuration to the default-cli execution, plexus cannot configure the component, claiming that the classname it encounters in the "implementation" attribute cannot be found (even though, again, if I bind it to the generate-sources phase instead, via another execution, same configuration, everything works fine. I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw take is that it looks like dependency resolution in the default-cli execution is somehow performed differently than when the plugin is run bound to a phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-568) Fork mode of "pertest" or "always" does not fork per test or always
Fork mode of "pertest" or "always" does not fork per test or always --- Key: SUREFIRE-568 URL: http://jira.codehaus.org/browse/SUREFIRE-568 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.3, 2.4.2, 2.4.1, 2.4, 2.3.1, 2.3, 2.0 (2.2 plugin), 2.0 Report Plugin, 1.5.3 (2.1.3 plugin), 1.5.2 (2.1.2 plugin), 1.5.1 (2.1.1 plugin), 1.5 (2.1 plugin), 1.4 (2.0 plugin), 1.3 (2.0-beta-1 plugin) Environment: Windows XP, Java 6 update 14, JUnit 4.6 Reporter: Laird Nelson Perhaps this is a misunderstanding, in which case I'd ask for a clarification in the documentation. If I specify a of "always" or "pertest" (which I understand is the same thing), Surefire will fork for each test *class*, but *not* for each @Test within the test class. The documentation led me to believe that surefire would fork once for each method annotated as @Test. (Background: I'm running OpenEJB and H2, and need to ensure that the in-memory H2 database I have set up is zapped in between each test run so that, among other things, the automated DDL generation re-runs for each test.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
