[jira] [Created] (MNG-7837) Maven blows up on nested pom attributes
Lenny Primak created MNG-7837:
-
Summary: Maven blows up on nested pom attributes
Key: MNG-7837
URL: https://issues.apache.org/jira/browse/MNG-7837
Project: Maven
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 4.0.0-alpha-7
Reporter: Lenny Primak
* This started happening in 4.0.0-alpha-7
{{When pom contains nested , maven refuses to build:}}
{code:java}
% mvn clean
[INFO] Scanning for projects...
[ERROR] Some problems were encountered while processing the POMs
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project (/Users/lprimak/Documents/dev/flowlogix/pom.xml) has 1
error
[ERROR] Unrecognised tag: 'project' (position: START_TAG @1:205) @ line 1,
column 205 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles: {code}
Example:
{code:java}
...
org.commonjava.maven.plugins
directory-maven-plugin
1.0
directories
directory-of
validate
flowlogix.basedir
com.flowlogix
flowlogix
...
{code}
Reproducer: [https://github.com/flowlogix/flowlogix]
Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740799#comment-17740799 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - users of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is sometimes implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - users of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is sometimes (see above) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - users of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is sometimes implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - users of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is sometimes (see above) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740797#comment-17740797 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default values - `0644` and `0755` respectively - so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740796#comment-17740796 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default value, so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default value, so it means that this condition is always true). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default value, so it means that this condition is always met). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740795#comment-17740795 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. `fileMode`/`directoryMode` are defined for `fileSet` (as far as I understand, both `fileMode` and `directoryMode` options of `fileSet` have default value, so it means that this condition is always met). 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740792#comment-17740792 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. User explicitly specifies `fileMode`/`directoryMode` in assembly descriptor. 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. User explicitly specifies `fileMode`/`directoryMode` in assembly descriptor. 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740791#comment-17740791 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. User explicitly specifies `fileMode`/`directoryMode` in assembly descriptor. 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when both conditions are met: 1. User explicitly specifies `fileMode`/`directoryMode` in assembly descriptor. 1. Assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team has) - user of Maven Assembly Plugin can specify `0` as `overrideUmask` configuration option to explicitly override umask which is (sometimes) implicitly used by Plexus Archiver. 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740786#comment-17740786 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when user explicitly specifies `fileMode`/`directoryMode` in assembly descriptor and when the assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configuration option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team needs). 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. It means that `0` as value of `overrideUmask` configuration option changes behavior of Maven Assembly Plugin only when `project.build.outputTimestamp` maven property is specified. It's sad (complicated for the users of Maven Assembly Plugin) behavior, but it's an issue of Plexus Archiver, which should not apply its default umask to file/directory permissions for the case when user explicitly specifies `fileMode`/`directoryMode` in assembly descriptor and when the assembly format (like `tar`, `zip` and `jar`) supports configuration of file/directory permissions independent of OS. This is the reason `overrideUmask` configura tion option of Maven Assembly Plugin is introduced: 1. It helps to workaround bug in Plexus Archiver (the case my team needs). 1. It provides additional flexibility for the users of Maven Assembly Plugin (but they need to realize that not every assembly format - like `dir` - supports setting same permissions as defined in assembly descriptor or source file/directory has in an OS independent way). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740781#comment-17740781 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on a diff in pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on code in PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#discussion_r1254863967 ## src/it/projects/bugs/massembly-791/pom.xml: ## @@ -0,0 +1,64 @@ + + +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 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + +org.apache.maven.plugin.assembly.test +it-project-parent +1 + + + org.apache.maven.its + massembly-791 + pom + 1.0 + + + 2023-06-07T10:18:31Z Review Comment: Current implementation of Plexus Archiver (used by Maven Assembly Plugin) - `org.codehaus.plexus.archiver.AbstractArchiver` class - applies its default umask (which is `022`) only when `configureReproducibleBuild` method is called. Current version of Maven Assembly Plugin invokes that method only when `project.build.outputTimestamp` maven property is specified. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[ https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740780#comment-17740780 ] ASF GitHub Bot commented on MASSEMBLY-791: -- mabrarov commented on PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#issuecomment-1624231912 Hi @elharo, Regarding that [comment](https://github.com/apache/maven-assembly-plugin/pull/148#pullrequestreview-1514449650): 1. Integration test for the new configuration option was added. 1. The case when invalid value is specified for `overrideUmask` plugin configuration option is described in Javadoc for `org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo#overrideUmask` field. This Javadoc is used for generation of plugin documentation - plugin.xml - so I find it sufficient. Thank you for your help with review of this pull request. > fileMode not set in dependencySet creating format tar.gz > > > Key: MASSEMBLY-791 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-791 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.6 > Environment: Linux and Windows >Reporter: Rick Poleshuck >Priority: Major > > The fileMode is ignored within a dependencySet while creating a tar.gz > archive. This works just fine in 2.4. > > > > com.company:dependency-artifact > > true > > > *.py > > > > 0750 > 0750 > > >
[GitHub] [maven-assembly-plugin] mabrarov commented on pull request #148: [MASSEMBLY-791] overrideUmask option to ensure permissions in packaged archive match …
mabrarov commented on PR #148: URL: https://github.com/apache/maven-assembly-plugin/pull/148#issuecomment-1624231912 Hi @elharo, Regarding that [comment](https://github.com/apache/maven-assembly-plugin/pull/148#pullrequestreview-1514449650): 1. Integration test for the new configuration option was added. 1. The case when invalid value is specified for `overrideUmask` plugin configuration option is described in Javadoc for `org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo#overrideUmask` field. This Javadoc is used for generation of plugin documentation - plugin.xml - so I find it sufficient. Thank you for your help with review of this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740720#comment-17740720 ] ASF GitHub Bot commented on MJAVADOC-755: - elharo merged PR #209: URL: https://github.com/apache/maven-javadoc-plugin/pull/209 > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo merged pull request #209: [MJAVADOC-755] replace IOUtil.close with try with resources
elharo merged PR #209: URL: https://github.com/apache/maven-javadoc-plugin/pull/209 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740673#comment-17740673
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi opened a new pull request, #77:
URL: https://github.com/apache/maven-filtering/pull/77
Currently it could happen that the scanner misses changed files (because
they are not part of the delta) or copies files even if they have not changed
(e.g. because the output has changes).
This uses now a different approach, instead of only handling the delta
files, we scan all inputs and compare if they are up-to-date with the output.
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/MSHARED) 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 `[MSHARED-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MSHARED-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 -Prun-its` 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).
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-filtering] laeubi opened a new pull request, #77: MSHARED-1285 use an up-to-date scanner instead the newscanner
laeubi opened a new pull request, #77: URL: https://github.com/apache/maven-filtering/pull/77 Currently it could happen that the scanner misses changed files (because they are not part of the delta) or copies files even if they have not changed (e.g. because the output has changes). This uses now a different approach, instead of only handling the delta files, we scan all inputs and compare if they are up-to-date with the output. 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/MSHARED) 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 `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-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 -Prun-its` 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MASSEMBLY-994) Items from unpacked dependency are not refreshed
Slawomir Jaranowski created MASSEMBLY-994:
-
Summary: Items from unpacked dependency are not refreshed
Key: MASSEMBLY-994
URL: https://issues.apache.org/jira/browse/MASSEMBLY-994
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Slawomir Jaranowski
For assembly descriptor like:
{code:java}
dir
groupId:ArtifactId
true
{code}
Where {{groupId:ArtifactId}} comes from reactor build, even when content of
artifact was changed, items in destination directory contains old files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7835) Support for alternative POM syntaxes
[ https://issues.apache.org/jira/browse/MNG-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7835. Resolution: Duplicate > Support for alternative POM syntaxes > > > Key: MNG-7835 > URL: https://issues.apache.org/jira/browse/MNG-7835 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7531) Upgrade to SLF4J 2.0.0
[
https://issues.apache.org/jira/browse/MNG-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740669#comment-17740669
]
ASF GitHub Bot commented on MNG-7531:
-
kwin commented on PR #791:
URL: https://github.com/apache/maven/pull/791#issuecomment-1623875406
This is not necessarily about logging in Mojos, but about logging in Maven
Core itself and in transitive dependencies.
> Upgrade to SLF4J 2.0.0
> --
>
> Key: MNG-7531
> URL: https://issues.apache.org/jira/browse/MNG-7531
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> [https://www.slf4j.org/faq.html#changesInVersion200]
>
> Instead of "bindings" now {{org.slf4j.LoggerFactory}} searches for
> "providers". These ship for example with {_}slf4j-nop-2.0.x.jar{_},
> _slf4j-simple-2.0.x.jar_ or {_}slf4j-jdk14-2.0.x.jar{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] kwin commented on pull request #791: [MNG-7531] Upgrade to SLF4J 2.0.0
kwin commented on PR #791: URL: https://github.com/apache/maven/pull/791#issuecomment-1623875406 This is not necessarily about logging in Mojos, but about logging in Maven Core itself and in transitive dependencies. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] gnodet closed pull request #110: [MNG-7046] Revert MNG-5639 and make repo config static only
gnodet closed pull request #110: [MNG-7046] Revert MNG-5639 and make repo config static only URL: https://github.com/apache/maven-integration-testing/pull/110 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only (no ${param} interpolation)
[
https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740666#comment-17740666
]
ASF GitHub Bot commented on MNG-7046:
-
gnodet closed pull request #509: [MNG-7046] Revert MNG-5639 and make repo
config static only
URL: https://github.com/apache/maven/pull/509
> Revert MNG-5639 and make repo config static only (no ${param} interpolation)
>
>
> Key: MNG-7046
> URL: https://issues.apache.org/jira/browse/MNG-7046
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
> Labels: must-be-in-4.0.0-alpha-2
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> As discussed in MNG-5639 repositories should always be known upfront, they
> have to be static to avoid chicken and egg situations, a project should not
> influence settings. It should be the way around.
> In subsequent ticket it will be verified that repo configuration does not
> contain any expression:
> https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #509: [MNG-7046] Revert MNG-5639 and make repo config static only
gnodet closed pull request #509: [MNG-7046] Revert MNG-5639 and make repo config static only URL: https://github.com/apache/maven/pull/509 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet closed pull request #419: [MNG-4645] Move Central repo definition out of Maven's core so it can…
gnodet closed pull request #419: [MNG-4645] Move Central repo definition out of Maven's core so it can… URL: https://github.com/apache/maven/pull/419 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MASSEMBLY-966) Artifacts with classifiers are not included anymore
[
https://issues.apache.org/jira/browse/MASSEMBLY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MASSEMBLY-966.
-
Resolution: Duplicate
> Artifacts with classifiers are not included anymore
> ---
>
> Key: MASSEMBLY-966
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-966
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.4.0
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I just upgraded to 3.4.0 (from 3.3.0) and one of my dependencies with a
> classifier and supposed to be included is now skipped. I guess it's a
> consequence of MASSEMBLY-955.
> In the pom the dependency is declared with
> {code:xml}
>
> org.eclipse.jetty
> jetty-start
> 10.0.7
> shaded
> true
>
> {code}
> and assembly configuration looks like
> {code:xml}
>
> distribution
>
> zip
>
> false
>
>
> start.jar
> /jetty
>
> org.eclipse.jetty:jetty-start:jar:shaded
>
>
> [...]
>
> [...]
>
> {code}
> And I see the related warning in the log:
> {code:xml}
> [INFO] --- maven-assembly-plugin:3.4.0:single (default) @
> xwiki-platform-tool-jetty-resources ---
> [INFO] Reading assembly descriptor:
> /media/DATA/xwiki/sources/xwiki-platform/xwiki-platform-tools/xwiki-platform-tool-jetty/xwiki-platform-tool-jetty-resources/src/main/assembly/distribution.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'org.eclipse.jetty:jetty-start:jar:shaded'
> [WARNING] The following patterns were never triggered in this artifact
> exclusion filter:
> o 'org.eclipse.jetty:jetty-start:jar:shaded'
> {code}
> For more details the module can be found on
> https://github.com/xwiki/xwiki-platform/tree/xwiki-platform-14.5/xwiki-platform-tools/xwiki-platform-tool-jetty/xwiki-platform-tool-jetty-resources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only (no ${param} interpolation)
[
https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740658#comment-17740658
]
ASF GitHub Bot commented on MNG-7046:
-
michael-o commented on PR #509:
URL: https://github.com/apache/maven/pull/509#issuecomment-1623860750
@gnodet Is this superseded?
> Revert MNG-5639 and make repo config static only (no ${param} interpolation)
>
>
> Key: MNG-7046
> URL: https://issues.apache.org/jira/browse/MNG-7046
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
> Labels: must-be-in-4.0.0-alpha-2
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> As discussed in MNG-5639 repositories should always be known upfront, they
> have to be static to avoid chicken and egg situations, a project should not
> influence settings. It should be the way around.
> In subsequent ticket it will be verified that repo configuration does not
> contain any expression:
> https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-integration-testing] michael-o commented on pull request #110: [MNG-7046] Revert MNG-5639 and make repo config static only
michael-o commented on PR #110: URL: https://github.com/apache/maven-integration-testing/pull/110#issuecomment-1623861453 @gnodet Is this superseded? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
Christoph Läubrich created MSHARED-1285:
---
Summary: DefaultMavenResourcesFiltering uses BuildContext in a way
that fails sometimes
Key: MSHARED-1285
URL: https://issues.apache.org/jira/browse/MSHARED-1285
Project: Maven Shared Components
Issue Type: Bug
Reporter: Christoph Läubrich
The maven resources plugin uses
[https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
to copy resources, but that component has some subtile flaws reported here:
[https://github.com/eclipse-m2e/m2e-core/discussions/1468]
The problematic part is the usage of BuildContext#newScanner that already
mentions in the javadoc that passing ignoreDelta to neScanner might not reveal
all required items +*for copy-resources*+ form A -> B and instead
BuildContext#isUpTodate should be used.
Just from a quick look I assume that part of code actually wants to use
something like this:
{code:java}
DirectoryScanner ds = new DirectoryScanner() {
@Override
protected boolean isSelected(String name, File file) {
if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file)) {
return false;
}
return true;
}
};
ds.setBasedir(basedir); {code}
That way all the code that currently checks for if output directory existed
before can also be removed what is another issue because it leads to a full
resources copy even if source+target are already even if a single class file is
changed while the idea seems more that if the output was not there it should
not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSKINS-234) Disabling 'topBarEnabled' doesn't remove padding
[ https://issues.apache.org/jira/browse/MSKINS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-234. - Resolution: Fixed Fixed with [ad8e01be560b9367cba156c9f760901581c78b90|https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=ad8e01be560b9367cba156c9f760901581c78b90] and with [6091c5fe1fd4b088fa8c58995b752c9168296817|https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=6091c5fe1fd4b088fa8c58995b752c9168296817]. for 1.x. > Disabling 'topBarEnabled' doesn't remove padding > > > Key: MSKINS-234 > URL: https://issues.apache.org/jira/browse/MSKINS-234 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.11.2 >Reporter: Alexander Brandes >Assignee: Michael Osipov >Priority: Minor > Fix For: fluido-2.0.0-M7, fluido-1.12.0 > > Attachments: Kapture 2023-07-02 at 19.23.10.mp4, screenshot-1.png > > > Hey, > I was looking for a way to remove the padding from the top of the page. > Disabling 'topBarEnabled' doesn't remove the padding fully, it leaves > 'padding-top' set at 20px, enabling 'topBarEnabled' increases it to 60px. > Am I missing something, or can't I disable the padding at all? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSKINS-234) Disabling 'topBarEnabled' doesn't remove padding
[ https://issues.apache.org/jira/browse/MSKINS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740648#comment-17740648 ] ASF GitHub Bot commented on MSKINS-234: --- asfgit closed pull request #53: [MSKINS-234] Disabling 'topBarEnabled' doesn't remove padding URL: https://github.com/apache/maven-fluido-skin/pull/53 > Disabling 'topBarEnabled' doesn't remove padding > > > Key: MSKINS-234 > URL: https://issues.apache.org/jira/browse/MSKINS-234 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.11.2 >Reporter: Alexander Brandes >Assignee: Michael Osipov >Priority: Minor > Fix For: fluido-2.0.0-M7, fluido-1.12.0 > > Attachments: Kapture 2023-07-02 at 19.23.10.mp4, screenshot-1.png > > > Hey, > I was looking for a way to remove the padding from the top of the page. > Disabling 'topBarEnabled' doesn't remove the padding fully, it leaves > 'padding-top' set at 20px, enabling 'topBarEnabled' increases it to 60px. > Am I missing something, or can't I disable the padding at all? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7531) Upgrade to SLF4J 2.0.0
[
https://issues.apache.org/jira/browse/MNG-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740644#comment-17740644
]
ASF GitHub Bot commented on MNG-7531:
-
michael-o commented on PR #791:
URL: https://github.com/apache/maven/pull/791#issuecomment-1623825720
> > (but there is no new feature for users so really think we can skip it).
>
> I disagree here, https://slf4j.org/manual.html#fluent was added
We haven't even agree on the plugin log API...
> Upgrade to SLF4J 2.0.0
> --
>
> Key: MNG-7531
> URL: https://issues.apache.org/jira/browse/MNG-7531
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> [https://www.slf4j.org/faq.html#changesInVersion200]
>
> Instead of "bindings" now {{org.slf4j.LoggerFactory}} searches for
> "providers". These ship for example with {_}slf4j-nop-2.0.x.jar{_},
> _slf4j-simple-2.0.x.jar_ or {_}slf4j-jdk14-2.0.x.jar{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #791: [MNG-7531] Upgrade to SLF4J 2.0.0
michael-o commented on PR #791: URL: https://github.com/apache/maven/pull/791#issuecomment-1623825720 > > (but there is no new feature for users so really think we can skip it). > > I disagree here, https://slf4j.org/manual.html#fluent was added We haven't even agree on the plugin log API... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7531) Upgrade to SLF4J 2.0.0
[
https://issues.apache.org/jira/browse/MNG-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740641#comment-17740641
]
ASF GitHub Bot commented on MNG-7531:
-
kwin commented on PR #791:
URL: https://github.com/apache/maven/pull/791#issuecomment-1623811646
> (but there is no new feature for users so really think we can skip it).
I disagree here, https://slf4j.org/manual.html#fluent was added
> Upgrade to SLF4J 2.0.0
> --
>
> Key: MNG-7531
> URL: https://issues.apache.org/jira/browse/MNG-7531
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> [https://www.slf4j.org/faq.html#changesInVersion200]
>
> Instead of "bindings" now {{org.slf4j.LoggerFactory}} searches for
> "providers". These ship for example with {_}slf4j-nop-2.0.x.jar{_},
> _slf4j-simple-2.0.x.jar_ or {_}slf4j-jdk14-2.0.x.jar{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] kwin commented on pull request #791: [MNG-7531] Upgrade to SLF4J 2.0.0
kwin commented on PR #791: URL: https://github.com/apache/maven/pull/791#issuecomment-1623811646 > (but there is no new feature for users so really think we can skip it). I disagree here, https://slf4j.org/manual.html#fluent was added -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet opened a new pull request, #868: Revert to slf4j simple logger for the actual logging to the terminal (fixes #835)
gnodet opened a new pull request, #868: URL: https://github.com/apache/maven-mvnd/pull/868 (no comment) -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740628#comment-17740628 ] ASF GitHub Bot commented on MJAVADOC-755: - elharo opened a new pull request, #209: URL: https://github.com/apache/maven-javadoc-plugin/pull/209 (no comment) > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-193) API change: let MavenReportRenderer#render() throw an exception
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-193. -- Resolution: Fixed Fixed with [5f1556d497f492285f884bde0ac47ccb6f1e1ed7|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git=commit=5f1556d497f492285f884bde0ac47ccb6f1e1ed7]. Merged the change since it is an easy fix. > API change: let MavenReportRenderer#render() throw an exception > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Assignee: Michael Osipov >Priority: Major > Labels: doxia-2.0.0-stack > Fix For: maven-reporting-api-4.0.0-M7 > > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-193) API change: let MavenReportRenderer#render() throw an exception
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740624#comment-17740624 ] ASF GitHub Bot commented on MSHARED-193: asfgit closed pull request #18: [MSHARED-193] API change: let MavenReportRenderer#render() throw an e… URL: https://github.com/apache/maven-reporting-api/pull/18 > API change: let MavenReportRenderer#render() throw an exception > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Assignee: Michael Osipov >Priority: Major > Labels: doxia-2.0.0-stack > Fix For: maven-reporting-api-4.0.0-M7 > > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-193) API change: let MavenReportRenderer#render() throw an exception
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-193: --- Labels: (was: doxia-2.0.0-stack) > API change: let MavenReportRenderer#render() throw an exception > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0-M7 > > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-reporting-api] asfgit closed pull request #18: [MSHARED-193] API change: let MavenReportRenderer#render() throw an e…
asfgit closed pull request #18: [MSHARED-193] API change: let MavenReportRenderer#render() throw an e… URL: https://github.com/apache/maven-reporting-api/pull/18 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1032) API change: let MavenReport#canGenerateReport() throw an exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740622#comment-17740622
]
ASF GitHub Bot commented on MSHARED-1032:
-
asfgit closed pull request #17: [MSHARED-1032] API change: let
MavenReport#canGenerateReport() throw …
URL: https://github.com/apache/maven-reporting-api/pull/17
> API change: let MavenReport#canGenerateReport() throw an exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-api-4.0.0-M7
>
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1032) API change: let MavenReport#canGenerateReport() throw an exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-1032:
Labels: (was: doxia-2.0.0-stack)
> API change: let MavenReport#canGenerateReport() throw an exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-api-4.0.0-M7
>
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1032) API change: let MavenReport#canGenerateReport() throw an exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHARED-1032.
---
Resolution: Fixed
Fixed with
[06d224eea0ab19595ba2e1038b012ee55a272e35|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git=commit=06d224eea0ab19595ba2e1038b012ee55a272e35].
> API change: let MavenReport#canGenerateReport() throw an exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Assignee: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
> Fix For: maven-reporting-api-4.0.0-M7
>
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-reporting-api] asfgit closed pull request #17: [MSHARED-1032] API change: let MavenReport#canGenerateReport() throw …
asfgit closed pull request #17: [MSHARED-1032] API change: let MavenReport#canGenerateReport() throw … URL: https://github.com/apache/maven-reporting-api/pull/17 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740613#comment-17740613 ] ASF GitHub Bot commented on MJAVADOC-755: - elharo merged PR #208: URL: https://github.com/apache/maven-javadoc-plugin/pull/208 > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo merged pull request #208: [MJAVADOC-755] Use java.lang.String instead of StringUtils
elharo merged PR #208: URL: https://github.com/apache/maven-javadoc-plugin/pull/208 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-477) Don't add a stray period
[ https://issues.apache.org/jira/browse/MPLUGIN-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740606#comment-17740606 ] ASF GitHub Bot commented on MPLUGIN-477: michael-o opened a new pull request, #220: URL: https://github.com/apache/maven-plugin-tools/pull/220 This closes #220 > Don't add a stray period > > > Key: MPLUGIN-477 > URL: https://issues.apache.org/jira/browse/MPLUGIN-477 > Project: Maven Plugin Tools > Issue Type: Improvement >Affects Versions: 3.9.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.1 > > > Some output consists only of half a sentence (phrase), those should not be > completed with a period, similiar to Javadoc on parameters. Moreover 'is' is > not required when you use a colon. > > Similar to > [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-477) Don't add a stray period
[ https://issues.apache.org/jira/browse/MPLUGIN-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPLUGIN-477: --- Description: Some output consists only of half a sentence (phrase), those should not be completed with a period, similiar to Javadoc on parameters. Moreover 'is' is not required when you use a colon. Similar to: [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] was:Some output consists only of half a sentence (phrase), those should not be completed with a period, similiar to Javadoc on parameters. Moreover 'is' is not required when you use a colon. > Don't add a stray period > > > Key: MPLUGIN-477 > URL: https://issues.apache.org/jira/browse/MPLUGIN-477 > Project: Maven Plugin Tools > Issue Type: Improvement >Affects Versions: 3.9.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.1 > > > Some output consists only of half a sentence (phrase), those should not be > completed with a period, similiar to Javadoc on parameters. Moreover 'is' is > not required when you use a colon. > > Similar to: > [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-477) Don't add a stray period
[ https://issues.apache.org/jira/browse/MPLUGIN-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPLUGIN-477: --- Description: Some output consists only of half a sentence (phrase), those should not be completed with a period, similiar to Javadoc on parameters. Moreover 'is' is not required when you use a colon. Similar to [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] was: Some output consists only of half a sentence (phrase), those should not be completed with a period, similiar to Javadoc on parameters. Moreover 'is' is not required when you use a colon. Similar to: [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] > Don't add a stray period > > > Key: MPLUGIN-477 > URL: https://issues.apache.org/jira/browse/MPLUGIN-477 > Project: Maven Plugin Tools > Issue Type: Improvement >Affects Versions: 3.9.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.1 > > > Some output consists only of half a sentence (phrase), those should not be > completed with a period, similiar to Javadoc on parameters. Moreover 'is' is > not required when you use a colon. > > Similar to > [https://github.com/codehaus-plexus/modello/commit/f969dbf051ffc7fe2d5fc6169a0291ebde4b5a54] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-477) Don't add a stray period
Michael Osipov created MPLUGIN-477: -- Summary: Don't add a stray period Key: MPLUGIN-477 URL: https://issues.apache.org/jira/browse/MPLUGIN-477 Project: Maven Plugin Tools Issue Type: Improvement Affects Versions: 3.9.0 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.9.1 Some output consists only of half a sentence (phrase), those should not be completed with a period, similiar to Javadoc on parameters. Moreover 'is' is not required when you use a colon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740591#comment-17740591
]
ASF GitHub Bot commented on MNG-6829:
-
elharo merged PR #109:
URL: https://github.com/apache/maven-doxia-sitetools/pull/109
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: close-pending
> Fix For: 4.0.x-candidate
>
> Attachments: dtPKn.xlsx
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia-sitetools] elharo merged pull request #108: Bump junitVersion from 5.9.2 to 5.9.3
elharo merged PR #108: URL: https://github.com/apache/maven-doxia-sitetools/pull/108 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740582#comment-17740582
]
ASF GitHub Bot commented on MNG-6829:
-
timtebeek commented on PR #109:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/109#issuecomment-1623583796
@michael-o ; I know this might seem a silly small PR, but it would help to
see this one through before I move on to the next batch of phasing out the
various other utility method calls. Would you be able to review and merge this
one?
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: close-pending
> Fix For: 4.0.x-candidate
>
> Attachments: dtPKn.xlsx
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-assembly-plugin] elharo closed pull request #131: Refactored code for Maven Assembly Plugin. No code breaks, all test cases passing.
elharo closed pull request #131: Refactored code for Maven Assembly Plugin. No code breaks, all test cases passing. URL: https://github.com/apache/maven-assembly-plugin/pull/131 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[
https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740535#comment-17740535
]
ASF GitHub Bot commented on MJAVADOC-755:
-
michael-o commented on code in PR #208:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/208#discussion_r1254215004
##
src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java:
##
@@ -212,12 +211,12 @@ protected static String quotedArgument(String value) {
if (arg != null && !arg.isEmpty()) {
if (arg.contains("'")) {
-arg = StringUtils.replace(arg, "'", "\\'");
+arg = arg.replace("'", "\\'");
Review Comment:
Why not just replace? Isn't it cheap?
> Clean up deprecated and unpreferred methods in JavadocUtil
> --
>
> Key: MJAVADOC-755
> URL: https://issues.apache.org/jira/browse/MJAVADOC-755
> Project: Maven Javadoc Plugin
> Issue Type: Dependency upgrade
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled() and isInfoEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed MENFORCER-488.
-
> EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled()
> and isInfoEnabled()
> ---
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.0
>
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled() and isInfoEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MENFORCER-488.
---
Fix Version/s: 3.3.1
Resolution: Fixed
Fixed in
https://github.com/apache/maven-enforcer/commit/22ff3c78aac693fb419e332fa97c55c944daf7a5.
> EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled()
> and isInfoEnabled()
> ---
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.3.1
>
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740508#comment-17740508
]
ASF GitHub Bot commented on MENFORCER-488:
--
kwin merged PR #279:
URL: https://github.com/apache/maven-enforcer/pull/279
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled() and isInfoEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-488:
--
Summary: EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(),
isWarnEnabled() and isInfoEnabled() (was: EnforcerLogger: Provide
isDebugEnabled())
> EnforcerLogger: Provide isDebugEnabled(), isErrorEnabled(), isWarnEnabled()
> and isInfoEnabled()
> ---
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740497#comment-17740497
]
ASF GitHub Bot commented on MENFORCER-488:
--
kwin commented on PR #279:
URL: https://github.com/apache/maven-enforcer/pull/279#issuecomment-1623254717
> one missing `isWarnOrErrorEnabled`
I would prefer to leave that out, as the semantics is not clear from the
name. It could mean both
1. `isWarnEnabled() || isErrorEnabled()` or
2. `isWarnEnabled() && rule.getLevel() == EnforcerLevel.WARN ||
isErrorEnabled() && rule.getLevel() == EnforcerLevel.ERROR`
Although one could clarify that in the javadoc the chance for
misinterpretation is quite high and I would not add it until we see a real use
case.
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] kwin commented on pull request #279: [MENFORCER-488] Add EnforcerLogger.isDebugEnabled()
kwin commented on PR #279: URL: https://github.com/apache/maven-enforcer/pull/279#issuecomment-1623254717 > one missing `isWarnOrErrorEnabled` I would prefer to leave that out, as the semantics is not clear from the name. It could mean both 1. `isWarnEnabled() || isErrorEnabled()` or 2. `isWarnEnabled() && rule.getLevel() == EnforcerLevel.WARN || isErrorEnabled() && rule.getLevel() == EnforcerLevel.ERROR` Although one could clarify that in the javadoc the chance for misinterpretation is quite high and I would not add it until we see a real use case. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] hohwille commented on issue #867: mvnd slower than mvn
hohwille commented on issue #867: URL: https://github.com/apache/maven-mvnd/issues/867#issuecomment-1623245977 Thanks, sounds like some cool improvements have been done that are not yet released. Are there plans to publish a new milestone? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet merged pull request #1198: Javadoc fixes
gnodet merged PR #1198: URL: https://github.com/apache/maven/pull/1198 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
