[jira] [Commented] (MWAR-433) Maven WAR plugin is deleting files generated by other plugins after upgrading to 3.3.0
[
https://issues.apache.org/jira/browse/MWAR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270826#comment-17270826
]
Herve Boutemy commented on MWAR-433:
[~martin.weg...@ebp.de]
1. please open another Jira issue
2. please give the output of the whole war goal, to see a little bit more
and of course, we'll need to be able to reproduce to really dig into this
issue: this issue is fixed, we did an IT that checks it, if something is still
wrong, we don't know what and we'll need to find together
> Maven WAR plugin is deleting files generated by other plugins after upgrading
> to 3.3.0
> --
>
> Key: MWAR-433
> URL: https://issues.apache.org/jira/browse/MWAR-433
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Kyle Lieber
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 3.3.1
>
>
> My project generates wsdls using the {{jaxws-maven-plugin}} which puts the
> generated wsdls in
> {{${project.build.directory}/${project.build.finalName}/WEB-INF/wsdls}} so
> that they are packaged up in the war file. Then I have a client jar that
> copies those wsdls out of the war file using the {{maven-dependency-plugin}}
> and generates a client from the wsdls using the {{jaxws-maven-plugin}}.
> This all works fine using {{3.2.3}} of the {{maven-war-plugin}}. However,
> after upgrading to {{3.3.0}} my project fails to build because the wsdls are
> no longer preserved. It seems that they are being deleted by the
> {{maven-war-plugin}}.
> I created an example project on Github which recreates the problem. The
> {{master}} branch is using {{3.2.3}} and the {{maven-war-plugin-3.3.0}}
> branch is using {{3.3.0}}. You can find more details in the readme file of
> the example project:
> https://github.com/klieber/maven-war-plugin-bug
> I also suspect that MWAR-427 is the change that introduced this bug.
> Please let me know if there is anymore information I can provide. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MWAR-433) Maven WAR plugin is deleting files generated by other plugins after upgrading to 3.3.0
[
https://issues.apache.org/jira/browse/MWAR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270826#comment-17270826
]
Herve Boutemy edited comment on MWAR-433 at 1/24/21, 8:04 AM:
--
[~martin.weg...@ebp.de]
1. please open another Jira issue
2. please give the output of the whole war goal, to see a little bit more
and of course, we'll need to be able to reproduce to really dig into this
issue: this issue is fixed, we did an IT that checks it, if something is still
wrong, we don't know what and we'll need to find together
at least, I'm happy to have added INFO when deleting outdated resources: you
have a clear view on what is happening
was (Author: hboutemy):
[~martin.weg...@ebp.de]
1. please open another Jira issue
2. please give the output of the whole war goal, to see a little bit more
and of course, we'll need to be able to reproduce to really dig into this
issue: this issue is fixed, we did an IT that checks it, if something is still
wrong, we don't know what and we'll need to find together
> Maven WAR plugin is deleting files generated by other plugins after upgrading
> to 3.3.0
> --
>
> Key: MWAR-433
> URL: https://issues.apache.org/jira/browse/MWAR-433
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Kyle Lieber
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 3.3.1
>
>
> My project generates wsdls using the {{jaxws-maven-plugin}} which puts the
> generated wsdls in
> {{${project.build.directory}/${project.build.finalName}/WEB-INF/wsdls}} so
> that they are packaged up in the war file. Then I have a client jar that
> copies those wsdls out of the war file using the {{maven-dependency-plugin}}
> and generates a client from the wsdls using the {{jaxws-maven-plugin}}.
> This all works fine using {{3.2.3}} of the {{maven-war-plugin}}. However,
> after upgrading to {{3.3.0}} my project fails to build because the wsdls are
> no longer preserved. It seems that they are being deleted by the
> {{maven-war-plugin}}.
> I created an example project on Github which recreates the problem. The
> {{master}} branch is using {{3.2.3}} and the {{maven-war-plugin-3.3.0}}
> branch is using {{3.3.0}}. You can find more details in the readme file of
> the example project:
> https://github.com/klieber/maven-war-plugin-bug
> I also suspect that MWAR-427 is the change that introduced this bug.
> Please let me know if there is anymore information I can provide. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-filtering] sebthom commented on pull request #15: [MRESOURCES-268] - Report path of offending file on copy/filter error.
sebthom commented on pull request #15: URL: https://github.com/apache/maven-filtering/pull/15#issuecomment-766320217 @khmarbaise @hboutemy any thoughts? 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] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270843#comment-17270843
]
Guy Brand commented on MRESOLVER-153:
-
[~michael-o] Did that happen on the MRESOLVER-145 custom Maven build you
referenced above? I still could not add this automated step into our CI.
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method wich then throws the
> abov
[jira] [Commented] (MNG-7078) The integration tests use the default maven settings
[
https://issues.apache.org/jira/browse/MNG-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270850#comment-17270850
]
Robert Scholte commented on MNG-7078:
-
if a test depends on specific settings or properties, the verifier should be
forked to get an isolated "environment".
> The integration tests use the default maven settings
>
>
> Key: MNG-7078
> URL: https://issues.apache.org/jira/browse/MNG-7078
> Project: Maven
> Issue Type: Improvement
> Components: Integration Tests
>Reporter: Guillaume Nodet
>Assignee: Michael Osipov
>Priority: Major
>
> I have a profile that caused one integration test to fail, but it took me
> some time to realise the problem came from my {{~/.m2/settings.xml}} file.
> It would be better to have the tests use an empty settings file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270856#comment-17270856
]
Michael Osipov commented on MRESOLVER-153:
--
Release version.
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method wich then throws the
> above error. See this screenshot on how these files look like (cannot add the
> text here as {{null}} characters aren't sho
[jira] [Commented] (MNG-7078) The integration tests use the default maven settings
[
https://issues.apache.org/jira/browse/MNG-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270859#comment-17270859
]
Michael Osipov commented on MNG-7078:
-
The fork itself wouldn't help because the user settings would be pulled anyway.
You are right, but the test itself is faulty by manipulating Java internal
properties or reusing their names.
> The integration tests use the default maven settings
>
>
> Key: MNG-7078
> URL: https://issues.apache.org/jira/browse/MNG-7078
> Project: Maven
> Issue Type: Improvement
> Components: Integration Tests
>Reporter: Guillaume Nodet
>Assignee: Michael Osipov
>Priority: Major
>
> I have a profile that caused one integration test to fail, but it took me
> some time to realise the problem came from my {{~/.m2/settings.xml}} file.
> It would be better to have the tests use an empty settings file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-common-artifact-filters] elharo opened a new pull request #16: remove unused dependency
elharo opened a new pull request #16: URL: https://github.com/apache/maven-common-artifact-filters/pull/16 @michael-o 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-common-artifact-filters] elharo commented on a change in pull request #15: Big speed improvements for patterns that do not contain any wildcard
elharo commented on a change in pull request #15: URL: https://github.com/apache/maven-common-artifact-filters/pull/15#discussion_r563294869 ## File path: src/test/java/org/apache/maven/shared/artifact/filter/PatternFilterPerfTest.java ## @@ -0,0 +1,122 @@ +package org.apache.maven.shared.artifact.filter; Review comment: Needs a copyright statement 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-checkstyle-plugin] elharo opened a new pull request #43: update site plugin and links
elharo opened a new pull request #43: URL: https://github.com/apache/maven-checkstyle-plugin/pull/43 @michael-o 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] [Commented] (MCHECKSTYLE-371) Add logViolationCountToConsole property
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270882#comment-17270882 ] Hudson commented on MCHECKSTYLE-371: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Add logViolationCountToConsole property > --- > > Key: MCHECKSTYLE-371 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-371 > Project: Maven Checkstyle Plugin > Issue Type: New Feature > Components: checkstyle:check >Affects Versions: 3.0.0 >Reporter: Stig Rohde Døssing >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The plugin is missing a property to allow users to log the violation count to > console. > There are already a couple of places where the violation count may be logged, > but it doesn't happen unconditionally. The DefaultCheckstyleExecutor may log > the error count, but only if there are error-severity violations. The > CheckstyleViolationCheckMojo.countViolations method may log the violation > count, but only if there are ignored violations. > It would be nice if a logViolationCountToConsole property were added. > Printing the violation count is convenient in cases where e.g. you have fixed > some violations in a project and now want to reduce maxAllowedViolations. > Currently you have to either manually count the violations from the report, > or set maxAllowedViolations to 0 to get the plugin to fail and print the > violation count. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-390) Upgrade to checkstyle 8.29
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270888#comment-17270888 ] Hudson commented on MCHECKSTYLE-390: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Upgrade to checkstyle 8.29 > -- > > Key: MCHECKSTYLE-390 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-390 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Enrico Olivelli >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-364) Link to wiki is dead
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270883#comment-17270883 ] Hudson commented on MCHECKSTYLE-364: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Link to wiki is dead > > > Key: MCHECKSTYLE-364 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-364 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Peter Lamby >Assignee: Elliotte Rusty Harold >Priority: Minor > Labels: beginner, documentation, easyfix > Time Spent: 40m > Remaining Estimate: 0h > > The link on > [https://maven.apache.org/plugins/maven-checkstyle-plugin/index.html] points > to the wiki under > [http://docs.codehaus.org/display/MAVENUSER/Checkstyle+Plugin] which is dead -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-389) MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on report
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270889#comment-17270889 ] Hudson commented on MCHECKSTYLE-389: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > MCHECKSTYLE-365 introduces regression with 'rules' aggregate count section on > report > > > Key: MCHECKSTYLE-389 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-389 > Project: Maven Checkstyle Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Jeremy Landis >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Commit eee0ba1 in CheckstyleReportGenerator.java sets the default 'severity' > is set as 'error'. The suggestion is that it fixes count issues per adjusted > comment at that time. While that may or may not be true, what it does do is > incorrectly shut down the entire section of rules aggregation counts in some > cases. The severity only takes into account that specific one to then > aggregate. Selecting just one other than null is going to mess up the logic > as implemented here. This change needs reverted for that one specific change > only. The original issue should be reopened as it was not properly fixed. > The IT tests fails to take into account individual types. It includes both > 'info' and 'error' thus the only reason it even works. > In my test case, I'm using 'mybatis-3'. I have configured it to use google > checks so nothing else setup. It has 0 info, 3151warnings, and 0 errors. > Switching it to any other value will cause it to only reflect that section. > So using 'info', nothing shows up. Using 'error' as coded now, nothing shows > up. Using 'warning', it does show up. Continuing to use null as originally > the case, it does show up. > There really was a miscount somewhere, but that was not the right fix. For > my test, I get a miscount of +5 if using 'warning' or the original null. > That is entirely better than nothing. And therefore, the best solution for > now is to revert this change. > While my test does not have a combination of issues in 'info', 'warning', and > 'error', presumably most do and thus why this was not reported after almost a > year since the release of 3.1.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270897#comment-17270897
]
Hudson commented on MCHECKSTYLE-163:
Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-163
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Chris Whelan
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 2.7
>
> Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @requiresDependencyResolution compile which means that pom dependencies which
> have been declared as test are not returned by
> project.getTestClasspathElements().
> This is a particular issue for the checkstyle RedundantThrows check
> (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
> requires all Exceptions to be available on it's classpath.
> If code throws an Exception which has been imported from a maven
> test dependency, the exception will not be available on the
> classpath and this checkstyle check will fail.
> Example:
> Include junit as a test scope dependency in the project POM:
> {code:xml}
> junit
> junit
> ${junit.version}
> test
> {code}
> Throw any junit exception within project test code, e.g.:
> {code:java}public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
> public MyCustomTestRunner(final Class klass) throws
> InitializationError {
> {code}
> If RedundantThrows check is enabled, the following error will be thrown:
> {noformat}[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check
> (checkstyle-verify) @ sample-project ---
> [INFO] Starting audit...
> C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
> warning: Unable to get class information for InitializationError.
> Audit done.
> [ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
> InitializationError.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-388) Update internal dependencies with low impact
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270886#comment-17270886 ] Hudson commented on MCHECKSTYLE-388: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Update internal dependencies with low impact > > > Key: MCHECKSTYLE-388 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-388 > Project: Maven Checkstyle Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Jeremy Landis >Assignee: Enrico Olivelli >Priority: Minor > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Bring up to date all low impact dependencies which do not require any changes > to code. Both mvn clean install and mvn site will continue to work. > > * build helper from 1.9.1 to 3.0.0 > * junit from 4.8.2 to 4.13 > * plexus-interpolation from 1.24 to 1.26 > * plexus-velocity from 1.1.8 to 1.2 > * velocity from 1.5 to 1.7 > * commons-collections from 3.2.1 to 3.2.2 > * animal sniffer from 1.16 to 1.18 > * plexus-utils from 3.0.24 to 3.3.0 *1 > * jaxb-api 2.3.0 to 2.3.1 > * l10n plugin from 1.0-alpha-2 to last on googlecode of 1.8 > *1 Resolves CVE issue -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-380) Issue tracking page for maven-checkstyle-plugin is not available
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270884#comment-17270884 ] Hudson commented on MCHECKSTYLE-380: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Issue tracking page for maven-checkstyle-plugin is not available > > > Key: MCHECKSTYLE-380 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-380 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Reporter: abolfazl >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > I want to submit a problem with maven-checkstyle-plugin but do not know how > to :) > Page not found: > [https://maven.apache.org/plugins/maven-checkstyle-plugin/issue-tracking.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-365) Site Report, Rules: Violation count incorrect for duplicate rules when one uses default severity
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270890#comment-17270890
]
Hudson commented on MCHECKSTYLE-365:
Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/
> Site Report, Rules: Violation count incorrect for duplicate rules when one
> uses default severity
>
>
> Key: MCHECKSTYLE-365
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-365
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.17, 3.0.0
>Reporter: Robert Turner
>Assignee: Enrico Olivelli
>Priority: Trivial
> Fix For: 3.1.0
>
> Attachments: Screen Shot 2018-12-31 at 14.43.18.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the site report is generated, in the Rules section, the plug-in groups
> together the violation counts for rules that have the same name and message,
> but that have different severity levels -- specifically where one of the
> rules doesn't specify a severity level and uses the default ({{error}}). This
> results in both rules being listed with different properties and severity
> levels, but with the same violation count (which is incorrect).
> Also note that adding a unique {{id}} attribute to each of the rules also
> does not result in the violation counts being aggregated correctly. (the
> proposed patch does not address this aspect).
> To be correct, the report should use the same criteria for determining unique
> rules as it does for aggregating the violation counts for each rule.
> A simple user work-around for some rules (such as {{RegexpSingleline}}) is to
> change the {{message}} property for each of the rules with different severity
> levels. However, this doesn't work for other rules, such as
> {{FileTabCharacter}} as the {{message}} property is not supported for that
> rule.
> I will attach a screenshot of the issue manifesting itself, and I will
> provide a pull request for the changes to correct the issue.
> Sample rule set showing the issue:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-384) Incompatibility to Checkstyle version >= 8.24 - Upgrade to 8.28
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270887#comment-17270887
]
Hudson commented on MCHECKSTYLE-384:
Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/
> Incompatibility to Checkstyle version >= 8.24 - Upgrade to 8.28
>
>
> Key: MCHECKSTYLE-384
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-384
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 3.1.0
>Reporter: Martin
>Assignee: Enrico Olivelli
>Priority: Blocker
> Fix For: 3.1.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest {{maven-checkstyle-plugin}} is incompatible to Checkstyle version
> 8.24 and newer. The check for "LineLength" was moved from "TreeWalker" to
> "Checker".
> For further details see "Breaking backward compatibility" under
> https://checkstyle.org/releasenotes.html#Release_8.24
>
> {code:none|title=Maven Console Output}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.1.0:check (validate) on
> project top-secrect: Failed during checkstyle configuration: LineLength is
> not allowed as a child in Checker -> [Help 1]
> [ERROR] ...
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-392) Update and backfill release notes
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270895#comment-17270895 ] Hudson commented on MCHECKSTYLE-392: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Update and backfill release notes > - > > Key: MCHECKSTYLE-392 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-392 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.1.2 > > > [http://maven.apache.org/plugins/maven-checkstyle-plugin/history.html] is > missing five years of release notes between 2015 and 2.15 and 2020 and 3.1.1. > > This should be filled in. Noticed because this range happens to include > exactly the versions I needed to know about. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-385) Violation should be a value class
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270894#comment-17270894
]
Hudson commented on MCHECKSTYLE-385:
Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/
> Violation should be a value class
> -
>
> Key: MCHECKSTYLE-385
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-385
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:check
>Affects Versions: 3.1.0
> Environment: Any (Linux, Window OS, etc.)
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Minor
> Labels: easyfix, pull-request-available
> Fix For: 3.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dear developers,
> while starting to implement the feature
> https://issues.apache.org/jira/browse/MCHECKSTYLE-356, I found out that a
> refactoring is needed.
>
> The method {color:#403294}{{int countViolations(Parser)}}{color} does so many
> things besides counting violations. Some of them are:
> * checking, if printing violations is wanted.
> * actually printing violations
> * counting violations
> * counting ignored violations
> * checking ignored violations count > 0 and logging
> * Keeping track of file changes
> I would like to rework this part of the code with no functional changes by
> creating a "Violation" value class.
> PR follows.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-358) Links to mailing lists in README are dead
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270892#comment-17270892 ] Hudson commented on MCHECKSTYLE-358: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Links to mailing lists in README are dead > - > > Key: MCHECKSTYLE-358 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-358 > Project: Maven Checkstyle Plugin > Issue Type: Task >Reporter: Karl Richter >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > The links in README to https://maven.apache.org/mail-lists.html are dead. > Not the best way, but an acceptable shortcut: I came across this because I > wanted to ping the dev mailing list about [Github pull requests without any > reaction](https://github.com/apache/maven-checkstyle-plugin/pulls). Others > and I would be happy if someone takes a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-387) Deprecate method setUpCheckstyleClassloader in 3.1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270893#comment-17270893
]
Hudson commented on MCHECKSTYLE-387:
Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/
> Deprecate method setUpCheckstyleClassloader in 3.1.2
>
>
> Key: MCHECKSTYLE-387
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-387
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 3.1.1
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Current situation
> In 3.1.1, the PR [https://github.com/apache/maven-checkstyle-plugin/pull/18]
> added a {{try-catch}}-block to the to-be-removed method call
> {{Checker::setClassLoader}}.
> Since users should be encuraged to upgrade and maven-plugin-developers should
> know that this method should be removed some time, a warning is to be issued
> if the method call was successful (i.e. when not entering the catch block).
> h2. Caveat and drawbacks
> * Users will have to update their {{checkstyle.xml}} file because of
> incompatible changes introduced in {{8.24}}.
> * Otherwise the warning might confuse users.
> * Once the method call to {{Checker::setClassLoader}} is removed,
> {{checkstyle}} versions prior to 8.26 (Source:
> [https://checkstyle.org/releasenotes.html#Release_8.26]) cannot be used
> anymore (Source:
> [https://github.com/checkstyle/checkstyle/commit/145160f5e21b80c27dc93a1904fe33b9afd4f212]
> and [https://github.com/checkstyle/checkstyle/issues/3773]). But this issue
> is not about removing this method call any time soon.
> => it will probably work fine for any 8.x version because this method existed
> for a deprecated check only.
> h2. Related issues
> *
> [MCHECKSTYLE-381|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-381]]
> The mentioned previous commit.
> *
> [MCHECKSTYLE-384|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-384]]:
> Once this maven-checkstyle-plugin updates to checkstyle > 8.24, the default
> installation for users will break existing installations unless users use
> this method of downgrading their checkstyle version:
> [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html.]
>
> * Also track [https://github.com/checkstyle/checkstyle/issues/7190.] This
> will tell when the checkstyle team removes that method.
> h2. Documentation
> * maven-checkstyle-plugin is compatible with all checkstyle versions by
> functionality.
> * maven-checkstyle-plugin >= 3.1.2 will complain if checkstyle < 8.29 is
> being used, which is the default (since it requires checkstyle 8.19).
> * If we are ever going to remove the method {{Checker::setClassLoader}},
> this means that earlier versions than checkstyle 8.26 are not supported. They
> will probably work just fine, but the method call became a 'real' no-op in
> 8.26. Might be worth documentation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-391) Update parent to 34
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270891#comment-17270891 ] Hudson commented on MCHECKSTYLE-391: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Update parent to 34 > --- > > Key: MCHECKSTYLE-391 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-391 > Project: Maven Checkstyle Plugin > Issue Type: Task >Affects Versions: 3.1.0 >Reporter: Enrico Olivelli >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-400) Remove travis.org ci
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270896#comment-17270896 ] Hudson commented on MCHECKSTYLE-400: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Remove travis.org ci > > > Key: MCHECKSTYLE-400 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-400 > Project: Maven Checkstyle Plugin > Issue Type: Task >Reporter: Benjamin Marwell >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.1.2 > > > Can be removed, there is GitHub Actions and ASF Jenkins. > Info: > https://discourse.julialang.org/t/reminder-travis-ci-org-shuts-down-on-december-31-2020/47234/10 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-381) Remove usage of deprecated class loading functionality from checkstyle
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270885#comment-17270885 ] Hudson commented on MCHECKSTYLE-381: Build failed in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin » 31 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/31/2/ > Remove usage of deprecated class loading functionality from checkstyle > -- > > Key: MCHECKSTYLE-381 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-381 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Reporter: richard >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Checkstyle Issue: [https://github.com/checkstyle/checkstyle/issues/7190] > > Checkstyle would like to remove all usage of class loading as it is a > deprecated functionality and has since been made broken since recent changes. > The methods were only left to keep compatibility with maven-checkstyle-plugin > but they don't do anything anymore. Checkstyle is a static analysis tool. > Class loading always had issues and this is why it was deprecated. We are now > in the process of removing it completely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
Krosheninnikov Artem created MENFORCER-376: -- Summary: Add support for excludes/includes in requireJavaVendor rule Key: MENFORCER-376 URL: https://issues.apache.org/jira/browse/MENFORCER-376 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 3.0.0-M3 Reporter: Krosheninnikov Artem There was a suggestion here [1] to add includes/excludes support in requireJavaVendor rule. Right now it's not clear how it would work if you define the same vendor name in exclude and include lists but implementation can be more or less copied from BannedDependencies rule. [1] https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] elharo opened a new pull request #44: use try with resources and charset
elharo opened a new pull request #44: URL: https://github.com/apache/maven-checkstyle-plugin/pull/44 @bmarwell 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] [Commented] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270901#comment-17270901 ] Krosheninnikov Artem commented on MENFORCER-376: There are several questions: 1) It should not be possible to define one vendor both in includes and excludes, right? 2) If vendor name is not from includes but it's also not in excludes, what should happen? [~MattNelson], [~jbennett2091], WDYT? > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Major > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCHECKSTYLE-401) NullPointerException in Violation class
Elliotte Rusty Harold created MCHECKSTYLE-401:
-
Summary: NullPointerException in Violation class
Key: MCHECKSTYLE-401
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-401
Project: Maven Checkstyle Plugin
Issue Type: Bug
Reporter: Elliotte Rusty Harold
import org.junit.Assert;
import org.junit.Test;
public class ViolationTest
{
@Test
public void testEquals() {
Violation v1 = new Violation("", null, "", "", "", "", "");
Violation v2 = new Violation("", null, "", "", "", "", "");
Assert.assertEquals( v1, v2 );
}
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] elharo merged pull request #43: update site plugin and links
elharo merged pull request #43: URL: https://github.com/apache/maven-checkstyle-plugin/pull/43 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-checkstyle-plugin] slachiewicz commented on pull request #43: update site plugin and links
slachiewicz commented on pull request #43: URL: https://github.com/apache/maven-checkstyle-plugin/pull/43#issuecomment-766361662 Please try to upgrade Doxia... 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-common-artifact-filters] slachiewicz commented on pull request #16: remove unused dependency
slachiewicz commented on pull request #16: URL: https://github.com/apache/maven-common-artifact-filters/pull/16#issuecomment-766361922 I have plan to do more cleanups later, please do not change anything here because that may make my already prepared commits harder to apply 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-checkstyle-plugin] elharo opened a new pull request #45: explicit dependencies
elharo opened a new pull request #45: URL: https://github.com/apache/maven-checkstyle-plugin/pull/45 @bmarwell the plugin depends on both of these directly 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-checkstyle-plugin] elharo commented on pull request #43: update site plugin and links
elharo commented on pull request #43: URL: https://github.com/apache/maven-checkstyle-plugin/pull/43#issuecomment-766363242 I tried that. It failed. It might require more detailed effort and code changes, or some other fixes first. 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] (MNG-6757) Cant create a proper BOM when using ${revision}
[
https://issues.apache.org/jira/browse/MNG-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270780#comment-17270780
]
Kalle Widell edited comment on MNG-6757 at 1/24/21, 6:16 PM:
-
Sorry, been busy here. I did try tonight.
Using
apache-maven-4.0.0-alpha-1-20210115.141200-33-bin (taken from your CI server?!)
i tried to build attached sample project.
# mvn clean install
# The installled/resulting
.m2//example-library-bom/pom.xml ("bom") does not replace
usage of ${revision} in the dependencyManagegment->dependencis-> dependency :
example-library-api clause of this file.
Cant really remember the details here. But if another project depends om
something containing ${revision} it gets confused? Can't remember the issue
with project.version (from a users perspective they sound the same). These are
not resolved either in the resulting bom. What did you hope should happen /
changed?
was (Author: widell):
Sorry, been busy here. I did try tonight.
Using
apache-maven-4.0.0-alpha-1-20210115.141200-33-bin (taken from your CI server?!)
i tried to build attached sample project.
# mvn clean install
# The installled/resulting
.m2//example-library-bom/pom.xml ("bom") does not replace
usage of ${revision} in the dependencyManagegment->dependencis-> dependency :
example-library-api clause of this file.
Cant really remember the details here. But if another project depends om
something containing ${revision} it gets confused? Can remember the issue
with project.version (from a users perspective they sound the same). These are
not resolved either in the resulting bom. What did you hope should happen?
> Cant create a proper BOM when using ${revision}
> ---
>
> Key: MNG-6757
> URL: https://issues.apache.org/jira/browse/MNG-6757
> Project: Maven
> Issue Type: Bug
> Components: core, Errors
>Affects Versions: 3.6.1
> Environment: Ubuntu 18.04
>Reporter: Kalle Widell
>Priority: Major
> Fix For: 4.0.x-candidate, waiting-for-feedback
>
> Attachments: sample-project.tar.bz2
>
>
> When I have a multimodule project where one of the modules is a BOM, meant
> for other projects. (Think spring boot starter bom) I see no way of using
> ${revision} to make the resulting BOM have the version of the project to be
> resolved in that bom. I cannot use ${project.version} in the BOM for this, as
> these wont be resolved upon install/deploy.
> Apart from the BOM part Ive set up my project according to
> [https://maven.apache.org/maven-ci-friendly.html]
> Also made a ticket here
> [https://github.com/mojohaus/flatten-maven-plugin/issues/104]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-common-artifact-filters] slachiewicz commented on pull request #16: remove unused dependency
slachiewicz commented on pull request #16: URL: https://github.com/apache/maven-common-artifact-filters/pull/16#issuecomment-766408356 reason why we have still this dependency.. https://github.com/apache/maven-common-artifact-filters/pull/12 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] (MPIR-402) Modules Report: provide links to Maven Central
Florian Brunner created MPIR-402: Summary: Modules Report: provide links to Maven Central Key: MPIR-402 URL: https://issues.apache.org/jira/browse/MPIR-402 Project: Maven Project Info Reports Plugin Issue Type: New Feature Components: modules Reporter: Florian Brunner In the table of the modules report also provide the links to Maven Central. This issue is actually about contributing a patch I made some years ago back to this upstream project. Here is a sample how it looks like: [https://www.drombler.org/drombler-fx/1.0/docs/site/modules.html] I'm using this patch already for several years and it is great for documenting the Maven coordinates of libraries, especially in multi-Module projects, IMHO. I typically directly point to this report from some prominent places such from a top site inside the documentation ([https://www.drombler.org/drombler-fx/1.0/]) or in blog posts (https://puces-blog.blogspot.com/2020/01/drombler-fx-version-10-released.html). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPIR-402) Modules Report: provide links to Maven Central
[ https://issues.apache.org/jira/browse/MPIR-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270972#comment-17270972 ] Florian Brunner commented on MPIR-402: -- I finally found some time to merge the Subversion based patch to Git and upgrade it to the latest version: [https://github.com/apache/maven-project-info-reports-plugin/compare/master...puce77:feature/maven-central-module-info] (work still in progress) > Modules Report: provide links to Maven Central > -- > > Key: MPIR-402 > URL: https://issues.apache.org/jira/browse/MPIR-402 > Project: Maven Project Info Reports Plugin > Issue Type: New Feature > Components: modules >Reporter: Florian Brunner >Priority: Major > > In the table of the modules report also provide the links to Maven Central. > This issue is actually about contributing a patch I made some years ago back > to this upstream project. > Here is a sample how it looks like: > [https://www.drombler.org/drombler-fx/1.0/docs/site/modules.html] > I'm using this patch already for several years and it is great for > documenting the Maven coordinates of libraries, especially in multi-Module > projects, IMHO. > I typically directly point to this report from some prominent places such > from a top site inside the documentation > ([https://www.drombler.org/drombler-fx/1.0/]) or in blog posts > (https://puces-blog.blogspot.com/2020/01/drombler-fx-version-10-released.html). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7081) Proxyless Repository Content Filtering
John Robert Fallows created MNG-7081:
Summary: Proxyless Repository Content Filtering
Key: MNG-7081
URL: https://issues.apache.org/jira/browse/MNG-7081
Project: Maven
Issue Type: Improvement
Components: Artifacts and Repositories
Reporter: John Robert Fallows
Support ability to filter repository resolution to include or exclude by
{{groupId}} similar to [Gradle's Repository Content
Filtering|[https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering]].
{quote}There are different use cases for it:
* performance, when you know a dependency will never be found in a specific
repository
* security, by avoiding leaking what dependencies are used in a private project
* reliability, when some repositories contain corrupted metadata or
artifacts{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6435:
Fix Version/s: (was: 4.0.x-candidate)
Issues to be reviewed for 4.x
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270983#comment-17270983
]
Michael Osipov commented on MNG-6435:
-
I have done further investigation and removing this isn't really possible at
the moment due to bad design and a failing IT. The {{interpolate}} method
interpolates instead on a memory/object model on the serialized model. It does
not know anything about the implementation of the settings writer. It assumes
to be XML. The problem is that it lacks abstraction. If you would have a model
in YAML a "&x" isn't a problem in a string, but it would be changed for
different semantics.
To solve this one should write an object visitor which interpolates each string
separately or you need some notion from the writer how to escape its input w/o
disclosing that this is XML, YAML, JSON or else. Something like an
{{InterpolationPostProcessor}} generated by Modello.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6435:
---
Assignee: (was: Michael Osipov)
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-filtering] slachiewicz commented on pull request #14: declare dependencies
slachiewicz commented on pull request #14: URL: https://github.com/apache/maven-filtering/pull/14#issuecomment-766429749 Any reason why we need to declare these dependencies? org.eclipse.sisu.plexus is a transitive dependency from maven plugin API and with each update to minimum maven.version property someone needs to adjust also this one instead of giving Maven chance to do its job. 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] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270983#comment-17270983
]
Michael Osipov edited comment on MNG-6435 at 1/24/21, 8:54 PM:
---
I have done further investigation and removing this isn't really possible at
the moment due to bad design and a failing IT. The {{interpolate}} method
interpolates instead on a memory/object model on the serialized model. It does
not know anything about the implementation of the settings writer. It assumes
to be XML. The problem is that it lacks abstraction. If you would have a model
in YAML a "&x" isn't a problem in a string, but it would be changed for
different semantics.
To solve this one should write an object visitor which interpolates each string
separately or you need some notion from the writer how to escape its input w/o
disclosing that this is XML, YAML, JSON or else. Something like an
{{InterpolationPostProcessor}} generated by Modello.
With the {{Interpolator}} being string-based I so no option to make it work in
object models.
was (Author: michael-o):
I have done further investigation and removing this isn't really possible at
the moment due to bad design and a failing IT. The {{interpolate}} method
interpolates instead on a memory/object model on the serialized model. It does
not know anything about the implementation of the settings writer. It assumes
to be XML. The problem is that it lacks abstraction. If you would have a model
in YAML a "&x" isn't a problem in a string, but it would be changed for
different semantics.
To solve this one should write an object visitor which interpolates each string
separately or you need some notion from the writer how to escape its input w/o
disclosing that this is XML, YAML, JSON or else. Something like an
{{InterpolationPostProcessor}} generated by Modello.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6435) DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
[
https://issues.apache.org/jira/browse/MNG-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270984#comment-17270984
]
Michael Osipov commented on MNG-6435:
-
The Maven Model does not seem to suffer form this because it uses a visitor
approach:
{noformat}
mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4625
(master=)
$
/var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/apache-maven/bin/mvn
-e --batch-mode
-Dmaven.repo.loca1l=/usr/home/mosipov/var/Projekte/maven-integration-testing/repo
validate -Dtest.prop1="&x=y<>" help:effective-pom
...
[INFO]
Effective POMs, after inheritance, interpolation, and profiles are applied:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.apache.maven.its.mng4625
test
0.1
pom
Maven Integration Test :: MNG-4625
Verify that interpolation of the settings.xml doesn't fail if an
expression's value contains
XML special characters. &x=y<>
{noformat}
Yes, that is ugly with settings. Would be a nice improvement for an
intermediate developer with GSoC.
> DefaultSettingsBuilder assumes all SettingsReader/Writer impls will use XML
> ---
>
> Key: MNG-6435
> URL: https://issues.apache.org/jira/browse/MNG-6435
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.5.3
>Reporter: Laird Nelson
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> On or around line 234, interpolation of settings assumes XML:
> {code}
> interpolator.addPostProcessor( new InterpolationPostProcessor()
> {
> @Override
> public Object execute( String expression, Object value )
> {
> if ( value != null )
> {
> // we're going to parse this back in as XML so we need to escape XML
> markup
> value = value.toString().replace( "&", "&" ).replace( "<", "<"
> ).replace( ">", ">" );
> return value;
> }
> return null;
> }
> } );
> {code}
> The value being interpolated here is the result of a {{SettingsWriter}}'s
> output. Obviously this kind of escaping doesn't make any sense if the
> {{SettingsWriter}} in question is not XML-based.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
https://issues.apache.org/jira/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reopened MSHARED-121:
--
> FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
> drive letter.
> --
>
> Key: MSHARED-121
> URL: https://issues.apache.org/jira/browse/MSHARED-121
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3
>Reporter: John Dennis Casey
>Priority: Major
> Attachments:
> 0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch,
> FilteringUtilsTest.java
>
>
> FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
> path, or at least the string {noformat}":\\"{noformat} to be present in order
> to trigger escaping the value as a windows path.
> In cases where the path is an absolute reference to a file on the current
> drive (no drive letter is included), or when the path starts with an
> unresolved expression (in cases where n+1 level interpolation will eventually
> resolve the expression), escaping doesn't happen at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-903) DefaultMavenResourcesFiltering remove dependence n Scanner
[ https://issues.apache.org/jira/browse/MSHARED-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270993#comment-17270993 ] Sylwester Lachiewicz commented on MSHARED-903: -- New scanner comes from plexus-build-api (looks unmaintaned) org.sonatype.plexus.build.incremental.BuildContext#newScanner(java.io.File, boolean) > DefaultMavenResourcesFiltering remove dependence n Scanner > -- > > Key: MSHARED-903 > URL: https://issues.apache.org/jira/browse/MSHARED-903 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Elliotte Rusty Harold >Priority: Minor > > This can be done with code in Java , and move plexus-utils to at most test > scope. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] bmarwell commented on a change in pull request #44: use try with resources and charset
bmarwell commented on a change in pull request #44:
URL:
https://github.com/apache/maven-checkstyle-plugin/pull/44#discussion_r563372857
##
File path:
src/main/java/org/apache/maven/plugins/checkstyle/rss/VelocityTemplate.java
##
@@ -77,52 +79,34 @@ public VelocityComponent getVelocity()
* Using a specified Velocity Template and provided context, create the
outputFilename.
*
* @param outputFilename the file to be generated.
- * @param template the velocity template to use.
- * @param contextthe velocity context map.
- * @throws VelocityException if the template was not found or any other
Velocity exception.
- * @throws MojoExecutionException if merging the velocity template failed.
- * @throws IOException if there was an error when writing to the output
file.
+ * @param template the velocity template to use
+ * @param contextthe velocity context map
+ * @throws VelocityException if the template was not found or any other
Velocity exception
+ * @throws MojoExecutionException if merging the velocity template failed
+ * @throws IOException if there was an error writing to the output file
*/
public void generate( String outputFilename, String template, Context
context )
throws VelocityException, MojoExecutionException, IOException
{
-Writer writer = null;
-try
+File f = new File( outputFilename );
+if ( !f.getParentFile().exists() )
+{
+f.getParentFile().mkdirs();
+}
+
+try ( Writer writer = new OutputStreamWriter( new FileOutputStream( f
), StandardCharsets.UTF_8 ) )
{
Review comment:
Can you pick a more descriptive variable name for 'f' here? We have
`outputFilename` already, so `outputFile` would be an obvious choice.
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] (MENFORCER-374) plexus-container-default in enforcer-api is very outdated
[ https://issues.apache.org/jira/browse/MENFORCER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-374: --- Fix Version/s: 3.0.0-M4 > plexus-container-default in enforcer-api is very outdated > - > > Key: MENFORCER-374 > URL: https://issues.apache.org/jira/browse/MENFORCER-374 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0-M4 > > > `plexus-container-default` in `enforcer-api` module is `1.0-alpha-9` version > that seems to be extremely outdated. > PlexusContainer in this module is resolved as from > org.eclipse.sisu.plexus-0.0.0.M5.jar for me in IDEA. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MENFORCER-374) plexus-container-default in enforcer-api is very outdated
[ https://issues.apache.org/jira/browse/MENFORCER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MENFORCER-374: -- Assignee: Sylwester Lachiewicz > plexus-container-default in enforcer-api is very outdated > - > > Key: MENFORCER-374 > URL: https://issues.apache.org/jira/browse/MENFORCER-374 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > > `plexus-container-default` in `enforcer-api` module is `1.0-alpha-9` version > that seems to be extremely outdated. > PlexusContainer in this module is resolved as from > org.eclipse.sisu.plexus-0.0.0.M5.jar for me in IDEA. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o commented on a change in pull request #429: [MNG-7051] - Optionally skip non-existing profiles and break on missing required profiles
michael-o commented on a change in pull request #429:
URL: https://github.com/apache/maven/pull/429#discussion_r563362703
##
File path: maven-core/src/main/java/org/apache/maven/DefaultMaven.java
##
@@ -493,25 +508,88 @@ private void
validatePrerequisitesForNonMavenPluginProjects( List
}
}
-private void validateActivatedProfiles( List projects,
List activeProfileIds )
+/**
+ * Get all profiles that are detected in either the projects, any parent
of the projects or the settings.
+ * @param session The Maven session
+ * @return A {@link Set} of profile identifiers, never {@code null}.
+ */
+private Set getAllProfiles( MavenSession session )
{
-Collection notActivatedProfileIds = new LinkedHashSet<>(
activeProfileIds );
-
-for ( MavenProject project : projects )
+final Set projectsIncludingParents = new HashSet<>();
+for ( MavenProject project : session.getProjects() )
{
-for ( List profileIds :
project.getInjectedProfileIds().values() )
+boolean isAdded = projectsIncludingParents.add( project );
+MavenProject parent = project.getParent();
+while ( isAdded && parent != null )
{
-notActivatedProfileIds.removeAll( profileIds );
+isAdded = projectsIncludingParents.add( parent );
+parent = parent.getParent();
}
}
-for ( String notActivatedProfileId : notActivatedProfileIds )
+final Stream projectProfiles =
projectsIncludingParents.stream()
+.map( MavenProject::getModel )
+.map( Model::getProfiles )
+.flatMap( Collection::stream )
+.map( Profile::getId );
+final Stream settingsProfiles =
session.getSettings().getProfiles().stream()
+.map( IdentifiableBase::getId );
Review comment:
Why not call `Profile::getId`?
##
File path: maven-core/src/main/java/org/apache/maven/DefaultMaven.java
##
@@ -493,25 +508,88 @@ private void
validatePrerequisitesForNonMavenPluginProjects( List
}
}
-private void validateActivatedProfiles( List projects,
List activeProfileIds )
+/**
+ * Get all profiles that are detected in either the projects, any parent
of the projects or the settings.
+ * @param session The Maven session
+ * @return A {@link Set} of profile identifiers, never {@code null}.
+ */
+private Set getAllProfiles( MavenSession session )
{
-Collection notActivatedProfileIds = new LinkedHashSet<>(
activeProfileIds );
-
-for ( MavenProject project : projects )
+final Set projectsIncludingParents = new HashSet<>();
+for ( MavenProject project : session.getProjects() )
{
-for ( List profileIds :
project.getInjectedProfileIds().values() )
+boolean isAdded = projectsIncludingParents.add( project );
+MavenProject parent = project.getParent();
+while ( isAdded && parent != null )
{
-notActivatedProfileIds.removeAll( profileIds );
+isAdded = projectsIncludingParents.add( parent );
+parent = parent.getParent();
}
}
-for ( String notActivatedProfileId : notActivatedProfileIds )
+final Stream projectProfiles =
projectsIncludingParents.stream()
+.map( MavenProject::getModel )
+.map( Model::getProfiles )
+.flatMap( Collection::stream )
+.map( Profile::getId );
+final Stream settingsProfiles =
session.getSettings().getProfiles().stream()
+.map( IdentifiableBase::getId );
+
+return Stream.concat( projectProfiles, settingsProfiles ).collect(
toSet() );
+}
+
+/**
+ * Check whether the required profiles were found in any of the projects
we're building or the Maven settings.
+ * @param session the Maven session.
+ * @param profileActivation the requested optional and required profiles.
+ */
+private void validateRequiredProfiles( MavenSession session,
ProfileActivation profileActivation )
+{
+final Set allDetectedProfiles = getAllProfiles( session );
Review comment:
I think `allAvailableProfiles` suits better here.
##
File path: maven-core/src/main/java/org/apache/maven/DefaultMaven.java
##
@@ -493,25 +508,88 @@ private void
validatePrerequisitesForNonMavenPluginProjects( List
}
}
-private void validateActivatedProfiles( List projects,
List activeProfileIds )
+/**
+ * Get all profiles that are detected in either the projects, any parent
of the projects or the settings.
+ * @param session The Maven session
+ * @return A {@link Set} of profile identifiers, never {@code null}.
+ */
+private Set getAllProfiles( MavenSession sess
[GitHub] [maven-integration-testing] michael-o commented on a change in pull request #87: [MNG-7051] Test activation of non-existing profiles
michael-o commented on a change in pull request #87:
URL:
https://github.com/apache/maven-integration-testing/pull/87#discussion_r563393294
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/IntegrationTestSuite.java
##
@@ -106,6 +106,10 @@ public static Test suite()
// Tests that don't run stable and need to be fixed
//
-
// suite.addTestSuite( MavenIT0108SnapshotUpdateTest.class ); --
MNG-3137
+suite.addTestSuite(
MavenITmng4106InterpolationUsesDominantProfile400Test.class );
Review comment:
I am a bit confused by this. Some of the are already there, why they pop
up here now and why have some disabled?
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7051NonExistingProfileActivationTest.java
##
@@ -0,0 +1,94 @@
+package org.apache.maven.it;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+import java.io.File;
+import java.io.IOException;
+
+public class MavenITmng7051NonExistingProfileActivationTest
+extends AbstractMavenIntegrationTestCase
+{
+private static final String PROJECT_PATH =
"/mng-7051-non-existing-profile-activation";
+
+public MavenITmng7051NonExistingProfileActivationTest()
+{
+super( "[4.0.0-alpha-1,)" );
+}
+
+/**
+ * This test verifies that activating a non-existing profile breaks the
build.
+ */
+public void testActivatingNonExistingProfileBreaks() throws IOException,
VerificationException
+{
+final File projectDir = ResourceExtractor.simpleExtractResources(
getClass(), PROJECT_PATH );
+final Verifier verifier = newVerifier( projectDir.getAbsolutePath() );
+
+verifier.addCliOption( "-P" );
+verifier.addCliOption( "non-existing-profile" );
+verifier.setLogFileName( "test-breaking.txt" );
+
+try
+{
+verifier.executeGoal( "validate" );
+fail( "Activated a non-existing profile without ? prefix should
break the build, but it didn't." );
+}
+catch ( VerificationException ve )
+{
+// Inspect the reason why the build broke.
+verifier.verifyTextInLog( "The requested profile(s)
\"non-existing-profile\" could not be activated or de-activated because they do
not exist." );
Review comment:
Make sure that you verify a warning with the `[WARNING]` prefix, some
other ITs do this too.
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] [Commented] (MNG-7081) Proxyless Repository Content Filtering
[
https://issues.apache.org/jira/browse/MNG-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271003#comment-17271003
]
Michael Osipov commented on MNG-7081:
-
Is this a dup of MNG-6763?
> Proxyless Repository Content Filtering
> --
>
> Key: MNG-7081
> URL: https://issues.apache.org/jira/browse/MNG-7081
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: John Robert Fallows
>Priority: Major
>
> Support ability to filter repository resolution to include or exclude by
> {{groupId}} similar to [Gradle's Repository Content
> Filtering|[https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering]].
> {quote}There are different use cases for it:
> * performance, when you know a dependency will never be found in a specific
> repository
> * security, by avoiding leaking what dependencies are used in a private
> project
> * reliability, when some repositories contain corrupted metadata or
> artifacts{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPIR-402) Modules Report: provide links to Maven Central
[ https://issues.apache.org/jira/browse/MPIR-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271004#comment-17271004 ] Michael Osipov commented on MPIR-402: - I am banging my head against the wall finding the improvement you actually want to see here. Help me! > Modules Report: provide links to Maven Central > -- > > Key: MPIR-402 > URL: https://issues.apache.org/jira/browse/MPIR-402 > Project: Maven Project Info Reports Plugin > Issue Type: New Feature > Components: modules >Reporter: Florian Brunner >Priority: Major > > In the table of the modules report also provide the links to Maven Central. > This issue is actually about contributing a patch I made some years ago back > to this upstream project. > Here is a sample how it looks like: > [https://www.drombler.org/drombler-fx/1.0/docs/site/modules.html] > I'm using this patch already for several years and it is great for > documenting the Maven coordinates of libraries, especially in multi-Module > projects, IMHO. > I typically directly point to this report from some prominent places such > from a top site inside the documentation > ([https://www.drombler.org/drombler-fx/1.0/]) or in blog posts > (https://puces-blog.blogspot.com/2020/01/drombler-fx-version-10-released.html). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7081) Proxyless Repository Content Filtering
[
https://issues.apache.org/jira/browse/MNG-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7081:
Fix Version/s: waiting-for-feedback
> Proxyless Repository Content Filtering
> --
>
> Key: MNG-7081
> URL: https://issues.apache.org/jira/browse/MNG-7081
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: John Robert Fallows
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Support ability to filter repository resolution to include or exclude by
> {{groupId}} similar to [Gradle's Repository Content
> Filtering|[https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering]].
> {quote}There are different use cases for it:
> * performance, when you know a dependency will never be found in a specific
> repository
> * security, by avoiding leaking what dependencies are used in a private
> project
> * reliability, when some repositories contain corrupted metadata or
> artifacts{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7081) Proxyless Repository Content Filtering
[
https://issues.apache.org/jira/browse/MNG-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271009#comment-17271009
]
John Robert Fallows commented on MNG-7081:
--
[~michael-o] yes, thanks.
I have upvoted MNG-6763 instead, please feel free to close this as a duplicate.
> Proxyless Repository Content Filtering
> --
>
> Key: MNG-7081
> URL: https://issues.apache.org/jira/browse/MNG-7081
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: John Robert Fallows
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Support ability to filter repository resolution to include or exclude by
> {{groupId}} similar to [Gradle's Repository Content
> Filtering|[https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering]].
> {quote}There are different use cases for it:
> * performance, when you know a dependency will never be found in a specific
> repository
> * security, by avoiding leaking what dependencies are used in a private
> project
> * reliability, when some repositories contain corrupted metadata or
> artifacts{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7081) Proxyless Repository Content Filtering
[
https://issues.apache.org/jira/browse/MNG-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7081.
---
Fix Version/s: (was: waiting-for-feedback)
Resolution: Duplicate
> Proxyless Repository Content Filtering
> --
>
> Key: MNG-7081
> URL: https://issues.apache.org/jira/browse/MNG-7081
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: John Robert Fallows
>Priority: Major
>
> Support ability to filter repository resolution to include or exclude by
> {{groupId}} similar to [Gradle's Repository Content
> Filtering|[https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering]].
> {quote}There are different use cases for it:
> * performance, when you know a dependency will never be found in a specific
> repository
> * security, by avoiding leaking what dependencies are used in a private
> project
> * reliability, when some repositories contain corrupted metadata or
> artifacts{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-tree] elharo commented on a change in pull request #6: [PoC] Require maven 3.1.1
elharo commented on a change in pull request #6: URL: https://github.com/apache/maven-dependency-tree/pull/6#discussion_r563399792 ## File path: pom.xml ## @@ -173,7 +139,8 @@ These files contains the expected output of this component and can not contain a license header. --> src/it/*/expected*.txt - +src/it/**/*.iml Review comment: we should really .gitignore these ## File path: src/main/java/org/apache/maven/shared/dependency/graph/DependencyGraphBuilder.java ## @@ -26,7 +26,7 @@ import java.util.Collection; /** - * Maven project dependency graph builder API, neutral against Maven 2 or Maven 3. + * Maven project dependency graph builder API, based on Maven 3.1+. Review comment: Wasn't this specifically the point of this API? i.e. to bridge between 2 and 3? or was that a different artifact? 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] [Commented] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271012#comment-17271012 ] John Robert Fallows commented on MNG-6763: -- There is also value in annotating a ** in *pom.xml* to indicate that it _only_ includes artifacts for a specific *groupId*, such that it can be safely skipped for downloads or update checks for other artifacts. Note: Gradle's Repository Content Filtering has this functionality. https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering > Restrict repositories to specific groupIds > -- > > Key: MNG-6763 > URL: https://issues.apache.org/jira/browse/MNG-6763 > Project: Maven > Issue Type: New Feature >Reporter: dennis lucero >Priority: Major > Labels: intern > > It should be possible to restrict the repositories specified in settings.xml > to specific groupIds. Looking at > [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository], > it seems this is currently not the case. > Background: We use Nexus to host our own artifacts. The settings.xml contains > our Nexus repository with always because > sometimes a project is built while a dependency is not yet in our Nexus repo > – without updatePolicy, it would take 24 hours or manual deletion of metadata > to make Maven re-check for the missing dependency. > Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in > our build process. > This results in lots of queries (more than 300 in a simple Dropwizard > project) to our repo which will never succeed. If we could specify that our > repo only supplies groupIds beginning with org.example, Maven could skip > update checks for groupIds starting with com.fasterxml.jackson and so on, > speeding up the build process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-filtering] elharo commented on pull request #14: declare dependencies
elharo commented on pull request #14: URL: https://github.com/apache/maven-filtering/pull/14#issuecomment-766457052 If one specifically imports classes from these dependencies, then they should be declared. Relaying on transitive dependencies is brittle. 5 months later I don't recall exactly which classes are imported from where but mvn dependency:analyze will find anything that's not needed. 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-enforcer] KroArtem opened a new pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
KroArtem opened a new pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271023#comment-17271023 ] Alexander Kriegisch commented on SUREFIRE-1788: --- [~tibordigana], this is still open AFAIK, so may I after 6 months kindly ask you to fix this? You said before that you know what needs to be done and I explained why I am not confident to contribute here because I am a mere Maven user and have never written a mojo or plugin. This still holds true as of today. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271023#comment-17271023 ] Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 2:08 AM: - [~tibordigana], this is still open AFAIK, so may I after 6 months kindly ask you to fix this? You said before that you know what needs to be done and I explained why I am not confident to contribute here because I am a mere Maven user and have never written a mojo or plugin. This still holds true as of today. Let me know if you wish to have a new issue created for this. I see that the old feature branch for this issue has been merged and deleted already. was (Author: kriegaex): [~tibordigana], this is still open AFAIK, so may I after 6 months kindly ask you to fix this? You said before that you know what needs to be done and I explained why I am not confident to contribute here because I am a mere Maven user and have never written a mojo or plugin. This still holds true as of today. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271046#comment-17271046
]
Alexander Kriegisch commented on SUREFIRE-1788:
---
I just looked into your instructions, and it wouldtake so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want? Or should I check for {{instanceof ForkedNodeArg}} and then cast? Sounds
ugly.
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271046#comment-17271046
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 2:50 AM:
-
I just looked into your instructions, and it would take so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want? Or should I check for {{instanceof ForkedNodeArg}} and then cast? Sounds
ugly.
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
was (Author: kriegaex):
I just looked into your instructions, and it wouldtake so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want? Or should I check for {{instanceof ForkedNodeArg}} and then cast? Sounds
ugly.
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271046#comment-17271046
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 2:57 AM:
-
I just looked into your instructions, and it would take so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want?
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
was (Author: kriegaex):
I just looked into your instructions, and it would take so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want? Or should I check for {{instanceof ForkedNodeArg}} and then cast? Sounds
ugly.
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271046#comment-17271046
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 2:59 AM:
-
I just looked into your instructions, and it would take so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not of the private inner class
{{ForkStarter.ForkedNodeArg}}. In order to pull that off I would have to extend
the interface and all implementing classes. Is that what you want?
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
was (Author: kriegaex):
I just looked into your instructions, and it would take so much longer for you
to answer my questions than do just do it yourself. Given your tight time
budget, that would not help you in any way. Some initial questions:
* What do you mean by "builder methods"? There is no builder pattern in class
{{StartupReportConfiguration}}.
* Do you maybe just mean something like returning something like {{new
NativeStdOutStreamConsumer(new PrintStreamLogger(originalSystemOut))}} from
those so-called builder methods?
* When extending the constructor of ForkedNodeArg, I would also add two fields
and getters, I guess. But then in {{SurefireForkChannel}} I could not easily
use those getters because {{getArguments()}} just returns an interface instance
{{ForkNodeArguments}}, not ForkedNodeArg. In order to pull that off I would
have to extend the interface and all implementing classes. Is that what you
want?
I would really rather leave that change up to you, otherwise I might break more
than I would fix.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] dependabot[bot] opened a new pull request #34: Bump assertj-core from 3.18.1 to 3.19.0
dependabot[bot] opened a new pull request #34: URL: https://github.com/apache/maven-jlink-plugin/pull/34 Bumps [assertj-core](https://github.com/assertj/assertj-core) from 3.18.1 to 3.19.0. Commits https://github.com/assertj/assertj-core/commit/54e2bcae01429f43fdc135e36e4ccc2349e52da7";>54e2bca [maven-release-plugin] prepare release assertj-core-3.19.0 https://github.com/assertj/assertj-core/commit/133719e9e7a4df7e4c4e03b57c3483b3a3d5f051";>133719e Minor javadoc edit https://github.com/assertj/assertj-core/commit/fd77d821299cfdaf2d4edd746714cb22e19e4266";>fd77d82 Deprecate isXmlEqualToContentOf in favor of XML Unit https://github.com/assertj/assertj-core/commit/52c6a284bb8ce0c9063782df84f4fcc06b7c5a29";>52c6a28 Javadoc improvements https://github.com/assertj/assertj-core/commit/bb13aac7fdc73558544453e7c3f0f1db8a526619";>bb13aac Rename isEmpty/isNotEmpty to isEmptyFile/isNotEmptyFile https://github.com/assertj/assertj-core/commit/3b85988540abcf9d1d3ce6e8267b238fea03c70e";>3b85988 Bump equalsverifier from 3.5.1 to 3.5.2 (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2104";>#2104) https://github.com/assertj/assertj-core/commit/67822a4b6ccb63a2639c3d78cb5fa54938c01fbd";>67822a4 Javadoc fixes and improvements https://github.com/assertj/assertj-core/commit/89292201d295dd7fbf4848b79bf0395ca26b16ba";>8929220 Prepare 3.19.0 version https://github.com/assertj/assertj-core/commit/81ba1cc4fd88f91b98e8c88666747c164d70df9e";>81ba1cc Fix javadoc warning https://github.com/assertj/assertj-core/commit/7827265a7b90db7875747857e6e4cb03fa883c51";>7827265 Remove <> from ShouldBeEqualByComparingOnlyGivenFields, ShouldBeEqualToIgnori... Additional commits viewable in https://github.com/assertj/assertj-core/compare/assertj-core-3.18.1...assertj-core-3.19.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 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] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271066#comment-17271066 ] Tibor Digana commented on SUREFIRE-1788: [~kriegaex] Sorry, I have been working on totally different topic in Surefire project where we are reworking the architecture and this is the biggest milestone release for me. I can interrupt my working copy and switch to this problem. After seen mine comment I have understood what change is necessary to do. So I will create a PR on GitHub and we can agree that you will make a test with the SNAPSHOT version. I think this issue can be joined together with SUREFIRE-1801. Can you push some a project at GH with a reproducible problem? I am afraid if we redirect all the native stream of JVM to the console, the users will obtain messy console logs. T > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271072#comment-17271072 ] Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 5:27 AM: - I gladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and play around with the settings. was (Author: kriegaex): I agladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and play around with the settings. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271072#comment-17271072 ] Alexander Kriegisch commented on SUREFIRE-1788: --- I agladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and play around with the settings. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271072#comment-17271072 ] Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 5:29 AM: - I gladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and also some comments concerning open issues. Change it to your heart's content, just play around with the settings in order to test different things. But the project has many modules, I did not create a dedicated, small reproducer. Maybe I could do that, but I was alway testing the real thing so far. Feel free to follow up with questions. was (Author: kriegaex): I gladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and play around with the settings. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271072#comment-17271072 ] Alexander Kriegisch edited comment on SUREFIRE-1788 at 1/25/21, 5:47 AM: - I gladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and also some comments concerning open issues. Change it to your heart's content, just play around with the settings in order to test different things. But the project has many modules, I did not create a dedicated, small reproducer. Maybe I could do that, but I was always testing the real thing so far. Feel free to follow up with questions. was (Author: kriegaex): I gladly agree to re-test, of course. 😀 The project in question is [Sarek|https://github.com/SarekTest/Sarek]. Starting [here|https://github.com/SarekTest/Sarek/blob/master/pom.xml#L180], you can see my current configuration and also some comments concerning open issues. Change it to your heart's content, just play around with the settings in order to test different things. But the project has many modules, I did not create a dedicated, small reproducer. Maybe I could do that, but I was alway testing the real thing so far. Feel free to follow up with questions. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
