[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291445#comment-17291445
]
Herve Boutemy commented on MNG-7052:
MNG-7107 created with a PR to differentiate profile id from coordinate id and
relax profile id validation to just "avoid start with + or -"
after that, coordinate ids could be checked to avoid starting with "." because
that would be a bad trick on Unix: I did not have any other idea of reasonable
additional validation rule for coordinate nor profile ids
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] hboutemy opened a new pull request #451: [MNG-7107] relax profile id validation, different from coordinate id
hboutemy opened a new pull request #451: URL: https://github.com/apache/maven/pull/451 see https://issues.apache.org/jira/browse/MNG-7107 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7107) relax recently introduced profile id validation
Herve Boutemy created MNG-7107: -- Summary: relax recently introduced profile id validation Key: MNG-7107 URL: https://issues.apache.org/jira/browse/MNG-7107 Project: Maven Issue Type: Bug Components: POM Affects Versions: 4.0.0-alpha-1 Reporter: Herve Boutemy Fix For: 4.0.0-alpha-1 profile id validation was introduced as a side effect of MNG-7051, with the same rules as groupId and artifactId this is causing issues, with existing projects using "jdk9+" profile ids: there is no reason to fail on such profile ids let's differentiate coordinate ids validation from profile ids -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #95: Bump guice from 4.1.0 to 5.0.0
dependabot[bot] opened a new pull request #95: URL: https://github.com/apache/maven-indexer/pull/95 Bumps [guice](https://github.com/google/guice) from 4.1.0 to 5.0.0. Release notes Sourced from https://github.com/google/guice/releases";>guice's releases. Guice 5.0.0-BETA-1 Latest beta release of Guice and Guice extensions. Guice 4.2.3. See the https://github.com/google/guice/wiki/Guice423";>release notes for details. Guice 4.2.2. See the https://github.com/google/guice/wiki/Guice422";>release notes for details. Guice 4.2.1. See the https://github.com/google/guice/wiki/Guice421";>release notes for details. Guice 4.2. See the https://github.com/google/guice/wiki/Guice42";>release notes for details. Commits https://github.com/google/guice/commit/533690c69805b25f2433ce358d99c13de7479561";>533690c specify release version numbers https://github.com/google/guice/commit/420400684c81b8c36b09cfc00d00182bfcebd4a1";>4204006 Upgrad guava to latest release 30.1-jre. https://github.com/google/guice/commit/4a66eb4deca051c9a0724a0368a5ebaec36f53f3";>4a66eb4 Upgrade asm from 9.0 to version 9.1 https://github.com/google/guice/commit/6fa83e476a4e8ecc80fac3b361cf8fc3643292a0";>6fa83e4 Add missing https://github.com/since";>@since methods https://github.com/google/guice/commit/96e835f0985ef06bd70a24c77be331c61acd1baa";>96e835f Update https://github.com/since";>@since tags https://github.com/google/guice/commit/bfc2e48f4a008462ff74e0e73bc7e1cabc04e30d";>bfc2e48 If all reasonable sources are filtered via skipSource, then show the source a... https://github.com/google/guice/commit/df622abf7ceb0984026fabfbcb04d2e6b05f370b";>df622ab Fixing javadoc, map bindings were actually implemented some time ago https://github.com/google/guice/commit/826a97fced733fe8ea60de4ed0837a6f50ed406e";>826a97f Update the description for Key class. https://github.com/google/guice/commit/015ed75b5c4a5b04d1adc36ad836cbf8df57cd35";>015ed75 Restore the default method log message to WARNING level. https://github.com/google/guice/commit/f78f7cfb3b7cb336e8bc8ad7fe421b24805720e9";>f78f7cf Temporarily down grade the warning to INFO level. Additional commits viewable in https://github.com/google/guice/compare/4.1...5.0.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #94: Bump guice-assistedinject from 4.1.0 to 5.0.0
dependabot[bot] opened a new pull request #94: URL: https://github.com/apache/maven-indexer/pull/94 Bumps guice-assistedinject from 4.1.0 to 5.0.0. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1888) Maven Surefire Exception error
[
https://issues.apache.org/jira/browse/SUREFIRE-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291204#comment-17291204
]
Sid edited comment on SUREFIRE-1888 at 2/25/21, 8:42 PM:
-
Hoping for some resolution regarding the error.
*POM Details*
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M2
true
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
org.aspectj
aspectjweaver
${aspectj.version}
was (Author: sid180):
Hoping for some resolution regarding the error.
!image-2021-02-25-15-40-36-242.png!
> Maven Surefire Exception error
> --
>
> Key: SUREFIRE-1888
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1888
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M2
> Environment: QA environment
>Reporter: Sid
>Priority: Blocker
> Attachments: image-2021-02-25-15-40-36-242.png
>
>
> Builds are getting failed in Jenkins.
> Boot Manifest-JAR contains absolute paths in classpath
> D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesBoot
> Manifest-JAR contains absolute paths in classpath
> D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesjava.lang.IllegalArgumentException:
> 'other' has different root at
> sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at
> sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at
> org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151)
> at
> org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:168)
> at
> org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:122)
> at
> org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:77)
> at
> org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:147)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:580)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> # Created at 2021-02-25T14:05:43.884Boot Manifest-JAR contains absolute paths
> in classpath
> D:\Jenki
[jira] [Comment Edited] (SUREFIRE-1888) Maven Surefire Exception error
[ https://issues.apache.org/jira/browse/SUREFIRE-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291204#comment-17291204 ] Sid edited comment on SUREFIRE-1888 at 2/25/21, 8:40 PM: - Hoping for some resolution regarding the error. !image-2021-02-25-15-40-36-242.png! was (Author: sid180): Hoping for some resolution regarding the error. > Maven Surefire Exception error > -- > > Key: SUREFIRE-1888 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1888 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M2 > Environment: QA environment >Reporter: Sid >Priority: Blocker > Attachments: image-2021-02-25-15-40-36-242.png > > > Builds are getting failed in Jenkins. > Boot Manifest-JAR contains absolute paths in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesBoot > Manifest-JAR contains absolute paths in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesjava.lang.IllegalArgumentException: > 'other' has different root at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:168) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:122) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:77) > at > org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:147) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:580) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at > org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at > org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at > org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > # Created at 2021-02-25T14:05:43.884Boot Manifest-JAR contains absolute paths > in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\classesjava.lang.IllegalArgumentException: > 'other' has different root at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at > org
[jira] [Commented] (SUREFIRE-1888) Maven Surefire Exception error
[ https://issues.apache.org/jira/browse/SUREFIRE-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291204#comment-17291204 ] Sid commented on SUREFIRE-1888: --- Hoping for some resolution regarding the error. > Maven Surefire Exception error > -- > > Key: SUREFIRE-1888 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1888 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M2 > Environment: QA environment >Reporter: Sid >Priority: Blocker > > Builds are getting failed in Jenkins. > Boot Manifest-JAR contains absolute paths in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesBoot > Manifest-JAR contains absolute paths in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesjava.lang.IllegalArgumentException: > 'other' has different root at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:168) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:122) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:77) > at > org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:147) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:580) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at > org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at > org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at > org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > # Created at 2021-02-25T14:05:43.884Boot Manifest-JAR contains absolute paths > in classpath > D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\classesjava.lang.IllegalArgumentException: > 'other' has different root at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at > sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151) > at > org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathEl
[jira] [Created] (SUREFIRE-1888) Maven Surefire Exception error
Sid created SUREFIRE-1888: - Summary: Maven Surefire Exception error Key: SUREFIRE-1888 URL: https://issues.apache.org/jira/browse/SUREFIRE-1888 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 3.0.0-M2 Environment: QA environment Reporter: Sid Builds are getting failed in Jenkins. Boot Manifest-JAR contains absolute paths in classpath D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesBoot Manifest-JAR contains absolute paths in classpath D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\test-classesjava.lang.IllegalArgumentException: 'other' has different root at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:168) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:122) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:77) at org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:147) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:580) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) # Created at 2021-02-25T14:05:43.884Boot Manifest-JAR contains absolute paths in classpath D:\Jenkins\workspace\SelenideAutomationNodeStandalone\SelenideTest\target\classesjava.lang.IllegalArgumentException: 'other' has different root at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392) at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize(JarManifestForkConfiguration.java:151) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:168) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:122) at org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:77) at org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration
[jira] [Created] (DOXIA-619) Sink.sectionTitle1() creates instead of
Bertrand Martin created DOXIA-619:
-
Summary: Sink.sectionTitle1() creates instead of
Key: DOXIA-619
URL: https://issues.apache.org/jira/browse/DOXIA-619
Project: Maven Doxia
Issue Type: Bug
Components: Module - Xhtml, Sink API
Reporter: Bertrand Martin
h1. Problem
The below code in a Maven Report plugin:
{code:java}
Sink mainSink = getSink();
mainSink.section1();
mainSink.sectionTitle1();
mainSink.text("Release Notes");
mainSink.sectionTitle1_();
{code}
produces this HTML:
{code:html}
Release Notes
{code}
Expected HTML was {{}} instead of {{}}:
{code:html}
Release Notes
{code}
As a consequence, documents produced using the *Sink* API in a Maven Report
plugin do not have any {{}} headings and start directly with {{}},
which is not recommended for SEO, and most importantly [for
accessibility|https://www.w3.org/WAI/tutorials/page-structure/headings/].
h1. Specification
Fix the mapping of section levels to HTML heading levels in _Xhtml5BaseSink_
and _XhtmlBaseSink_ (see {{protected void onSectionTitle( int depth,
SinkEventAttributes attributes )}}).
Similarly (and this is riskier), update _baseStartTag()_ and _baseEndTag()_
methods in _Xhtml5BaseParser_ and _XhtmlBaseParser_ classes.
h1. Doc
N/A
h1. Tests
Add corresponding unit and integration tests. This should not break
*maven-site-plugin*'s own integration tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MJAVADOC-673) Generating wrong commandline option for javadoc tool when using Java9+ modules
Kai Hofmann created MJAVADOC-673:
Summary: Generating wrong commandline option for javadoc tool when
using Java9+ modules
Key: MJAVADOC-673
URL: https://issues.apache.org/jira/browse/MJAVADOC-673
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.2.0
Environment: MacOS, Window, Linux, Java 11.0.10 +
With older java versions like 11.0.3 you will got more errors!
Reporter: Kai Hofmann
When you checkout my open source
[TemplateEnginel|https://github.com/PowerStat/TemplateEngine] and simply run
{code:java}
mvn javadoc:javadoc
{code}
you will get the following error message:
{noformat}
[INFO] <<< maven-javadoc-plugin:3.2.0:javadoc (default-cli) < generate-sources
@ templateengine <<<
[INFO]
[INFO]
[INFO] --- maven-javadoc-plugin:3.2.0:javadoc (default-cli) @ templateengine ---
[INFO] No previous run data found, generating javadoc.
[INFO]
Loading source file
D:\work\eclipse\java\github\TemplateEngine\src\main\java\module-info.java...
1 error
[ERROR] Error while creating javadoc report:
Exit code: 1 - error: module not found: de.powerstat.phplib.templateengine
Command line was: cmd.exe /X /C "D:\Programme\Java\jdk-11.0.10\bin\javadoc.exe
@options @packages @argfile"
Refer to the generated Javadoc files in
'D:\work\eclipse\java\github\TemplateEngine\target\site\apidocs' dir.
org.apache.maven.reporting.MavenReportException:
Exit code: 1 - error: module not found: de.powerstat.phplib.templateengine
Commandline was: cmd.exe /X /C "D:\Programme\Java\jdk-11.0.10\bin\javadoc.exe
@options @packages @argfile"Refer to the generated Javadoc files in
'D:\work\eclipse\java\github\TemplateEngine\target\site\apidocs' dir.
[...]{noformat}
Now go to *target/site/apidocs*
There you could run the generated script by *javadoc.bat*|*sh*
Which results in the same error!
Please note that the subdirectory *src/de.powerstat.phplib.templateengine* is
empty.
Now open the *options* file
and remove the following lines:
{code:java}
--module-source-path
'D:/work/eclipse/java/github/TemplateEngine/target/site/apidocs/src'
{code}
Run the *javadoc.bat*|*sh* again.
Now the error
{noformat}
error: module not found: de.powerstat.phplib.templateengine{noformat}
is gone. And the javadocs are generated as expected!
So for me it looks like the generated --module-source-path option for the
javadoc command is wrong in this (and maybe other) context(s)!
The generation happens in org.apache.maven.plugins.javadoc.AbstractJavadocMojo
around line 5316.
Because of the complexity of this code and it's context (maven Reactor) I am
not able to provide a patch for this.
But hopefully you could fix this fast, because it is a real blocker that makes
maven javadoc generation for java 9+ modules imposible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7106) VersionRange produces a version range that is incompatible with itself
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290931#comment-17290931
]
Brandon Heck commented on MNG-7106:
---
Would the preference be to fix this in parseRestriction by skipping the
creation of a Restriction for a hard version requirement? Would it be
preferable to fix this in the {{toString}} by checking the bounds for equality
when constructing the string? Is there another way this might be fixed that
would be better than either of those suggestions? I'm assuming that the first
suggestion may have unintended consequences when building the effective model.
> VersionRange produces a version range that is incompatible with itself
> --
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Priority: Minor
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] mpkorstanje commented on pull request #338: Upgrade Cucumber versions
mpkorstanje commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785850017 You're welcome. Ping me if you run into more Cucumber related problems. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #338: Upgrade Cucumber versions
Tibor17 commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785846543 @mpkorstanje Thx for helping us with the fix. I used your changes in #337, we will fix more integration tests, additionally Mockito needs to be upgraded as well. We have one problem [java 16] with Java compiler under Java 16 which will be fixed in Java 17 and so it looks like that one IT class will skip the Java 16. Then the build would be in good conditions again. [java 16]: https://bugs.openjdk.java.net/browse/JDK-8258246 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje edited a comment on pull request #338: Upgrade Cucumber versions
mpkorstanje edited a comment on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785842409 Okay, I think I worked it out. With Cucumber v1 there are 8 tests because there are 2 feature files with 1 scenario + 3 steps each in the scenario and each scenario and step is reported as an individual test. So 2 * ( 1 + 3 ) = 8. Then as the comment said, "with parallel=classes, we get 9 tests in total, as the dummy "scenario" test entry is reported twice: once as success, and once with the failure from the failing test step". So I'm glad I fixed this in v2. :smile: This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje commented on pull request #338: Upgrade Cucumber versions
mpkorstanje commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785843071 > Thx I have fixed this in #337 I'll close this MR then. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje closed pull request #338: Upgrade Cucumber versions
mpkorstanje closed pull request #338: URL: https://github.com/apache/maven-surefire/pull/338 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje edited a comment on pull request #338: Upgrade Cucumber versions
mpkorstanje edited a comment on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785842409 Okay, I think I worked it out. With Cucumber v1 there are 8 tests because there are 2 feature files with 1 scenario + 3 steps each in the scenario and each scenario and step is reported as an individual test. So 2 * ( 1 + 3 ) = 8. Then as the comment said, "with parallel=classes, we get 9 tests in total, as the dummy "scenario" test entry is reported twice: once as success, and once with the failure from the failing test step" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje commented on pull request #338: Upgrade Cucumber versions
mpkorstanje commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785842409 Okay, I think I worked it out. With Cucumber v1 there are 8 tests because there are 2 feature files with 1 scenario + 3 steps in the scenario and each scenario and step is reported as an individual test. So 2 * ( 1 + 3 ) = 8. Then as the comment said, "with parallel=classes, we get 9 tests in total, as the dummy "scenario" test entry is reported twice: once as success, and once with the failure from the failing test step" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje commented on pull request #338: Upgrade Cucumber versions
mpkorstanje commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785831716 Cucumber executes feature files written in Gherkin. A feature file is a set of test cases (scenarios) written in plain human readable language. These are not naturally executable so for each step in the feature file there must be a matching step definition in Java. These are defined in the `StepDefs` class. So a suite consists of feature files + step definitions. The class annotated with `@RunWith( Cucumber.class )` (optionally in combination with `@CucumberOptions`) defines which feature files and step definitions are included in the suite and executes the suite. So the `junit47-cucumber` test case consists of 2 suites, each containing 1 feature file with 1 scenario each. And 1 step definition class with 4 step definitions in total. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #338: Upgrade Cucumber versions
Tibor17 edited a comment on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785821060 > > Should we put `@RunWith( Cucumber.class )` on the top of the class StepDefs? > > No. That should not be necessary. What makes you think so? We have three classes, see [link], but `StepDefs.java` is not supposed to be a test. What's the purpose of the class `StepDefs.java`? If we made it a test, the total could be 3, am I right? [link]: https://github.com/apache/maven-surefire/tree/f58673bd37a98f53516faa54155e427aadcbed29/surefire-its/src/test/resources/junit47-cucumber/src/test/java/org/sample/cucumber This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #338: Upgrade Cucumber versions
Tibor17 commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785821060 > > Should we put `@RunWith( Cucumber.class )` on the top of the class StepDefs? > > No. That should not be necessary. What makes you think so? We have three classes, see [1], but `StepDefs.java` is not supposed to be a test. What's the purpose of the class `StepDefs.java`? If we made it a test, the total could be 3, am I right? [1]: https://github.com/apache/maven-surefire/tree/f58673bd37a98f53516faa54155e427aadcbed29/surefire-its/src/test/resources/junit47-cucumber/src/test/java/org/sample/cucumber This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje edited a comment on pull request #338: Upgrade Cucumber versions
mpkorstanje edited a comment on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785801829 > What total should be right in this case? That's expected. Cucumber v1 used to report individual steps as testcases, this didn't line up with the semantics in maven/junit and now reports scenarios/examples as test cases. Though I'm quite puzzled how this resulted in a total of 8/9. > Should we put `@RunWith( Cucumber.class )` on the top of the class StepDefs? No. That should not be necessary. What makes you think so? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] mpkorstanje commented on pull request #338: Upgrade Cucumber versions
mpkorstanje commented on pull request #338: URL: https://github.com/apache/maven-surefire/pull/338#issuecomment-785801829 > What total should be right in this case? That's expected. Cucumber v1 used to report individual steps as testcases, this didn't line up with the semantics in maven/junit and now reports scenarios/examples as test cases. Though I'm quite puzzled how this resulted in a total of 8/9. > Should we put @RunWith( Cucumber.class ) on the top of the class StepDefs? No. That should not be necessary. What makes you think so? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7052:
-
Labels: (was: up-for-grabs)
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290826#comment-17290826
]
Maarten Mulders commented on MNG-7052:
--
bq. and definitely not an "up-for-grabs" issue
As long as we don't have an agreement on how to validate identifiers, I agree.
I'll remove the label for now. If we have an agreement, the implementation
would be up-for-grabs again.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290797#comment-17290797
]
Michael Osipov edited comment on MNG-7052 at 2/25/21, 9:28 AM:
---
[~hboutemy], I do agree. See my previous proposals to approach this issue. The
{{validateId()}} must be renamed to {{validateCoordinateId()}} for starters.
The we need to agree on chars for profile ids *without* the
activation/deactivation chars to avoid confusion. This also means that no
profile id may start with these chars.
was (Author: michael-o):
[~hboutemy], I do agree. See my previous proposals to approach this issue. The
{{validateId()}} must be renamed to {{validateCoordinateId()}} for starters.
The we need to agree on chars for profile ids *without* the
activation/deactivation chars to avoid confusing. This also means that no
profile id may start with these chars.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290797#comment-17290797
]
Michael Osipov commented on MNG-7052:
-
[~hboutemy], I do agree. See my previous proposals to approach this issue. The
{{validateId()}} must be renamed to {{validateCoordinateId()}} for starters.
The we need to agree on chars for profile ids *without* the
activation/deactivation chars to avoid confusing. This also means that no
profile id may start with these chars.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290788#comment-17290788
]
Herve Boutemy commented on MNG-7052:
and definitely not an "up-for-grabs" issue: I know that adding controls is easy
to code, but what is not so easy is to envision the impact
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290786#comment-17290786
]
Herve Boutemy edited comment on MNG-7052 at 2/25/21, 8:54 AM:
--
just checked the "etc..." in
bq. used to validate artifactid, groupid, etc...
it seems validateId was created to validate only groupId and artifactId
and just reused as is in MNG-7051 to also validate profile id
I propose:
1. to validate profile ids in a separate method, that will only check + and -
as first characters (which is the only really invalid case)
2. add in validateId javadoc the fact that it is for groupId and artifactId, or
even rename the method to be more specific
3. to update this issue to not talk about "ids" in general but groupId and
artifactId, and then discuss on concrete benefit and impact of changing
was (Author: hboutemy):
just checked the "etc..." in
bq. used to validate artifactid, groupid, etc...
it seems validateId was created to validate only groupId and artifactId
and just reused as is in MNG-7051 to also validate profile id
I propose:
1. to validate profile ids in a separate method, that will only check + and -
as first characters (which is the only really invalid case)
2. to update this issue to not talk about "ids" in general but groupId and
artifactId, and then discuss on concrete benefit and impact of changing
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290786#comment-17290786
]
Herve Boutemy commented on MNG-7052:
just checked the "etc..." in
bq. used to validate artifactid, groupid, etc...
it seems validateId was created to validate only groupId and artifactId
and just reused as is in MNG-7051 to also validate profile id
I propose:
1. to validate profile ids in a separate method, that will only check + and -
as first characters (which is the only really invalid case)
2. to update this issue to not talk about "ids" in general but groupId and
artifactId, and then discuss on concrete benefit and impact of changing
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290776#comment-17290776
]
Herve Boutemy edited comment on MNG-7052 at 2/25/21, 8:49 AM:
--
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051, which they were not
checked before
2. an idea to make existing checks against ids more strict: I don't know if
there are concrete cases of people doing dumb choices, and I don't know which
ids it covers = what has to be defined first (= currently what calls
"validateId(" in
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
, but maybe someone will want to check more than what is currently checked,
when I see ides about checking Modello id)
was (Author: hboutemy):
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051, which they were not
checked before
2. an idea to make existing checks against ids more strict: I don't know if
there are concrete cases of people doing dumb choices, and I don't know which
ids it covers = what has to be defined first (= currently what calls
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
, but maybe someone will want to check more thatn what is currently checked,
when I see ides about checking Modello id)
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290776#comment-17290776
]
Herve Boutemy edited comment on MNG-7052 at 2/25/21, 8:48 AM:
--
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051, which they were not
checked before
2. an idea to make existing checks against ids more strict: I don't know if
there are concrete cases of people doing dumb choices, and I don't know which
ids it covers = what has to be defined first (= currently what calls
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
, but maybe someone will want to check more thatn what is currently checked,
when I see ides about checking Modello id)
was (Author: hboutemy):
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051, which they were not
checked before
2. an idea to make existing checks against ids more strict: I don't know if
there are concrete cases of people doing dumb choices, and I don't know which
ids it covers = what has to be defined first
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290776#comment-17290776
]
Herve Boutemy edited comment on MNG-7052 at 2/25/21, 8:45 AM:
--
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051, which they were not
checked before
2. an idea to make existing checks against ids more strict: I don't know if
there are concrete cases of people doing dumb choices, and I don't know which
ids it covers = what has to be defined first
was (Author: hboutemy):
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051
2. an idea (which I don't know if it is good or not) to make checks against ids
more strict: I don't know if there are concrete cases of people doing dumb
choices
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290776#comment-17290776
]
Herve Boutemy edited comment on MNG-7052 at 2/25/21, 8:44 AM:
--
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
I really think we are conflating 2 completely separate issues:
1. issue created by checking profile id in MNG-7051
2. an idea (which I don't know if it is good or not) to make checks against ids
more strict: I don't know if there are concrete cases of people doing dumb
choices
was (Author: hboutemy):
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290776#comment-17290776
]
Herve Boutemy commented on MNG-7052:
jumping in because I was hit by MNG-7051 changing rules *for profile ids*,
reusing the same "validateId" method that existed before
I think that profile ids are another beast than other ids (which are used to
validate artifactid, groupid, etc...)
profile ids should be checked against invalid first character like + and -,
then let them quite free
and for other ids, if we want to change the checks, we should list what is
checked precisely, and define the benefit of breaking things now, after near 20
years of artifactids, groupids, and I don't know where we currently check with
"validateId"
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290774#comment-17290774
]
Herve Boutemy commented on MNG-7051:
ok, thank you, I'll followup in MNG-7052
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290765#comment-17290765
]
Maarten Mulders commented on MNG-7051:
--
[~hboutemy], I think [~tibordigana] raised the same concern in MNG-7052, as the
same happens [in Surefire|https://github.com/apache/maven-surefire/pull/334].
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290758#comment-17290758
]
Herve Boutemy commented on MNG-7051:
I just found an unexpected side effect of this feature: it now refuses some
profile ids like "java9+" = a profile id used in Apache Camel
I see that profile id is now checked like any other id:
https://github.com/apache/maven/commit/8defd169651db30fe0ac3ad3f318e471f0241d02#diff-690df442061d3325c6a7cf7b687e90ae79dd3639d45b8d1e606ad1bbc97a00e2
I'm not sure this is the best solution:
- too aggressive for example with this "+"
- not sufficiently aggressive if a profile is named
"-profile_cannot_be_activated"
should I create a separate Jira issue?
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
