[jira] [Comment Edited] (MSHADE-363) Breaking change to ResourceTransformer's API
[
https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108977#comment-17108977
]
Andy Wilkinson edited comment on MSHADE-363 at 5/16/20, 10:17 AM:
--
Following up on the suggestion to use {{PropertiesTransformer}}, unfortunately
it does not meet our needs. Boot’s transformer combines values for the same key
by comma separating them, i.e we merge the values rather than overriding.
was (Author: awilkinson):
Following up on the suggestion to use {{PropertiesTransformer}, unfortunately
it does not meet our needs. Boot’s transformer combines values for the same key
by comma separating them, i.e we merge the values rather than overriding.
> Breaking change to ResourceTransformer's API
>
>
> Key: MSHADE-363
> URL: https://issues.apache.org/jira/browse/MSHADE-363
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Andy Wilkinson
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.2.4
>
>
> A Spring Boot user has [made us
> aware|https://github.com/spring-projects/spring-boot/issues/21128] of a
> [breaking change to the API of
> ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958]
> in 3.2.3.
> Ideally, we don't want to require a specific version of the Shade plugin.
> While I think we may be able to support the new and old both variants of the
> method, it would be preferable if future 3.2.x releases are backwards
> compatible with 3.2.2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-363) Breaking change to ResourceTransformer's API
[
https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108977#comment-17108977
]
Andy Wilkinson commented on MSHADE-363:
---
Following up on the suggestion to use {{PropertiesTransformer}, unfortunately
it does not meet our needs. Boot’s transformer combines values for the same key
by comma separating them, i.e we merge the values rather than overriding.
> Breaking change to ResourceTransformer's API
>
>
> Key: MSHADE-363
> URL: https://issues.apache.org/jira/browse/MSHADE-363
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Andy Wilkinson
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.2.4
>
>
> A Spring Boot user has [made us
> aware|https://github.com/spring-projects/spring-boot/issues/21128] of a
> [breaking change to the API of
> ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958]
> in 3.2.3.
> Ideally, we don't want to require a specific version of the Shade plugin.
> While I think we may be able to support the new and old both variants of the
> method, it would be preferable if future 3.2.x releases are backwards
> compatible with 3.2.2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-363) Breaking change to ResourceTransformer's API
[
https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099048#comment-17099048
]
Andy Wilkinson commented on MSHADE-363:
---
Thanks for the pointer, Herve. I'd missed the addition of
{{PropertiesTransformer}}. I've opened
[https://github.com/spring-projects/spring-boot/issues/21307] so that we can
make use of it in Spring Boot.
> Breaking change to ResourceTransformer's API
>
>
> Key: MSHADE-363
> URL: https://issues.apache.org/jira/browse/MSHADE-363
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Andy Wilkinson
>Priority: Major
>
> A Spring Boot user has [made us
> aware|https://github.com/spring-projects/spring-boot/issues/21128] of a
> [breaking change to the API of
> ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958]
> in 3.2.3.
> Ideally, we don't want to require a specific version of the Shade plugin.
> While I think we may be able to support the new and old both variants of the
> method, it would be preferable if future 3.2.x releases are backwards
> compatible with 3.2.2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-363) Breaking change to ResourceTransformer's API
[ https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Wilkinson updated MSHADE-363: -- Description: A Spring Boot user has [made us aware|https://github.com/spring-projects/spring-boot/issues/21128] of a [breaking change to the API of ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] in 3.2.3. Ideally, we don't want to require a specific version of the Shade plugin. While I think we may be able to support the new and old both variants of the method, it would be preferable if future 3.2.x releases are backwards compatible with 3.2.2. was: A Spring Boot user has [made us aware|https://github.com/spring-projects/spring-boot/issues/21128] of a [breaking change to the API of ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] in 3.2.3. Ideally, we don't want to require a specific version of the Shade plugin. While I think we may be able to support the new and old both variants of the method, it would be preferable if 3.2.3 was backwards compatible with 3.2.2. > Breaking change to ResourceTransformer's API > > > Key: MSHADE-363 > URL: https://issues.apache.org/jira/browse/MSHADE-363 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Andy Wilkinson >Priority: Major > > A Spring Boot user has [made us > aware|https://github.com/spring-projects/spring-boot/issues/21128] of a > [breaking change to the API of > ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] > in 3.2.3. > Ideally, we don't want to require a specific version of the Shade plugin. > While I think we may be able to support the new and old both variants of the > method, it would be preferable if future 3.2.x releases are backwards > compatible with 3.2.2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-363) Breaking change to ResourceTransformer's API
[ https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097361#comment-17097361 ] Andy Wilkinson edited comment on MSHADE-363 at 5/1/20, 1:45 PM: If reverting the change is not an option, requiring Java 8 and adding a default method is the only thing that I can think of. was (Author: awilkinson): If reverting the change is not an option, requiring Java 8 and adding a default method is thing that I can think of. > Breaking change to ResourceTransformer's API > > > Key: MSHADE-363 > URL: https://issues.apache.org/jira/browse/MSHADE-363 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Andy Wilkinson >Priority: Major > > A Spring Boot user has [made us > aware|https://github.com/spring-projects/spring-boot/issues/21128] of a > [breaking change to the API of > ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] > in 3.2.3. > Ideally, we don't want to require a specific version of the Shade plugin. > While I think we may be able to support the new and old both variants of the > method, it would be preferable if 3.2.3 was backwards compatible with 3.2.2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-363) Breaking change to ResourceTransformer's API
[ https://issues.apache.org/jira/browse/MSHADE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097361#comment-17097361 ] Andy Wilkinson commented on MSHADE-363: --- If reverting the change is not an option, requiring Java 8 and adding a default method is thing that I can think of. > Breaking change to ResourceTransformer's API > > > Key: MSHADE-363 > URL: https://issues.apache.org/jira/browse/MSHADE-363 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.3 >Reporter: Andy Wilkinson >Priority: Major > > A Spring Boot user has [made us > aware|https://github.com/spring-projects/spring-boot/issues/21128] of a > [breaking change to the API of > ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] > in 3.2.3. > Ideally, we don't want to require a specific version of the Shade plugin. > While I think we may be able to support the new and old both variants of the > method, it would be preferable if 3.2.3 was backwards compatible with 3.2.2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHADE-363) Breaking change to ResourceTransformer's API
Andy Wilkinson created MSHADE-363: - Summary: Breaking change to ResourceTransformer's API Key: MSHADE-363 URL: https://issues.apache.org/jira/browse/MSHADE-363 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.2.3 Reporter: Andy Wilkinson A Spring Boot user has [made us aware|https://github.com/spring-projects/spring-boot/issues/21128] of a [breaking change to the API of ResourceTransformer|https://github.com/apache/maven-shade-plugin/commit/0d7bfb53a5fd83eede7edfd5552db5fa561d6286#diff-f09094e2212bb4d1173a4e183635b958] in 3.2.3. Ideally, we don't want to require a specific version of the Shade plugin. While I think we may be able to support the new and old both variants of the method, it would be preferable if 3.2.3 was backwards compatible with 3.2.2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPH-162) Allow EffectiveHelpMojo to be configured to produce repeatable output
[ https://issues.apache.org/jira/browse/MPH-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995075#comment-16995075 ] Andy Wilkinson commented on MPH-162: Yes, I should be able to do that. When you say "it" do you mean just the timestamp or the entire header comment? > Allow EffectiveHelpMojo to be configured to produce repeatable output > - > > Key: MPH-162 > URL: https://issues.apache.org/jira/browse/MPH-162 > Project: Maven Help Plugin > Issue Type: Improvement > Components: effective-pom >Affects Versions: 3.2.0 >Reporter: Andy Wilkinson >Priority: Major > > When an effective pom is generated, a header comment is added that includes a > timestamp. This prevents the output from being repeatable. Could a > configuration option to disable the timestamp or the entire header comment be > provided please? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MPH-162) Allow EffectiveHelpMojo to be configured to produce repeatable output
Andy Wilkinson created MPH-162: -- Summary: Allow EffectiveHelpMojo to be configured to produce repeatable output Key: MPH-162 URL: https://issues.apache.org/jira/browse/MPH-162 Project: Maven Help Plugin Issue Type: Improvement Components: effective-pom Affects Versions: 3.2.0 Reporter: Andy Wilkinson When an effective pom is generated, a header comment is added that includes a timestamp. This prevents the output from being repeatable. Could a configuration option to disable the timestamp or the entire header comment be provided please? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break test bootstrapping in subsequent modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886805#comment-16886805
]
Andy Wilkinson commented on SUREFIRE-1679:
--
[~tibordigana], how would you like the changes to {{ClasspathCache}} to be
handled? As things stand its {{CLASSPATHS}} map and all of its methods are
{{static}} and they need to be instance-scoped instead. It's only used by
{{AbstractSurefireMojo}} as far as I can tell, but it is a public class. What's
the preferred way of handling breaking API changes, both in a 3.0 milestone and
in a 2.22.x maintenance release?
FWIW, my instinct is to deprecate {{ClasspathCache}}, leave it otherwise
unchanged, and create a private inner-class in {{AbstractSurefireMojo}} that
serves the required purpose without being part of the public API.
> Caching of provider classpath with module-specific changes may break test
> bootstrapping in subsequent modules
> -
>
> Key: SUREFIRE-1679
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Andy Wilkinson
>Priority: Major
> Fix For: 3.0.0-M4
>
> Attachments: surefire-pollution-problem.zip
>
>
> I believe I've identified a bug in the caching that's performed by
> {{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
> bootstrap Surefire:
>
> {noformat}
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.NoClassDefFoundError:
> org/junit/platform/launcher/core/LauncherFactory
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
>
> This is in a module that uses Surefire and JUnit Jupiter 5.5:
>
> {noformat}
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
[jira] [Commented] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break test bootstrapping in subsequent modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886748#comment-16886748
]
Andy Wilkinson commented on SUREFIRE-1679:
--
Sounds good to me. Thanks.
> Caching of provider classpath with module-specific changes may break test
> bootstrapping in subsequent modules
> -
>
> Key: SUREFIRE-1679
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Andy Wilkinson
>Priority: Major
> Fix For: 3.0.0-M4
>
> Attachments: surefire-pollution-problem.zip
>
>
> I believe I've identified a bug in the caching that's performed by
> {{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
> bootstrap Surefire:
>
> {noformat}
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.NoClassDefFoundError:
> org/junit/platform/launcher/core/LauncherFactory
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
>
> This is in a module that uses Surefire and JUnit Jupiter 5.5:
>
> {noformat}
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.2
>
>
>
> {noformat}
>
> Earlier in the reactor, another project is built which depends on
> {{junit-platform-launcher}}:
>
> {noformat}
>
>
> org.junit.platform
> junit-platform-launcher
> 1.5.0
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.2
>
>
>
> {noformat}
[jira] [Commented] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break test bootstrapping in subsequent modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886239#comment-16886239
]
Andy Wilkinson commented on SUREFIRE-1679:
--
Thanks, Tibor. I'd be happy to try and contribute a pull request that fixes the
problem. I notice that you've set 3.0.0-M4 as the fix version. To be able to
justify spending time on it, I'd really like a fix in 2.22.x. Would that be
possible?
> Caching of provider classpath with module-specific changes may break test
> bootstrapping in subsequent modules
> -
>
> Key: SUREFIRE-1679
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Andy Wilkinson
>Priority: Major
> Fix For: 3.0.0-M4
>
> Attachments: surefire-pollution-problem.zip
>
>
> I believe I've identified a bug in the caching that's performed by
> {{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
> bootstrap Surefire:
>
> {noformat}
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.NoClassDefFoundError:
> org/junit/platform/launcher/core/LauncherFactory
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
>
> This is in a module that uses Surefire and JUnit Jupiter 5.5:
>
> {noformat}
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.2
>
>
>
> {noformat}
>
> Earlier in the reactor, another project is built which depends on
> {{junit-platform-launcher}}:
>
> {noformat}
>
>
> org.junit.platform
> junit-platform-launcher
> 1.5.0
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
>
[jira] [Updated] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break test bootstrapping in subsequent modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated SUREFIRE-1679:
-
Description:
I believe I've identified a bug in the caching that's performed by
{{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
bootstrap Surefire:
{noformat}
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] java.lang.NoClassDefFoundError:
org/junit/platform/launcher/core/LauncherFactory
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
This is in a module that uses Surefire and JUnit Jupiter 5.5:
{noformat}
org.junit.jupiter
junit-jupiter
5.5.0
test
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
{noformat}
Earlier in the reactor, another project is built which depends on
{{junit-platform-launcher}}:
{noformat}
org.junit.platform
junit-platform-launcher
1.5.0
org.junit.jupiter
junit-jupiter
5.5.0
test
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
{noformat}
For the problem to occur, both projects have to be built in the same reactor.
Building of the module which depends on {{junit-platform-launcher}} is causing
some pollution that results in the other module failing to build.
I believe I've tracked down the cause of this pollution to some caching that's
performed by
[AbstractSurefireMojo|https://github.com/apache/maven-surefire/blob/d96b95c4bda73c4a93506db38b9ca76b4d7b5743/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1750-L1756]:
{code:java}
testClasspathWrapper.avoidArtifactDuplicates( providerArtifacts );
Classpath providerClasspath = ClasspathCache.getCachedClassPath( providerName );
if ( providerClasspath == null )
{
providerClasspath = ClasspathCache.setCachedClasspath( providerName,
providerArtifacts );
}
{code}
The
[jira] [Updated] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break test bootstrapping in subsequent modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated SUREFIRE-1679:
-
Summary: Caching of provider classpath with module-specific changes may
break test bootstrapping in subsequent modules (was: Caching of provider
classpath with module-specific changes may break testing bootstrapping in
subsequent modules)
> Caching of provider classpath with module-specific changes may break test
> bootstrapping in subsequent modules
> -
>
> Key: SUREFIRE-1679
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Andy Wilkinson
>Priority: Major
> Attachments: surefire-pollution-problem.zip
>
>
> I believe I've identified a bug in the caching that's performed by
> {{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
> bootstrap Surefire:
>
> {noformat}
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.NoClassDefFoundError:
> org/junit/platform/launcher/core/LauncherFactory
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
>
> This is in a module that uses Surefire and JUnit Jupiter 5.5:
>
> {noformat}
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.2
>
>
>
> {noformat}
>
> Earlier in the reactor, another project is built which depends on
> {{junit-platform-launcher}}:
>
> {noformat}
>
>
> org.junit.platform
> junit-platform-launcher
> 1.5.0
>
>
> org.junit.jupiter
> junit-jupiter
> 5.5.0
> test
>
>
>
>
>
>
[jira] [Created] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break testing bootstrapping in subsequent modules
Andy Wilkinson created SUREFIRE-1679:
Summary: Caching of provider classpath with module-specific
changes may break testing bootstrapping in subsequent modules
Key: SUREFIRE-1679
URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M3, 2.22.2
Reporter: Andy Wilkinson
Attachments: surefire-pollution-problem.zip
I believe I've identified a bug in the caching that's performed by
{{AbstractSurefireMojo}}. The problem that I am seeing is a failure to
bootstrap Surefire:
{noformat}
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was
an error in the forked process
[ERROR] java.lang.NoClassDefFoundError:
org/junit/platform/launcher/core/LauncherFactory
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
This is in a module that uses Surefire and JUnit Jupiter 5.5:
{noformat}
org.junit.jupiter
junit-jupiter
5.5.0
test
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
{noformat}
Earlier in the reactor, another project is built which depends on
{{junit-platform-launcher}}:
{noformat}
org.junit.platform
junit-platform-launcher
1.5.0
org.junit.jupiter
junit-jupiter
5.5.0
test
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
{noformat}
For the problem to occur, both projects have to be built in the same reactor.
Building of the module which depends on {{junit-platform-launcher}} is causing
some pollution that results in the other module failing to build.
I believe I've tracked down the cause of this pollution to some caching that's
performed by
[jira] [Commented] (SUREFIRE-1614) JUnit Runner that writes to System.out corrupts Surefire's STDOUT when using JUnit's Vintage Engine
[
https://issues.apache.org/jira/browse/SUREFIRE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722098#comment-16722098
]
Andy Wilkinson commented on SUREFIRE-1614:
--
Thank you for fixing this in 3.0. Could you please consider a fix in the 2.x
line as well? We'd like to be able to use JUnit 5's Vintage Engine without
requiring an upgrade to a new major version of Surefire.
> JUnit Runner that writes to System.out corrupts Surefire's STDOUT when using
> JUnit's Vintage Engine
> ---
>
> Key: SUREFIRE-1614
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1614
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.1, 3.0.0-M2
>Reporter: Andy Wilkinson
>Assignee: Christian Stein
>Priority: Major
> Fix For: 3.0.0-M3
>
> Attachments: surefire-stream-corruption-bug.zip
>
>
> When JUnit Jupiter's Vintage Engine is used to run tests written using the
> JUnit 4 API, output to the console from a {{TestRunner}} results in
> Surefire's STDOUT being corrupted:
> {noformat}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file […]{noformat}
> Note that the test runner is simply calling {{System.out}}. This is to
> simulate the real world setup where the runner performs some logging that
> ultimately results in a console appender calling {{System.out}}. The same
> arrangement does not cause a problem when run using JUnit 4. An initial
> investigation suggests that the Vintage Engine calls the custom
> {{TestRunner}} earlier and, it would appear, at a time when Surefire cannot
> tolerate output to {{System.out}}.
> I have attached a minimal project that reproduces the problem. Running
> {{./mvnw -Pjunit5 test}} will reproduce the corruption. Running {{./mvnw
> -Pjunit4 test}} will not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1614) JUnit Runner that writes to System.out corrupts Surefire's STDOUT when using JUnit's Vintage Engine
Andy Wilkinson created SUREFIRE-1614:
Summary: JUnit Runner that writes to System.out corrupts
Surefire's STDOUT when using JUnit's Vintage Engine
Key: SUREFIRE-1614
URL: https://issues.apache.org/jira/browse/SUREFIRE-1614
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support
Affects Versions: 3.0.0-M2, 2.22.1
Reporter: Andy Wilkinson
Attachments: surefire-stream-corruption-bug.zip
When JUnit Jupiter's Vintage Engine is used to run tests written using the
JUnit 4 API, output to the console from a {{TestRunner}} results in Surefire's
STDOUT being corrupted:
{noformat}
[WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
1. See FAQ web page and the dump file […]{noformat}
Note that the test runner is simply calling {{System.out}}. This is to simulate
the real world setup where the runner performs some logging that ultimately
results in a console appender calling {{System.out}}. The same arrangement does
not cause a problem when run using JUnit 4. An initial investigation suggests
that the Vintage Engine calls the custom {{TestRunner}} earlier and, it would
appear, at a time when Surefire cannot tolerate output to {{System.out}}.
I have attached a minimal project that reproduces the problem. Running {{./mvnw
-Pjunit5 test}} will reproduce the corruption. Running {{./mvnw -Pjunit4 test}}
will not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-532) entries that do not redirect are ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580938#comment-16580938
]
Andy Wilkinson commented on MJAVADOC-532:
-
{quote}
For now, then, it's preventing us from upgrading to 3.0.1, which of course we
want because it supports Java 11.
{quote}
FWIW, we have successfully upgraded to 3.0.1 by deliberately using URLs that
redirect.
> entries that do not redirect are ignored
> ---
>
> Key: MJAVADOC-532
> URL: https://issues.apache.org/jira/browse/MJAVADOC-532
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Andy Wilkinson
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.2
>
>
> If the URL included in a entry does not redirect, the entry is
> ignored. This appears to happen due to a bug in
> {{JavadocUtil.getRedirectUrl}} which results in a {{NullPointerException}}
> being thrown for URLs that do not redirect.
> At the time of writing, you can reproduce the problem with the following code:
> {code:java}
> package org.apache.maven.plugins.javadoc;
> import java.io.IOException;
> import java.net.MalformedURLException;
> import java.net.URI;
> public class JavadocRedirectBug {
> public static void main(String[] args) throws MalformedURLException,
> IOException {
>
> JavadocUtil.getRedirectUrl(URI.create("https://docs.oracle.com/javase/8/docs/api/;).toURL(),
> null);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-533) entries that point to a resource that requires an Accept header may be ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575265#comment-16575265
]
Andy Wilkinson commented on MJAVADOC-533:
-
I don't really know the reasoning for Cloudflare's rule behaving the way it
does and why it treats no {{Accept}} header differently to {{Accept */*}}. It,
as you say, is the default after all. Given what {{JavadocUtil}} is doing,
accepting anything seems reasonable as it's only really interested in redirects
and will accept (and ignore) any body. It wouldn't address this issue, but
given that behaviour perhaps a {{HEAD}} request could be used to save some
bandwidth?
In case you're doing any further testing, our sysadmin's in the process of
tweaking the configuration so you may soon get a 200 back from docs.spring.io
even without the {{Accept}} header.
> entries that point to a resource that requires an Accept header may be
> ignored
> -
>
> Key: MJAVADOC-533
> URL: https://issues.apache.org/jira/browse/MJAVADOC-533
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Andy Wilkinson
>Priority: Minor
>
> This is a regression caused by the changes made to fix MJAVADOC-427.
> The HTTP client configuration that's used to get the redirect URLs does not
> include an {{Accept}} header in the requests that it makes. This can result
> in a 403 response for some javadoc, such as Spring Framework's which is
> fronted by Cloudflare. The lack of {{Accept}} header will sometimes cause
> Cloudflare to respond with a 403 containing a Captcha.
> I'm a member of the Spring Framework team and have asked our sysadmin to look
> at tweaking Cloudflare's rules, but I thought it worth reporting the problem
> here as others may be affected and may not be in a position to change the
> server's configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-533) entries that point to a resource that requires an Accept header may be ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575265#comment-16575265
]
Andy Wilkinson edited comment on MJAVADOC-533 at 8/9/18 6:41 PM:
-
I don't really know the reasoning for Cloudflare's rule behaving the way it
does and why it treats no {{Accept}} header differently to {{Accept \*/\*}}.
It, as you say, is the default after all. Given what {{JavadocUtil}} is doing,
accepting anything seems reasonable as it's only really interested in redirects
and will accept (and ignore) any body. It wouldn't address this issue, but
given that behaviour perhaps a {{HEAD}} request could be used to save some
bandwidth?
In case you're doing any further testing, our sysadmin's in the process of
tweaking the configuration so you may soon get a 200 back from docs.spring.io
even without the {{Accept}} header.
was (Author: awilkinson):
I don't really know the reasoning for Cloudflare's rule behaving the way it
does and why it treats no {{Accept}} header differently to {{Accept */*}}. It,
as you say, is the default after all. Given what {{JavadocUtil}} is doing,
accepting anything seems reasonable as it's only really interested in redirects
and will accept (and ignore) any body. It wouldn't address this issue, but
given that behaviour perhaps a {{HEAD}} request could be used to save some
bandwidth?
In case you're doing any further testing, our sysadmin's in the process of
tweaking the configuration so you may soon get a 200 back from docs.spring.io
even without the {{Accept}} header.
> entries that point to a resource that requires an Accept header may be
> ignored
> -
>
> Key: MJAVADOC-533
> URL: https://issues.apache.org/jira/browse/MJAVADOC-533
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Andy Wilkinson
>Priority: Minor
>
> This is a regression caused by the changes made to fix MJAVADOC-427.
> The HTTP client configuration that's used to get the redirect URLs does not
> include an {{Accept}} header in the requests that it makes. This can result
> in a 403 response for some javadoc, such as Spring Framework's which is
> fronted by Cloudflare. The lack of {{Accept}} header will sometimes cause
> Cloudflare to respond with a 403 containing a Captcha.
> I'm a member of the Spring Framework team and have asked our sysadmin to look
> at tweaking Cloudflare's rules, but I thought it worth reporting the problem
> here as others may be affected and may not be in a position to change the
> server's configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-533) entries that point to a resource that requires an Accept header may be ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575252#comment-16575252
]
Andy Wilkinson commented on MJAVADOC-533:
-
The Cloudflare rule that's triggered and results in a Captcha challenge is
named {{IE6 detection [Type B]}}. It seems to require both a missing {{Accept}}
header and the {{User-Agent: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.0)"}} header.
> entries that point to a resource that requires an Accept header may be
> ignored
> -
>
> Key: MJAVADOC-533
> URL: https://issues.apache.org/jira/browse/MJAVADOC-533
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Andy Wilkinson
>Priority: Minor
>
> This is a regression caused by the changes made to fix MJAVADOC-427.
> The HTTP client configuration that's used to get the redirect URLs does not
> include an {{Accept}} header in the requests that it makes. This can result
> in a 403 response for some javadoc, such as Spring Framework's which is
> fronted by Cloudflare. The lack of {{Accept}} header will sometimes cause
> Cloudflare to respond with a 403 containing a Captcha.
> I'm a member of the Spring Framework team and have asked our sysadmin to look
> at tweaking Cloudflare's rules, but I thought it worth reporting the problem
> here as others may be affected and may not be in a position to change the
> server's configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-533) entries that point to a resource that requires an Accept header may be ignored
Andy Wilkinson created MJAVADOC-533:
---
Summary: entries that point to a resource that requires an
Accept header may be ignored
Key: MJAVADOC-533
URL: https://issues.apache.org/jira/browse/MJAVADOC-533
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Andy Wilkinson
This is a regression caused by the changes made to fix MJAVADOC-427.
The HTTP client configuration that's used to get the redirect URLs does not
include an {{Accept}} header in the requests that it makes. This can result in
a 403 response for some javadoc, such as Spring Framework's which is fronted by
Cloudflare. The lack of {{Accept}} header will sometimes cause Cloudflare to
respond with a 403 containing a Captcha.
I'm a member of the Spring Framework team and have asked our sysadmin to look
at tweaking Cloudflare's rules, but I thought it worth reporting the problem
here as others may be affected and may not be in a position to change the
server's configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-532) entries that do not redirect are ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575074#comment-16575074
]
Andy Wilkinson commented on MJAVADOC-532:
-
A workaround is to use a URL that redirects. The example above can be "fixed"
by removing the trailing {{/}} and using
{{https://docs.oracle.com/javase/8/docs/api}} instead.
> entries that do not redirect are ignored
> ---
>
> Key: MJAVADOC-532
> URL: https://issues.apache.org/jira/browse/MJAVADOC-532
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Andy Wilkinson
>Priority: Major
>
> If the URL included in a entry does not redirect, the entry is
> ignored. This appears to happen due to a bug in
> {{JavadocUtil.getRedirectUrl}} which results in a {{NullPointerException}}
> being thrown for URLs that do not redirect.
> At the time of writing, you can reproduce the problem with the following code:
> {code:java}
> package org.apache.maven.plugins.javadoc;
> import java.io.IOException;
> import java.net.MalformedURLException;
> import java.net.URI;
> public class JavadocRedirectBug {
> public static void main(String[] args) throws MalformedURLException,
> IOException {
>
> JavadocUtil.getRedirectUrl(URI.create("https://docs.oracle.com/javase/8/docs/api/;).toURL(),
> null);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-532) entries that do not redirect are ignored
Andy Wilkinson created MJAVADOC-532:
---
Summary: entries that do not redirect are ignored
Key: MJAVADOC-532
URL: https://issues.apache.org/jira/browse/MJAVADOC-532
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Andy Wilkinson
If the URL included in a entry does not redirect, the entry is ignored.
This appears to happen due to a bug in {{JavadocUtil.getRedirectUrl}} which
results in a {{NullPointerException}} being thrown for URLs that do not
redirect.
At the time of writing, you can reproduce the problem with the following code:
{code:java}
package org.apache.maven.plugins.javadoc;
import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URI;
public class JavadocRedirectBug {
public static void main(String[] args) throws MalformedURLException,
IOException {
JavadocUtil.getRedirectUrl(URI.create("https://docs.oracle.com/javase/8/docs/api/;).toURL(),
null);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6306) Replace use of Guava in maven-resolver-provider with a lighter weight alternative
Andy Wilkinson created MNG-6306: --- Summary: Replace use of Guava in maven-resolver-provider with a lighter weight alternative Key: MNG-6306 URL: https://issues.apache.org/jira/browse/MNG-6306 Project: Maven Issue Type: Improvement Affects Versions: 3.5.2 Reporter: Andy Wilkinson Spring Boot's CLI currently embeds Aether and uses Maven's Aether Provider 3.2.1. We'd [like to switch to Maven Resolver and Maven Resolver Provider|https://github.com/spring-projects/spring-boot/issues/7627] but the use of Guava adds 2.4MB to a < 10MB binary. We'd like to avoid that 25% increase if we can. Given that Aether and Maven Resolver are intended to be embedded, would it be possible to remove the use of Guava from Maven Resolver Provider? Its use appears to have been added in [this commit|https://github.com/apache/maven/commit/61c374042560b2dc21c294886615931a888df597#diff-b275596b2058bcd469e4c45288cef7b4]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180538#comment-16180538
]
Andy Wilkinson commented on SUREFIRE-1424:
--
A workaround is to explicitly add the {{java.base}} module which stops the
unwanted {{java.se.ee}} module from being added:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.20.1
--add-modules java.base
{code}
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180527#comment-16180527
]
Andy Wilkinson commented on SUREFIRE-1424:
--
This appears to be a regression in 2.20.1. The sample linked above works with
Surefire 2.20 but fails with 2.20.1. With 2.20.1, the JVM is launched with
{{--add-modules java.se.ee}} but with 2.20 it is not. Adding the {{java.se.ee}}
module breaks JTA as only some of its classes at in the module. This split
package leads to the {{NoClassDefFoundError}} reported above. This would appear
to be an unanticipated side-effect of SUREFIRE-1403.
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180527#comment-16180527
]
Andy Wilkinson edited comment on SUREFIRE-1424 at 9/26/17 9:24 AM:
---
This appears to be a regression in 2.20.1. The sample linked above works with
Surefire 2.20 but fails with 2.20.1. With 2.20.1, the JVM is launched with
{{--add-modules java.se.ee}} but with 2.20 it is not. Adding the {{java.se.ee}}
module breaks JTA as only some of its classes are in that module. This split
package leads to the {{NoClassDefFoundError}} reported above. This would appear
to be an unanticipated side-effect of SUREFIRE-1403.
was (Author: awilkinson):
This appears to be a regression in 2.20.1. The sample linked above works with
Surefire 2.20 but fails with 2.20.1. With 2.20.1, the JVM is launched with
{{--add-modules java.se.ee}} but with 2.20 it is not. Adding the {{java.se.ee}}
module breaks JTA as only some of its classes at in the module. This split
package leads to the {{NoClassDefFoundError}} reported above. This would appear
to be an unanticipated side-effect of SUREFIRE-1403.
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158998#comment-15158998
]
Andy Wilkinson commented on MNG-5971:
-
AFAIK, the warnings would not appear if the dependency management had been
declared directly so I'm surprised that they appear if that dependency
management has come via the import of a bom. In their current form, I think the
warnings are a hinderance rather than a help as they actively discourage people
from separating their dependency management out into a reusable bom.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152382#comment-15152382
]
Andy Wilkinson edited comment on MNG-5971 at 2/18/16 2:41 PM:
--
{quote}
For the include scope it will not be possible to use anything requiring
inheritance processing. Properties would be available only after inheritance
processing has been performed.
{quote}
Is that due to a technical restriction or a design choice that's been made? If
I can use a property when defining a managed dependency directly, why can't I
also use a property when I'm using the new {{include}} scope? Put another way,
once property interpolation is available can't the model be processed such that
any {{include}}-scoped dependency is replaced with the content of the bom that
it references?
was (Author: awilkinson):
> For the include scope it will not be possible to use anything requiring
> inheritance processing. Properties would be available only after inheritance
> processing has been performed.
Is that due to a technical restriction or a design choice that's been made? If
I can use a property when defining a managed dependency directly, why can't I
also use a property when I'm using the new {{include}} scope? Put another way,
once property interpolation is available can't the model be processed such that
any {{include}}-scoped dependency is replaced with the content of the bom that
it references?
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152382#comment-15152382
]
Andy Wilkinson commented on MNG-5971:
-
> For the include scope it will not be possible to use anything requiring
> inheritance processing. Properties would be available only after inheritance
> processing has been performed.
Is that due to a technical restriction or a design choice that's been made? If
I can use a property when defining a managed dependency directly, why can't I
also use a property when I'm using the new {{include}} scope? Put another way,
once property interpolation is available can't the model be processed such that
any {{include}}-scoped dependency is replaced with the content of the bom that
it references?
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152297#comment-15152297
]
Andy Wilkinson commented on MNG-5971:
-
{quote}
Since that scope would be processed very early (before inheritance and
interpolation), you cannot use any features like property expansion.
{quote}
Given that I can do this:
{noformat}
com.example.foo
alpha
${foo.version}
com.example.foo
bravo
${foo.version}
{noformat}
I'd really like to be able to move that dependency management out into a
reusable bom and do this:
{noformat}
com.example.foo
foo-bom
${foo.version}
include
pom
{noformat}
If the accepted goal for {{include}} is to provide a shorthand for declaring
the managed dependencies directly, I'd expect that the same rules for the use
of properties would apply. Is that not possible?
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
Andy Wilkinson created MNG-5737:
---
Summary: Adding a test dependency can move dependencies from the
compile scope to the test scope
Key: MNG-5737
URL: https://jira.codehaus.org/browse/MNG-5737
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.3
Reporter: Andy Wilkinson
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of the
hierarchy wins and, for a number of the Jetty dependencies, the shortest route
is via the test-scoped {{org.apache.solr:sole-core}}. I can understand a
test-scoped dependency being upgraded to the compile scope when a dependency is
added, but downgrading a dependency from the compile scope to the test scope
feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on the
transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MNG-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated MNG-5737:
Description:
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of the
hierarchy wins and, for a number of the Jetty dependencies, the shortest route
is via the test-scoped {{org.apache.solr:sole-core}}. I can understand a
test-scoped dependency being upgraded to the compile scope when a dependency is
added, but downgrading a dependency from the compile scope to the test scope
feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on the
transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
was:
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+-
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated MDEP-475:
Attachment: test-scope-problem.zip
I think it's more than a presentation problem. The attached project will fail
to compile due to the `org.eclipse.jetty.server` package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml, test-scope-problem.zip
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359251#comment-359251
]
Andy Wilkinson edited comment on MDEP-475 at 12/17/14 1:23 PM:
---
I think it's more than a presentation problem. The attached project will fail
to compile due to the {{org.eclipse.jetty.server}} package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
was (Author: wilkinsona):
I think it's more than a presentation problem. The attached project will fail
to compile due to the `org.eclipse.jetty.server` package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml, test-scope-problem.zip
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
