[jira] [Created] (MWRAPPER-79) Automatically add sha256 to maven-wrapper.properties
Slawomir Jaranowski created MWRAPPER-79: --- Summary: Automatically add sha256 to maven-wrapper.properties Key: MWRAPPER-79 URL: https://issues.apache.org/jira/browse/MWRAPPER-79 Project: Maven Wrapper Issue Type: New Feature Reporter: Slawomir Jaranowski Even more for historical versions of wrapper and Maven distribution we can provide default sha256 in plugin, for never we should compute during installation / updating wrapper. Checksum provided by user should have priority. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-57) Make sure that Maven Wrapper created with distribution type set to script won't fail on Unix machines
[
https://issues.apache.org/jira/browse/MWRAPPER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MWRAPPER-57:
Fix Version/s: waiting-for-feedback
> Make sure that Maven Wrapper created with distribution type set to script
> won't fail on Unix machines
> -
>
> Key: MWRAPPER-57
> URL: https://issues.apache.org/jira/browse/MWRAPPER-57
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Reporter: Adam Gabrys
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> When the Maven {{wrapper:wrapper}} goal is executed with the
> {{-Dtype=script}} parameter the {{maven-wrapper.jar}} and
> {{MavenWrapperDownloader.java}} files are not created. The problem is that
> the {{mvnw.cmd}} script guarantees that the Maven distribution will be
> downloaded. However, the {{mvnw}} script fails when the {{curl}} and {{wget}}
> binaries are not installed. It may cause potential issues like "works on my
> PC, but fails on the {{CI}} system". The documentation doesn't Inform the
> users about that fact.
> I see a few possibilities to handle it:
> # remove the {{script}} option, then the people use {{bin}} or {{source}}.
> The {{source}} option generates the required {{MavenWrapperDownloader.java}}
> file
> # extend the {{script}} documentation with a warning that it may fail
> # generate different scripts depending on the chosen option - when {{script}}
> is not
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-57) Make sure that Maven Wrapper created with distribution type set to script won't fail on Unix machines
[
https://issues.apache.org/jira/browse/MWRAPPER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612792#comment-17612792
]
Slawomir Jaranowski commented on MWRAPPER-57:
-
Another proposition MWRAPPER-59 - inline {{MavenWrapperDownloader.java}} into
{{mvnw}} script.
> Make sure that Maven Wrapper created with distribution type set to script
> won't fail on Unix machines
> -
>
> Key: MWRAPPER-57
> URL: https://issues.apache.org/jira/browse/MWRAPPER-57
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Reporter: Adam Gabrys
>Priority: Minor
>
> When the Maven {{wrapper:wrapper}} goal is executed with the
> {{-Dtype=script}} parameter the {{maven-wrapper.jar}} and
> {{MavenWrapperDownloader.java}} files are not created. The problem is that
> the {{mvnw.cmd}} script guarantees that the Maven distribution will be
> downloaded. However, the {{mvnw}} script fails when the {{curl}} and {{wget}}
> binaries are not installed. It may cause potential issues like "works on my
> PC, but fails on the {{CI}} system". The documentation doesn't Inform the
> users about that fact.
> I see a few possibilities to handle it:
> # remove the {{script}} option, then the people use {{bin}} or {{source}}.
> The {{source}} option generates the required {{MavenWrapperDownloader.java}}
> file
> # extend the {{script}} documentation with a warning that it may fail
> # generate different scripts depending on the chosen option - when {{script}}
> is not
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-494) Clarify how to modify inheritance with attributes prefixed with "combine."
Konrad Windszus created MNGSITE-494:
---
Summary: Clarify how to modify inheritance with attributes
prefixed with "combine."
Key: MNGSITE-494
URL: https://issues.apache.org/jira/browse/MNGSITE-494
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Konrad Windszus
The merging options used for inheritance are only partially described within
https://maven.apache.org/pom.html#advanced_configuration_inheritance but in
fact apply everywhere (not only to plugin configuration). Also the attributes
{{combine.id}} and {{combine.keys}} used in
https://github.com/codehaus-plexus/plexus-utils/blob/7f5114af7d0c4d19838a9e0082758ec0f5e0269e/src/main/java/org/codehaus/plexus/util/xml/Xpp3DomUtils.java#L124
are not described at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-50) Verify checksum when downloading maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-50: Fix Version/s: waiting-for-feedback > Verify checksum when downloading maven-wrapper.jar > > > Key: MWRAPPER-50 > URL: https://issues.apache.org/jira/browse/MWRAPPER-50 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Premek Vyhnal >Priority: Major > Fix For: waiting-for-feedback > > > Hi, > Sorry if I just cannot find it > but it seems the checksum is not checked of the `maven-wrapper.jar` > downloaded here: > [https://github.com/apache/maven-wrapper/blob/efba2bde13feeabfb42e9dc120e8a35c127baf0d/maven-wrapper-distribution/src/resources/mvnw#L207] > > Checksum of the downloaded file should be checked before executing it to > avoid a remote code execution attack on the developer machine. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-50) Verify checksum when downloading maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612788#comment-17612788 ] Slawomir Jaranowski commented on MWRAPPER-50: - I hope that MWRAPPER-75 will resolve this issue. > Verify checksum when downloading maven-wrapper.jar > > > Key: MWRAPPER-50 > URL: https://issues.apache.org/jira/browse/MWRAPPER-50 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Premek Vyhnal >Priority: Major > > Hi, > Sorry if I just cannot find it > but it seems the checksum is not checked of the `maven-wrapper.jar` > downloaded here: > [https://github.com/apache/maven-wrapper/blob/efba2bde13feeabfb42e9dc120e8a35c127baf0d/maven-wrapper-distribution/src/resources/mvnw#L207] > > Checksum of the downloaded file should be checked before executing it to > avoid a remote code execution attack on the developer machine. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-45) Migrate/Sync startup scripts with Maven 4
[ https://issues.apache.org/jira/browse/MWRAPPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-45: Fix Version/s: waiting-for-feedback > Migrate/Sync startup scripts with Maven 4 > - > > Key: MWRAPPER-45 > URL: https://issues.apache.org/jira/browse/MWRAPPER-45 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > > The scripts are Maven 3 based. Maven 4 has simplified the scripts and > introduced consistency improvements. We should port those over for version 4?! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-70) Don't require a pom.xml
[ https://issues.apache.org/jira/browse/MWRAPPER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612784#comment-17612784 ] Slawomir Jaranowski commented on MWRAPPER-70: - Should be ok. > Don't require a pom.xml > --- > > Key: MWRAPPER-70 > URL: https://issues.apache.org/jira/browse/MWRAPPER-70 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Falko Modler >Priority: Major > Labels: up-for-grabs > > Occasionally, it would come in handy if you could run the wrapper goal > without a pom.xml to prepare a folder from scratch. > 3.1.1 fails with: "Goal requires a project to execute but there is no POM in > this directory" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-70) Don't require a pom.xml
[ https://issues.apache.org/jira/browse/MWRAPPER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-70: Labels: up-for-grabs (was: ) > Don't require a pom.xml > --- > > Key: MWRAPPER-70 > URL: https://issues.apache.org/jira/browse/MWRAPPER-70 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Falko Modler >Priority: Major > Labels: up-for-grabs > > Occasionally, it would come in handy if you could run the wrapper goal > without a pom.xml to prepare a folder from scratch. > 3.1.1 fails with: "Goal requires a project to execute but there is no POM in > this directory" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-45) Migrate/Sync startup scripts with Maven 4
[ https://issues.apache.org/jira/browse/MWRAPPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612783#comment-17612783 ] Slawomir Jaranowski commented on MWRAPPER-45: - I would like to promote script-only - direct calling mvn executable from target distribution. > Migrate/Sync startup scripts with Maven 4 > - > > Key: MWRAPPER-45 > URL: https://issues.apache.org/jira/browse/MWRAPPER-45 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Michael Osipov >Priority: Major > > The scripts are Maven 3 based. Maven 4 has simplified the scripts and > introduced consistency improvements. We should port those over for version 4?! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-33) Use java 8 in maven-wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MWRAPPER-33:
Labels: up-for-grabs (was: )
> Use java 8 in maven-wrapper
> ---
>
> Key: MWRAPPER-33
> URL: https://issues.apache.org/jira/browse/MWRAPPER-33
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Jar
>Affects Versions: 3.1.0
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> Currently {{maven-wrapper}} use java {*}5{*}.
> It blocks build project on java > 8.
> {{maven-wrapper-plugin}} require java 8, so we can use {{maven-wrapper}} with
> java 5 but we can't install it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MWRAPPER-16) update mvnw scripts to launch target Maven mvn scripts, to enforce consistency
[ https://issues.apache.org/jira/browse/MWRAPPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MWRAPPER-16. --- Assignee: Slawomir Jaranowski Resolution: Fixed I hope that was resolved in linked issue. > update mvnw scripts to launch target Maven mvn scripts, to enforce consistency > -- > > Key: MWRAPPER-16 > URL: https://issues.apache.org/jira/browse/MWRAPPER-16 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6, 3.1.0 >Reporter: Herve Boutemy >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > > currently, wrapper scripts copied to user project mimic Maven scripts (search > .mvn, and so on), then launch wrapper.jar: at the end, wrapper.jar calls > installed Maven distribution Classworlds bootstrap to run Maven Java code > this may cause a discrepency between features supported by mvnw script vs > what would have been done by installed Maven mvn scripts > for example, when/if [https://github.com/apache/maven/pull/602] is done > To enforce consistency, mvnw should launch installed Maven mvn script at the > end, and let it do its full work as if it had been launched -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-33) Use java 8 in maven-wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612779#comment-17612779
]
Slawomir Jaranowski commented on MWRAPPER-33:
-
I think we can go we it nowadays.
> Use java 8 in maven-wrapper
> ---
>
> Key: MWRAPPER-33
> URL: https://issues.apache.org/jira/browse/MWRAPPER-33
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Jar
>Affects Versions: 3.1.0
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Currently {{maven-wrapper}} use java {*}5{*}.
> It blocks build project on java > 8.
> {{maven-wrapper-plugin}} require java 8, so we can use {{maven-wrapper}} with
> java 5 but we can't install it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-78) Rewrite mvnw.cmd in PowerShell (mvnw.ps1)
[ https://issues.apache.org/jira/browse/MWRAPPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-78: Labels: up-for-grabs (was: ) > Rewrite mvnw.cmd in PowerShell (mvnw.ps1) > - > > Key: MWRAPPER-78 > URL: https://issues.apache.org/jira/browse/MWRAPPER-78 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Reporter: Jorge Solórzano >Priority: Normal > Labels: up-for-grabs > > More and more features in the Batch script for Windows are requiring > PowerShell, one feature is the web client to download the wrapper jar, and > the next one will be the sha256sum feature. > Batch scripting is showing its age and even Microsoft doesn't really want to > be used anymore, PowerShell 2.0 is integrated with Windows 7 and Windows > Server 2008 R2, and is released for Windows XP with Service Pack 3, Windows > Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1, it > would make sense to migrate the Batch script into PowerShell. > There is even a PowerShell Core version that could be installed on Linux, but > I'm not sure about the compatibility with older versions of Windows > PowerShell, one goal could be to make it compatible with Windows 7 and > higher, but honestly, I'm not sure if we should be supporting an OS that out > of support. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-78) Rewrite mvnw.cmd in PowerShell (mvnw.ps1)
[
https://issues.apache.org/jira/browse/MWRAPPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612775#comment-17612775
]
Slawomir Jaranowski commented on MWRAPPER-78:
-
Good idea especially for {{only-mvnw.cmd}} where more of code is in
{{PowerShell}}
> Rewrite mvnw.cmd in PowerShell (mvnw.ps1)
> -
>
> Key: MWRAPPER-78
> URL: https://issues.apache.org/jira/browse/MWRAPPER-78
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Scripts
>Reporter: Jorge Solórzano
>Priority: Normal
>
> More and more features in the Batch script for Windows are requiring
> PowerShell, one feature is the web client to download the wrapper jar, and
> the next one will be the sha256sum feature.
> Batch scripting is showing its age and even Microsoft doesn't really want to
> be used anymore, PowerShell 2.0 is integrated with Windows 7 and Windows
> Server 2008 R2, and is released for Windows XP with Service Pack 3, Windows
> Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1, it
> would make sense to migrate the Batch script into PowerShell.
> There is even a PowerShell Core version that could be installed on Linux, but
> I'm not sure about the compatibility with older versions of Windows
> PowerShell, one goal could be to make it compatible with Windows 7 and
> higher, but honestly, I'm not sure if we should be supporting an OS that out
> of support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1150) Support for PowerShell Maven executable
[
https://issues.apache.org/jira/browse/MSHARED-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MSHARED-1150:
-
Summary: Support for PowerShell Maven executable (was: Native support for
PowerShell Maven executable)
> Support for PowerShell Maven executable
> ---
>
> Key: MSHARED-1150
> URL: https://issues.apache.org/jira/browse/MSHARED-1150
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-invoker
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> Allow for detecting {{mvn}} executable as {{PowerShell}} script with
> extension {{.ps1}}
> We need a change in method: {{detectMavenExecutablePerOs}}
> in
> https://github.com/apache/maven-invoker/blob/master/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1150) Native support for PowerShell Maven executable
Slawomir Jaranowski created MSHARED-1150:
Summary: Native support for PowerShell Maven executable
Key: MSHARED-1150
URL: https://issues.apache.org/jira/browse/MSHARED-1150
Project: Maven Shared Components
Issue Type: New Feature
Components: maven-invoker
Reporter: Slawomir Jaranowski
Allow for detecting {{mvn}} executable as {{PowerShell}} script with extension
{{.ps1}}
We need a change in method: {{detectMavenExecutablePerOs}}
in
https://github.com/apache/maven-invoker/blob/master/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1150) Native support for PowerShell Maven executable
[
https://issues.apache.org/jira/browse/MSHARED-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MSHARED-1150:
-
Labels: up-for-grabs (was: )
> Native support for PowerShell Maven executable
> --
>
> Key: MSHARED-1150
> URL: https://issues.apache.org/jira/browse/MSHARED-1150
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-invoker
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> Allow for detecting {{mvn}} executable as {{PowerShell}} script with
> extension {{.ps1}}
> We need a change in method: {{detectMavenExecutablePerOs}}
> in
> https://github.com/apache/maven-invoker/blob/master/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7541) Native support for PowerShell to start Maven
[
https://issues.apache.org/jira/browse/MNG-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612641#comment-17612641
]
Michael Osipov commented on MNG-7541:
-
Those need to be reviewed:
{noformat}
$ grep -r --include='*.java' \\.cmd .
./plugins/tools/scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/BootstrapMojo.java:
String winMvnPath = mvnPath + ".cmd";
./shared/invoker/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:
File executableFile = new File( baseDirectory, executable + ".cmd"
);
{noformat}
I can take cake of Maven SCM, [~sjaranowski], do you want to address Invoker?
> Native support for PowerShell to start Maven
>
>
> Key: MNG-7541
> URL: https://issues.apache.org/jira/browse/MNG-7541
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.3
> Environment: windows 10 / 11
>Reporter: Jurrian Fahner
>Priority: Trivial
> Labels: Script, Windows10, Windows11
>
> Maven has two files in the bin dir:
> ||command||its use||
> |mvn|POSIX shell|
> |mvn.cmd|cmd.exe|
> On windows there are two ways to write scripts, by using cmd.exe or using
> powershell.
> If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first.
> If it doesn't find anything it will execute `mvn.cmd` as fall-back.
> When running maven for starting a server for development purposes and you do
> ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)?
> As far as I know it is default behaviour of cmd.exe.
> Well if I don't want to terminate, I wouldn't press ctrl-c. ;)
> It is not the case (as far as I know that Microsoft is going to deprecate
> cmd.exe in favor of powershell:
> [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/]
> Allthough I think it would be a good move for maven to have also a powershell
> script as well... It is possible to integrate elegant support for native help
> in powershell, `get-help mvn`.
> But it also increases the maintenance effort as well. I don't know whether
> this cost outweigh the benefits, though...
> By the way I would happy to contribute if it is appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7541) Native support for PowerShell to start Maven
[ https://issues.apache.org/jira/browse/MNG-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7541: Summary: Native support for PowerShell to start Maven (was: Native support for powershell to start maven) > Native support for PowerShell to start Maven > > > Key: MNG-7541 > URL: https://issues.apache.org/jira/browse/MNG-7541 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.8.3 > Environment: windows 10 / 11 >Reporter: Jurrian Fahner >Priority: Trivial > Labels: Script, Windows10, Windows11 > > Maven has two files in the bin dir: > ||command||its use|| > |mvn|POSIX shell| > |mvn.cmd|cmd.exe| > On windows there are two ways to write scripts, by using cmd.exe or using > powershell. > If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first. > If it doesn't find anything it will execute `mvn.cmd` as fall-back. > When running maven for starting a server for development purposes and you do > ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)? > As far as I know it is default behaviour of cmd.exe. > Well if I don't want to terminate, I wouldn't press ctrl-c. ;) > It is not the case (as far as I know that Microsoft is going to deprecate > cmd.exe in favor of powershell: > [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/] > Allthough I think it would be a good move for maven to have also a powershell > script as well... It is possible to integrate elegant support for native help > in powershell, `get-help mvn`. > But it also increases the maintenance effort as well. I don't know whether > this cost outweigh the benefits, though... > By the way I would happy to contribute if it is appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[
https://issues.apache.org/jira/browse/MENFORCER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-435:
--
Description: As the m-enforcer-p depends on Maven 3.2.5 (since
MENFORCER-419) all dependency resolutions should be done with Aether API
directly instead of leveraging
https://maven.apache.org/shared/maven-dependency-tree/. At the same time the
error message should be print the full path to the affected dependency instead
of forcing users to use a dedicated call of {{mvn dependency:tree}} to locate
the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
(was: As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-419) all
dependency resolutions should be done with Aether API directly instead of
leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the same
time the error message should be print the full path to the affected dependency
instead of forcing users to use a dedicated call of {{mvn dependency:tree}} to
locate the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111))
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> As the m-enforcer-p depends on Maven 3.2.5 (since MENFORCER-419) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should be print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[
https://issues.apache.org/jira/browse/MENFORCER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-435:
--
Description: As the m-enforcer-p depens on Maven 3.2.5 (since
MENFORCER-419) all dependency resolutions should be done with Aether API
directly instead of leveraging
https://maven.apache.org/shared/maven-dependency-tree/. At the same time the
error message should be print the full path to the affected dependency instead
of forcing users to use a dedicated call of {{mvn dependency:tree}} to locate
the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
(was: As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-325) all
dependency resolutions should be done with Aether API directly instead of
leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the same
time the error message should be print the full path to the affected dependency
instead of forcing users to use a dedicated call of {{mvn dependency:tree}} to
locate the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111))
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-419) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should be print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[
https://issues.apache.org/jira/browse/MENFORCER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-435:
--
Description: As the m-enforcer-p depens on Maven 3.2.5 (since
MENFORCER-325) all dependency resolutions should be done with Aether API
directly instead of leveraging
https://maven.apache.org/shared/maven-dependency-tree/. At the same time the
error message should be print the full path to the affected dependency instead
of forcing users to use a dedicated call of {{mvn dependency:tree}} to locate
the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
(was: As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-325) all
dependency resolutions should be done with Aether API directly instead of
leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the same
time the error message should be print the full path to the affected dependency
instead of forcing users to use a dedicated call of `mvn dependency:tree` to
locate the dependency
(https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111))
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-325) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should be print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-435) Get rid of maven-dependency-tree dependency
Konrad Windszus created MENFORCER-435: - Summary: Get rid of maven-dependency-tree dependency Key: MENFORCER-435 URL: https://issues.apache.org/jira/browse/MENFORCER-435 Project: Maven Enforcer Plugin Issue Type: Improvement Reporter: Konrad Windszus As the m-enforcer-p depens on Maven 3.2.5 (since MENFORCER-325) all dependency resolutions should be done with Aether API directly instead of leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the same time the error message should be print the full path to the affected dependency instead of forcing users to use a dedicated call of `mvn dependency:tree` to locate the dependency (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7558) The localRepository is invalid when I use 'mvn install'
[
https://issues.apache.org/jira/browse/MNG-7558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7558.
---
Resolution: Not A Bug
I don't see a bug or issue, you haven't provided necessary information. I
recommend to describe your problem to the users@ mailing list.
> The localRepository is invalid when I use 'mvn install'
> ---
>
> Key: MNG-7558
> URL: https://issues.apache.org/jira/browse/MNG-7558
> Project: Maven
> Issue Type: Bug
> Components: Maven Wrapper
>Affects Versions: 3.6.1
>Reporter: Jiangtao Guo
>Priority: Major
>
> I have set the localRepository in the d disk file 'setting.xml', but the
> localRepository is invalid when I use 'mvn install' in IDEA.
> Maven's official documents（ [https://maven.apache.org/settings.html] ）mention
> that the setting file has priority, but there is no setting file in my user
> directory.
> What should I do? The setting file is as follows:
> 我已经在d磁盘文件中设置了localRepository。但当我在IDEA中使用“mvn install”时，localRepository无效。
> Maven的官方文件（[https://maven.apache.org/settings.html]）提到设置文件具有优先级，但我的用户目录中没有'setting.xml'。
> 我应该怎么做，setting文件内容如下:
> {code:java}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> D:\ProgramFiles\maven3.6\repository
>
>
> aliyunmaven
> *
> 阿里云公共仓库
> https://maven.aliyun.com/repository/public
>
>
> aliyunmaven
> *
> 阿里云谷歌仓库
> https://maven.aliyun.com/repository/google
>
>
> aliyunmaven
> *
> 阿里云阿帕奇仓库
> https://maven.aliyun.com/repository/apache-snapshots
>
>
> aliyunmaven
> *
> 阿里云spring仓库
> https://maven.aliyun.com/repository/spring
>
>
> aliyunmaven
> *
> 阿里云spring插件仓库
> https://maven.aliyun.com/repository/spring-plugin
>
>
> jboss
> jboss
>
> https://repository.jboss.org/nexus/content/repositories/releases/
> JBoss Releases
>
>
> repo1
> central
> central repo
> http://repo1.maven.org/maven2/
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7558) The localRepository is invalid when I use 'mvn install'
[
https://issues.apache.org/jira/browse/MNG-7558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiangtao Guo updated MNG-7558:
--
Description:
I have set the localRepository in the d disk file 'setting.xml', but the
localRepository is invalid when I use 'mvn install' in IDEA.
Maven's official documents（ [https://maven.apache.org/settings.html] ）mention
that the setting file has priority, but there is no setting file in my user
directory.
What should I do? The setting file is as follows:
我已经在d磁盘文件中设置了localRepository。但当我在IDEA中使用“mvn install”时，localRepository无效。
Maven的官方文件（[https://maven.apache.org/settings.html]）提到设置文件具有优先级，但我的用户目录中没有'setting.xml'。
我应该怎么做，setting文件内容如下:
{code:java}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
D:\ProgramFiles\maven3.6\repository
aliyunmaven
*
阿里云公共仓库
https://maven.aliyun.com/repository/public
aliyunmaven
*
阿里云谷歌仓库
https://maven.aliyun.com/repository/google
aliyunmaven
*
阿里云阿帕奇仓库
https://maven.aliyun.com/repository/apache-snapshots
aliyunmaven
*
阿里云spring仓库
https://maven.aliyun.com/repository/spring
aliyunmaven
*
阿里云spring插件仓库
https://maven.aliyun.com/repository/spring-plugin
jboss
jboss
https://repository.jboss.org/nexus/content/repositories/releases/
JBoss Releases
repo1
central
central repo
http://repo1.maven.org/maven2/
{code}
was:
I have set the localRepository in the d disk file 'setting.xml', but the
localRepository is invalid when I use 'mvn install' in IDEA.
Maven's official documents（ https://maven.apache.org/settings.html ）mention
that the setting file has priority, but there is no setting file in my user
directory.
我已经在d磁盘文件中设置了localRepository。但当我在IDEA中使用“mvn install”时，localRepository无效。
Maven的官方文件（https://maven.apache.org/settings.html）提到设置文件具有优先级，但我的用户目录中没有'setting.xml'。
What should I do? The setting file is as follows:
我应该怎么做，setting文件内容如下:
{code:java}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
D:\ProgramFiles\maven3.6\repository
aliyunmaven
*
阿里云公共仓库
https://maven.aliyun.com/repository/public
aliyunmaven
*
阿里云谷歌仓库
https://maven.aliyun.com/repository/google
aliyunmaven
*
阿里云阿帕奇仓库
https://maven.aliyun.com/repository/apache-snapshots
aliyunmaven
*
阿里云spring仓库
https://maven.aliyun.com/repository/spring
aliyunmaven
*
阿里云spring插件仓库
https://maven.aliyun.com/repository/spring-plugin
jboss
jboss
https://repository.jboss.org/nexus/content/repositories/releases/
JBoss Releases
repo1
central
central repo
http://repo1.maven.org/maven2/
{code}
> The localRepository is invalid when I use 'mvn install'
> ---
>
> Key: MNG-7558
> URL: https://issues.apache.org/jira/browse/MNG-7558
> Project: Maven
> Issue Type: Bug
> Components: Maven Wrapper
>Affects Versions: 3.6.1
>Reporter: Jiangtao Guo
>Priority: Major
>
> I have set the localRepository in the d disk file 'setting.xml', but the
> localRepository is invalid when I use 'mvn install' in IDEA.
> Maven's official documents（ [https://maven.apache.org/settings.html] ）mention
> that the setting file has priority, but there is no setting file in my user
> directory.
> What should I do? The setting file is as follows:
> 我已经在d磁盘文件中设置了localRepository。但当我在IDEA中使用“mvn install”时，localRepository无效。
> Maven的官方文件（[https://maven.apache.org/settings.html]）提到设置文件具有优先级，但我的用户目录中没有'setting.xml'。
> 我应该怎么做，setting文件内容如下:
> {code:java}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
>
[jira] [Created] (MNG-7558) The localRepository is invalid when I use 'mvn install'
Jiangtao Guo created MNG-7558:
-
Summary: The localRepository is invalid when I use 'mvn install'
Key: MNG-7558
URL: https://issues.apache.org/jira/browse/MNG-7558
Project: Maven
Issue Type: Bug
Components: Maven Wrapper
Affects Versions: 3.6.1
Reporter: Jiangtao Guo
I have set the localRepository in the d disk file 'setting.xml', but the
localRepository is invalid when I use 'mvn install' in IDEA.
Maven's official documents（ https://maven.apache.org/settings.html ）mention
that the setting file has priority, but there is no setting file in my user
directory.
我已经在d磁盘文件中设置了localRepository。但当我在IDEA中使用“mvn install”时，localRepository无效。
Maven的官方文件（https://maven.apache.org/settings.html）提到设置文件具有优先级，但我的用户目录中没有'setting.xml'。
What should I do? The setting file is as follows:
我应该怎么做，setting文件内容如下:
{code:java}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
D:\ProgramFiles\maven3.6\repository
aliyunmaven
*
阿里云公共仓库
https://maven.aliyun.com/repository/public
aliyunmaven
*
阿里云谷歌仓库
https://maven.aliyun.com/repository/google
aliyunmaven
*
阿里云阿帕奇仓库
https://maven.aliyun.com/repository/apache-snapshots
aliyunmaven
*
阿里云spring仓库
https://maven.aliyun.com/repository/spring
aliyunmaven
*
阿里云spring插件仓库
https://maven.aliyun.com/repository/spring-plugin
jboss
jboss
https://repository.jboss.org/nexus/content/repositories/releases/
JBoss Releases
repo1
central
central repo
http://repo1.maven.org/maven2/
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[ https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612608#comment-17612608 ] Konrad Windszus edited comment on MNG-7529 at 10/4/22 12:53 PM: This fix is IMHO incorrectly filtering the results afterwards while it needs to prevent asking SNAPSHOT remote repositories for metadata.xml in the first place when resolving non-SNAPSHOT versions. Why can't we just set the correct nature in https://github.com/apache/maven/blob/ce4579108d653be2ab7eab43be7d5951151dae5b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L151 and filter out non-relevant remote repos in https://github.com/apache/maven/blob/ce4579108d653be2ab7eab43be7d5951151dae5b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L157-L163 in the first place? was (Author: kwin): This fix is IMHO incorrectly filtering the results afterwards while it needs to prevent asking SNAPSHOT remote repositories for metadata.xml in the first place when resolving non-SNAPSHOT versions. Why can't we just set the correct nature in https://github.com/apache/maven/blob/ce4579108d653be2ab7eab43be7d5951151dae5b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L151 in the first place? > Maven resolver makes bad repository choices when resolving version ranges > - > > Key: MNG-7529 > URL: https://issues.apache.org/jira/browse/MNG-7529 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: Henning Schmiedehausen >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > This is the same problem as MRESOLVER-270. The problem is actually in the > maven core, not in the resolver. See the description there. > > This bug is a placeholder for the fix PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[ https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612608#comment-17612608 ] Konrad Windszus commented on MNG-7529: -- This fix is IMHO incorrectly filtering the results afterwards while it needs to prevent asking SNAPSHOT remote repositories for metadata.xml in the first place when resolving non-SNAPSHOT versions. Why can't we just set the correct nature in https://github.com/apache/maven/blob/ce4579108d653be2ab7eab43be7d5951151dae5b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L151 in the first place? > Maven resolver makes bad repository choices when resolving version ranges > - > > Key: MNG-7529 > URL: https://issues.apache.org/jira/browse/MNG-7529 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: Henning Schmiedehausen >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > This is the same problem as MRESOLVER-270. The problem is actually in the > maven core, not in the resolver. See the description there. > > This bug is a placeholder for the fix PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7541) Native support for powershell to start maven
[
https://issues.apache.org/jira/browse/MNG-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612603#comment-17612603
]
Michael Osipov commented on MNG-7541:
-
I'd be in favor to review a PR. One issue is though that some of our components
might explicitly call {{mvn.cmd}}.
> Native support for powershell to start maven
>
>
> Key: MNG-7541
> URL: https://issues.apache.org/jira/browse/MNG-7541
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.3
> Environment: windows 10 / 11
>Reporter: Jurrian Fahner
>Priority: Trivial
> Labels: Script, Windows10, Windows11
>
> Maven has two files in the bin dir:
> ||command||its use||
> |mvn|POSIX shell|
> |mvn.cmd|cmd.exe|
> On windows there are two ways to write scripts, by using cmd.exe or using
> powershell.
> If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first.
> If it doesn't find anything it will execute `mvn.cmd` as fall-back.
> When running maven for starting a server for development purposes and you do
> ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)?
> As far as I know it is default behaviour of cmd.exe.
> Well if I don't want to terminate, I wouldn't press ctrl-c. ;)
> It is not the case (as far as I know that Microsoft is going to deprecate
> cmd.exe in favor of powershell:
> [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/]
> Allthough I think it would be a good move for maven to have also a powershell
> script as well... It is possible to integrate elegant support for native help
> in powershell, `get-help mvn`.
> But it also increases the maintenance effort as well. I don't know whether
> this cost outweigh the benefits, though...
> By the way I would happy to contribute if it is appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7557) Rewrite Batch scripts (*.cmd) in PowerShell (*.ps1)
[ https://issues.apache.org/jira/browse/MNG-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7557. --- Resolution: Duplicate > Rewrite Batch scripts (*.cmd) in PowerShell (*.ps1) > --- > > Key: MNG-7557 > URL: https://issues.apache.org/jira/browse/MNG-7557 > Project: Maven > Issue Type: Improvement >Reporter: Jorge Solórzano >Priority: Major > > Batch scripting is considered legacy and PowerShell provides improved > scripting that could help to have more maintainable scripts for Maven on > Windows. > PowerShell also has versions that run on Linux, so it could probably also > help to test the scripts without a windows machine. > The only drawback initially could be the lack of expertise with PowerShell, > but once the scripts are fully migrated they might not need a lot of changes. > It would be nice to have this for Maven 4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7557) Rewrite Batch scripts (*.cmd) in PowerShell (*.ps1)
Jorge Solórzano created MNG-7557: Summary: Rewrite Batch scripts (*.cmd) in PowerShell (*.ps1) Key: MNG-7557 URL: https://issues.apache.org/jira/browse/MNG-7557 Project: Maven Issue Type: Improvement Reporter: Jorge Solórzano Batch scripting is considered legacy and PowerShell provides improved scripting that could help to have more maintainable scripts for Maven on Windows. PowerShell also has versions that run on Linux, so it could probably also help to test the scripts without a windows machine. The only drawback initially could be the lack of expertise with PowerShell, but once the scripts are fully migrated they might not need a lot of changes. It would be nice to have this for Maven 4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MENFORCER-427) Rule for no version ranges
[ https://issues.apache.org/jira/browse/MENFORCER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned MENFORCER-427: - Assignee: Konrad Windszus > Rule for no version ranges > -- > > Key: MENFORCER-427 > URL: https://issues.apache.org/jira/browse/MENFORCER-427 > Project: Maven Enforcer Plugin > Issue Type: New Feature >Reporter: Simon >Assignee: Konrad Windszus >Priority: Major > > In order to create a reproducible build, it could make sense to fix all > version of direct and indirect dependency. > This can be done adding this in > It could be great to add a rules to ensure that all dependency version are > fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612461#comment-17612461 ] Herve Boutemy edited comment on MASSEMBLY-941 at 10/4/22 8:41 AM: -- if the issue was introduced in MASSEMBLY-921, it was not intentional: as written in issue description, it was about order and timestamp, not permissions perhaps there was some permissions changes included that I was not aware of we'll need to find where the change was done Edit: now I see that I did the changes, sorry... was (Author: hboutemy): if the issue was introduced in MASSEMBLY-921, it was not intentional: as written in issue description, it was about order and timestamp, not permissions perhaps there was some permissions changes included that I was not aware of we'll need to find where the change was done > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612526#comment-17612526 ] Herve Boutemy commented on MASSEMBLY-941: - second thoughts > perhaps we could store in the archive the same permissions for group and > other than user? read and execute permissions look ok write permission not ok: I don't want other write, and I don't know what's best for group > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612522#comment-17612522 ] Herve Boutemy commented on MASSEMBLY-941: - ok, now I start to remember the compromises I had to do both for UID/GID and file/dir permissions in tar archives in https://github.com/codehaus-plexus/plexus-archiver/pull/121 UID/GID seems ok, nobody complains but file/dir permission is not ok: IIRC, the issue I got is variation based on user's umask on Unixes = user/group/other user permissions are ok, but group and other may differ based on umask idea: instead of ignoring file permissions, perhaps we could store in the archive the same permissions for group and other than user? WDYT? [~plamenttv] we had a small discussion on these file permissions in https://github.com/codehaus-plexus/plexus-archiver/pull/121 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Piotr Zygielo edited comment on MASSEMBLY-941 at 10/4/22 8:32 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 https://github.com/codehaus-plexus/plexus-archiver/pull/121#discussion_r331805108: > This can be quite inconvenient if the archive contains executable scripts > (not uncommon for Java applications). https://github.com/codehaus-plexus/plexus-archiver/pull/121#discussion_r334241220: > yes, executable bit is the most wanted one. was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MASSEMBLY-921) Reproducible Builds: make entries in output archive reproducible (order + timestamp)
[ https://issues.apache.org/jira/browse/MASSEMBLY-921 ] Herve Boutemy deleted comment on MASSEMBLY-921: - was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven-assembly-plugin » master #24 See https://builds.apache.org/job/maven-box/job/maven-assembly-plugin/job/master/24/ > Reproducible Builds: make entries in output archive reproducible (order + > timestamp) > > > Key: MASSEMBLY-921 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-921 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: maven-archiver >Affects Versions: 3.1.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.0 > > > see Maven Reproducible Builds: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > in addition to expected order and timestamp work, we had also to update > UID/GID in tar files and file+directory permissions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7457 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7457/2/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9. Output:
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build succeeded in Jenkins: Maven TLP » maven » MNG-6829 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6829/15/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9. Output:
> │ │┄
> │ │ @@
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build succeeded in Jenkins: Maven TLP » maven » master #368
See https://builds.apache.org/job/maven-box/job/maven/job/master/368/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9. Output:
> │ │┄
> │ │ @@
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build succeeded in Jenkins: Maven TLP » maven » MNG-5868 #51
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/51/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9. Output:
> │ │┄
> │ │ @@
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build failed in Jenkins: Maven TLP » maven-studies » maven-metrics #4
See
https://builds.apache.org/job/maven-box/job/maven-studies/job/maven-metrics/4/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9.
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #33
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/33/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9.
[jira] (MNG-6859) Build not easily reproducible when built from source release archive
[ https://issues.apache.org/jira/browse/MNG-6859 ]
Herve Boutemy deleted comment on MNG-6859:
was (Author: hudson):
Build succeeded in Jenkins: Maven TLP » maven » MNG-6656 #42
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/42/
> Build not easily reproducible when built from source release archive
>
>
> Key: MNG-6859
> URL: https://issues.apache.org/jira/browse/MNG-6859
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap Build, General
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0-alpha-1, 4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When build from the source tarball, we don't have Git revision information
> which means the non-canonical tag with a timestamp is used. This breaks
> reproducibility, or at least makes reproducibility harder: you have to add a
> command line argument {{-DbuildNumber=...git commit...}}, as explained in
> 3.6.3 release notes [https://maven.apache.org/docs/3.6.3/release-notes.html]
>
> Before patch:
> {noformat}
> [~/Projekte/maven]$ git clone ...
> [~/Projekte/maven]$ mvn clean package -Papache-release
> [~/Projekte/maven]$ cp
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-src.tar.gz ~
> [~]$ tar xzf apache-maven-3.7.0-SNAPSHOT-src.tar.gz
> [~]$ cd apache-maven-3.7.0-SNAPSHOT/
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> [~/apache-maven-3.7.0-SNAPSHOT]$ mvn clean package
> [~/apache-maven-3.7.0-SNAPSHOT]$ mv
> apache-maven/target/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz
> ~/apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> [~/apache-maven-3.7.0-SNAPSHOT]$ cd
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1) =
> a38ea894346edea14cde621dfe11d5d82e0a9330e430c1fe0538f67581057001
> [~]$ sha256 apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> SHA256 (apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2) =
> 404798fc51cbcfa6201e23f0e215c6d9d43aeeea0c4383a9cf5e4a0b443e4a21
> [~]$ diffoscope apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1
> +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2
> │ --- apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.1-content
> ├── +++ apache-maven-3.7.0-SNAPSHOT-bin.tar.gz.2-content
> │ ├── file list
> │ │ @@ -71,15 +71,15 @@
> │ │ -rw-r--r-- 0 root (0) root (0) 2497 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/javax.inject-1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 5848 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/jsr250-api-1.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 263253 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-utils-3.3.0.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27703 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 13350 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 41424 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/slf4j-api-1.7.29.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 501879 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/commons-lang3-3.8.1.jar
> │ │ --rw-r--r-- 0 root (0) root (0) 631758 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ +-rw-r--r-- 0 root (0) root (0) 631756 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 27163 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-repository-metadata-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 57769 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-artifact-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 66243 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-provider-3.7.0-SNAPSHOT.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 180696 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-impl-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 36732 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/maven-resolver-spi-1.4.1.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 379197 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.4.jar
> │ │ -rw-r--r-- 0 root (0) root (0) 4225 2019-11-07 12:32:18.00
> apache-maven-3.7.0-SNAPSHOT/lib/plexus-component-annotations-2.1.0.jar
> │ ├── apache-maven-3.7.0-SNAPSHOT/lib/maven-core-3.7.0-SNAPSHOT.jar
> │ │┄ Command `zipinfo /dev/stdin` exited with 9. Output:
> │ │┄
> │ │ @@
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » MNG-6071 #33 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6071/33/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » MNG-5868 #51 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/51/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build failed in Jenkins: Maven TLP » maven-studies » maven-metrics #4 See https://builds.apache.org/job/maven-box/job/maven-studies/job/maven-metrics/4/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-921) Reproducible Builds: make entries in output archive reproducible (order + timestamp)
[ https://issues.apache.org/jira/browse/MASSEMBLY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MASSEMBLY-921: Description: see Maven Reproducible Builds: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 in addition to expected order and timestamp work, we had also to update UID/GID in tar files and file+directory permissions was:see Maven Reproducible Builds: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > Reproducible Builds: make entries in output archive reproducible (order + > timestamp) > > > Key: MASSEMBLY-921 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-921 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: maven-archiver >Affects Versions: 3.1.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.0 > > > see Maven Reproducible Builds: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > in addition to expected order and timestamp work, we had also to update > UID/GID in tar files and file+directory permissions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/3/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » master #300 See https://builds.apache.org/job/maven-box/job/maven/job/master/300/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » reproducible #56 See https://builds.apache.org/job/maven-box/job/maven/job/reproducible/56/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #23 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/23/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789 ] Herve Boutemy deleted comment on MNG-6789: was (Author: hudson): Build succeeded in Jenkins: Maven TLP » maven » reproducible #55 See https://builds.apache.org/job/maven-box/job/maven/job/reproducible/55/ > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509731#comment-17509731 ] Herve Boutemy edited comment on MASSEMBLY-941 at 10/4/22 8:05 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 https://github.com/codehaus-plexus/plexus-archiver/pull/121 was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 https://github.com/codehaus-plexus/plexus-archiver/commit/98940db17e3e55ee69646a8b46510f6d1ecad800 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7556) Clean up notion between user properties and system properties
[
https://issues.apache.org/jira/browse/MNG-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7556:
Description:
For a very long time we have documented that the user can set system properties
via {{mvn -Dfoo=bar}}, but actually those are user properties which are
promoted to system properties and it some cases system properties cannot be
modified *after* the JVM has been started. To properly set system properties
there are basically two ways:
* use {{MAVEN_OPTS}} environment variable
* use {{.mvn/jvm.config}} file
A third option in the future we could introduce, like other Java tools, a
{{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
was:
For a very long time we have documented that the user can set system properties
via {{mvn -Dfoo=bar}}, but actually those are user properties which are
promoted to system properties and it some cases system properties cannot be
modified **after** the JVM has been started. To properly set system properties
there are basically two ways:
* use {{MAVEN_OPTS}} environment variable
* use {{.mvn/jvm.config}} file
A third option in the future we could introduce, like other Java tools, a
{{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
> Clean up notion between user properties and system properties
> -
>
> Key: MNG-7556
> URL: https://issues.apache.org/jira/browse/MNG-7556
> Project: Maven
> Issue Type: Task
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
>
> For a very long time we have documented that the user can set system
> properties via {{mvn -Dfoo=bar}}, but actually those are user properties
> which are promoted to system properties and it some cases system properties
> cannot be modified *after* the JVM has been started. To properly set system
> properties there are basically two ways:
> * use {{MAVEN_OPTS}} environment variable
> * use {{.mvn/jvm.config}} file
> A third option in the future we could introduce, like other Java tools, a
> {{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7556) Clean up notion between user properties and system properties
[
https://issues.apache.org/jira/browse/MNG-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7556:
Description:
For a very long time we have documented that the user can set system properties
via {{mvn -Dfoo=bar}}, but actually those are user properties which are
promoted to system properties and it some cases system properties cannot be
modified **after** the JVM has been started. To properly set system properties
there are basically two ways:
* use {{MAVEN_OPTS}} environment variable
* use {{.mvn/jvm.config}} file
A third option in the future we could introduce, like other Java tools, a
{{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
was:
For a very long time we have documented that the user can set system properties
via {{mvn -Dfoo=bar}}, but actually those are user properties which are
promoted to system properties and it some cases system properties cannot be
modified **after* the JVM has been started. To properly set system properties
there are basically two ways:
* use {{MAVEN_OPTS}} environment variable
* use {{.mvn/jvm.config}} file
A third option in the future we could introduce, like other Java tools, a
{{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
> Clean up notion between user properties and system properties
> -
>
> Key: MNG-7556
> URL: https://issues.apache.org/jira/browse/MNG-7556
> Project: Maven
> Issue Type: Task
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
>
> For a very long time we have documented that the user can set system
> properties via {{mvn -Dfoo=bar}}, but actually those are user properties
> which are promoted to system properties and it some cases system properties
> cannot be modified **after** the JVM has been started. To properly set system
> properties there are basically two ways:
> * use {{MAVEN_OPTS}} environment variable
> * use {{.mvn/jvm.config}} file
> A third option in the future we could introduce, like other Java tools, a
> {{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1141) ForkedLauncher#run() uses a misconception of JAVA_HOME
[
https://issues.apache.org/jira/browse/MSHARED-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612496#comment-17612496
]
Hudson commented on MSHARED-1141:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-verifier » master #54
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-verifier/job/master/54/
> ForkedLauncher#run() uses a misconception of JAVA_HOME
> --
>
> Key: MSHARED-1141
> URL: https://issues.apache.org/jira/browse/MSHARED-1141
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-verifier
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-verifier-next
>
>
> The code does:
> {noformat}
> if ( envVars == null || envVars.get( "JAVA_HOME" ) == null )
> {
> cmd.addEnvironment( "JAVA_HOME", System.getProperty( "java.home" ) );
> } {noformat}
> This is logically wrong because {{java.home}} is not {{{}JAVA_HOME{}}}.
> {{java.home}} points to the JRE directory which can or cannot be the
> {{{}JAVA_HOME{}}}. This block can be removed all together and shall be eiher
> inherited or provided by the client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1141) ForkedLauncher#run() uses a misconception of JAVA_HOME
[
https://issues.apache.org/jira/browse/MSHARED-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHARED-1141.
---
Resolution: Fixed
Fixed with
[cbad3daf3e0befc5f212589e9ba8109712dae5be|https://gitbox.apache.org/repos/asf?p=maven-verifier.git=commit=cbad3daf3e0befc5f212589e9ba8109712dae5be].
> ForkedLauncher#run() uses a misconception of JAVA_HOME
> --
>
> Key: MSHARED-1141
> URL: https://issues.apache.org/jira/browse/MSHARED-1141
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-verifier
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-verifier-next
>
>
> The code does:
> {noformat}
> if ( envVars == null || envVars.get( "JAVA_HOME" ) == null )
> {
> cmd.addEnvironment( "JAVA_HOME", System.getProperty( "java.home" ) );
> } {noformat}
> This is logically wrong because {{java.home}} is not {{{}JAVA_HOME{}}}.
> {{java.home}} points to the JRE directory which can or cannot be the
> {{{}JAVA_HOME{}}}. This block can be removed all together and shall be eiher
> inherited or provided by the client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7556) Clean up notion between user properties and system properties
[
https://issues.apache.org/jira/browse/MNG-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612494#comment-17612494
]
Michael Osipov commented on MNG-7556:
-
Agree, but the current state is incorrect. Not only your cleanup is necessary,
but also the introduction of {{#setUserPropert...(...)}}. This will make it
clean and properly replicate real life.
> Clean up notion between user properties and system properties
> -
>
> Key: MNG-7556
> URL: https://issues.apache.org/jira/browse/MNG-7556
> Project: Maven
> Issue Type: Task
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
>
> For a very long time we have documented that the user can set system
> properties via {{mvn -Dfoo=bar}}, but actually those are user properties
> which are promoted to system properties and it some cases system properties
> cannot be modified **after* the JVM has been started. To properly set system
> properties there are basically two ways:
> * use {{MAVEN_OPTS}} environment variable
> * use {{.mvn/jvm.config}} file
> A third option in the future we could introduce, like other Java tools, a
> {{-J-Dfoo=bar}} option with the restriction of the the paragraph above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1132) Improved handling of system and user properties
[
https://issues.apache.org/jira/browse/MSHARED-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-1132:
Summary: Improved handling of system and user properties (was: Improved
handling of system properties)
> Improved handling of system and user properties
> ---
>
> Key: MSHARED-1132
> URL: https://issues.apache.org/jira/browse/MSHARED-1132
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-verifier
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-verifier-2.0.0
>
>
> In embedded mode system properties are overridden by values provided by user
> in current JVM, but some of properties can be read only
> https://bugs.openjdk.org/browse/JDK-8206908
> In fork mode system properties are provided as Maven user properties,
> should be add to {{MAVEN_OPTS}} environment variable.
> Because one correct place for system properties is {{MAVEN_OPTS}} we should
> force forked mode when system properties are set.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MEAR-318) Require Maven 3.2.5
Slawomir Jaranowski created MEAR-318: Summary: Require Maven 3.2.5 Key: MEAR-318 URL: https://issues.apache.org/jira/browse/MEAR-318 Project: Maven EAR Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
