[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734376#comment-14734376
]
ASF GitHub Bot commented on MNG-5837:
-
Github user birkedal commented on the pull request:
https://github.com/apache/maven/pull/50#issuecomment-138463968
It works just fine after the switch to backticks :+1:
I have no opinion on whether that other idiom is better or not.
One more little detail; if JAVA_HOME is not set I get `mvn: !: not found`
from the exclamation mark in the test on line 175. I would guess the same
applies for lines 144 and 147 as well.
> Syntax error in bin/mvn on Solaris SPARC
>
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `('
> unexpected{code}
> Looks like similas issues as in MNG-5658
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WAGON-444) Enable possibility to use MS Windows keystore as source for intermediate CA certs
Andreas Sandberg created WAGON-444: -- Summary: Enable possibility to use MS Windows keystore as source for intermediate CA certs Key: WAGON-444 URL: https://issues.apache.org/jira/browse/WAGON-444 Project: Maven Wagon Issue Type: Improvement Components: wagon-http Affects Versions: 2.9 Environment: Windows Reporter: Andreas Sandberg Priority: Minor Using Maven against an Artifactory instance configured with https (SSL). The problem is that the certificate is signed by our internal CA which forces us to import the CA cert into the cacerts file in Java. The CA certs are distributed to our Windows platform and are available using the Microsoft CryptoAPI support introduced in Java SE6. It would be really nice if Maven somehow could access the intermediate CAs from Windows keystores since Maven is Java based (as described in http://stackoverflow.com/questions/5476974/java-access-to-intermediate-cas-from-windows-keystores). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-444) Enable possibility to use MS Windows keystore as source for intermediate CA certs
[ https://issues.apache.org/jira/browse/WAGON-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734705#comment-14734705 ] Michael Osipov commented on WAGON-444: -- This should be, first and foremost, tried with Apache HttpClient. If that works, this is a snap in Wagon. Did you try already? > Enable possibility to use MS Windows keystore as source for intermediate CA > certs > - > > Key: WAGON-444 > URL: https://issues.apache.org/jira/browse/WAGON-444 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http >Affects Versions: 2.9 > Environment: Windows >Reporter: Andreas Sandberg >Priority: Minor > Labels: newbie > > Using Maven against an Artifactory instance configured with https (SSL). The > problem is that the certificate is signed by our internal CA which forces us > to import the CA cert into the cacerts file in Java. > The CA certs are distributed to our Windows platform and are available using > the Microsoft CryptoAPI support introduced in Java SE6. > It would be really nice if Maven somehow could access the intermediate CAs > from Windows keystores since Maven is Java based (as described in > http://stackoverflow.com/questions/5476974/java-access-to-intermediate-cas-from-windows-keystores). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WAGON-444) Enable possibility to use MS Windows keystore as source for intermediate CA certs
[ https://issues.apache.org/jira/browse/WAGON-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734705#comment-14734705 ] Michael Osipov edited comment on WAGON-444 at 9/8/15 12:06 PM: --- This should be, first and foremost, tried with Apache HttpClient (the default HTTP transport). If that works, this is a snap in Wagon. Did you try already? was (Author: michael-o): This should be, first and foremost, tried with Apache HttpClient. If that works, this is a snap in Wagon. Did you try already? > Enable possibility to use MS Windows keystore as source for intermediate CA > certs > - > > Key: WAGON-444 > URL: https://issues.apache.org/jira/browse/WAGON-444 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http >Affects Versions: 2.9 > Environment: Windows >Reporter: Andreas Sandberg >Priority: Minor > Labels: newbie > > Using Maven against an Artifactory instance configured with https (SSL). The > problem is that the certificate is signed by our internal CA which forces us > to import the CA cert into the cacerts file in Java. > The CA certs are distributed to our Windows platform and are available using > the Microsoft CryptoAPI support introduced in Java SE6. > It would be really nice if Maven somehow could access the intermediate CAs > from Windows keystores since Maven is Java based (as described in > http://stackoverflow.com/questions/5476974/java-access-to-intermediate-cas-from-windows-keystores). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735493#comment-14735493 ] Nicolas Juneau commented on MNG-5728: - All the repositories defined in my configuration now have a default checksum policy of "fail". This, however, cannot cover projects who define their own without specifying their checksum policies. I also configured Eclipse so that the default checksum policy for it is also "fail". As for the local Nexus, while it would be a good idea to set it there, not everyone can deploy a local Nexus repository on their machines or operate in an organization which provides one. That is why I brought this as an issue for Maven. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735382#comment-14735382 ] ASF GitHub Bot commented on MNG-5728: - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/36#issuecomment-138667695 Kindly squash your commits into one and bring it in sync with current master. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735383#comment-14735383 ] Michael Osipov commented on MNG-5728: - Have you considered to set the appropriate configs and your local Nexus instance? In this case Nexus will refuse to serve the broken artifact. I agree with you that Maven should fail with broken artifacts. You might want to raise this issue with the OSSRH mailing list to see how they cope with such problem. It would a resolve dicision for this issue way easier. Feel free to nag me when 3.4 is around. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735506#comment-14735506 ] Nicolas Juneau commented on MNG-5728: - In case you are wondering how I came into experiencing this issue, I don't have the specific artifacts that were corrupted (it's been almost a year - I don't quite recall which ones were failing). I became aware of the corrupt artifacts because I was having build failures where others did not (using the same code base and compiler). It was after a bit of investigation that I realized that some developers were not always setting their checksum policy in their settings. Since, like I said, Maven produces a lot of output or, in case of builds managed by m2e, almost none, it was pretty easy to miss the fact that some potentially corrupted artifacts were used in builds. Newer, intact versions of artifacts were produced upstream so we didn't have to do any special configuration on our side to fix the problem, but if it wasn't of careful examination of the output logs, this could easily have gone without notice. I now strongly recommend to alias "mvn" to "mvn -C" and set the checksum policy to fail in order to prevent that kind of problems. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735388#comment-14735388 ] Michael Osipov commented on MNG-5728: - I am not experiencing this issue. Nicolas obviously is. I will always handle this via a third-party repo in our local Nexus instance. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735380#comment-14735380 ] Mirko Friedenhagen commented on MNG-5728: - Hello Michael, I would recommend: * open an issue at OSSRH * download and check the corrupt artifacts and either * install them to your local cache or * deploy them to your local repository manager. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MANTTASKS-201) artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false
[
https://issues.apache.org/jira/browse/MANTTASKS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt McHenry reopened MANTTASKS-201:
A complete build file for reference:
{code:xml}
{code}
The same exception is produced:
{noformat}
$ M2_HOME=/usr/share/maven ant -Dmvn.goal=-version mvn.invoke
Buildfile: /home/mmchenry/tmp/maven-ant-bug/build.xml
mvn.invoke:
[artifact:mvn] Apache Maven 3.0.5
[artifact:mvn] Maven home: /usr/share/maven
[artifact:mvn] Java version: 1.8.0_45, vendor: Oracle Corporation
[artifact:mvn] Java home: /usr/lib/jvm/java-8-oracle/jre
[artifact:mvn] Default locale: en_US, platform encoding: UTF-8
[artifact:mvn] OS name: "linux", version: "3.13.0-57-generic", arch: "amd64",
family: "unix"
[artifact:mvn] org.apache.tools.ant.ExitException: Permission
("java.lang.RuntimePermission" "exitVM") was not granted.
[artifact:mvn] at
org.apache.tools.ant.types.Permissions$MySM.checkExit(Permissions.java:193)
[artifact:mvn] at java.lang.Runtime.exit(Runtime.java:107)
[artifact:mvn] at java.lang.System.exit(System.java:971)
[artifact:mvn] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:358)
[artifact:mvn] at org.codehaus.classworlds.Launcher.main(Launcher.java:46)
[artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[artifact:mvn] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[artifact:mvn] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:497)
[artifact:mvn] at
org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
[artifact:mvn] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
[artifact:mvn] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
[artifact:mvn] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
[artifact:mvn] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
[artifact:mvn] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
[artifact:mvn] at org.apache.maven.artifact.ant.Mvn.execute(Mvn.java:91)
[artifact:mvn] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[artifact:mvn] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[artifact:mvn] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:497)
[artifact:mvn] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[artifact:mvn] at org.apache.tools.ant.Task.perform(Task.java:348)
[artifact:mvn] at org.apache.tools.ant.Target.execute(Target.java:435)
[artifact:mvn] at org.apache.tools.ant.Target.performTasks(Target.java:456)
[artifact:mvn] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
[artifact:mvn] at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
[artifact:mvn] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[artifact:mvn] at
org.apache.tools.ant.Project.executeTargets(Project.java:1248)
[artifact:mvn] at org.apache.tools.ant.Main.runBuild(Main.java:851)
[artifact:mvn] at org.apache.tools.ant.Main.startAnt(Main.java:235)
[artifact:mvn] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
[artifact:mvn] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
[artifact:mvn] Java Result: 100
BUILD SUCCESSFUL
Total time: 0 seconds
{noformat}
> artifact:mvn generates "org.apache.tools.ant.ExitException: Permission
> (java.lang.RuntimePermission exitVM) was not granted" when fork=false
>
>
> Key: MANTTASKS-201
> URL: https://issues.apache.org/jira/browse/MANTTASKS-201
> Project: Maven Ant Tasks
> Issue Type: Bug
> Components: mvn task
>Affects Versions: 2.1.1
>Reporter: Matt McHenry
>Priority: Minor
>
> Using this simple ant target:
> {code:xml}
>
>
>
>
> {code}
> I get the correct behaviour:
> {noformat}
> $ M2_HOME=`cygpath -w "$M2_HOME"` ant -Dmvn.goal=-version mvn.invoke
> Searching for build.xml ...
> Buildfile: c:\Users\mmchenry\svn\cli\trunk\runtime\maven\build.xml
> mvn.setversion:
> mvn.invoke:
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family:
> "windows"
[jira] [Commented] (MANTTASKS-201) artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false
[
https://issues.apache.org/jira/browse/MANTTASKS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734923#comment-14734923
]
Michael Osipov commented on MANTTASKS-201:
--
It seems like the Ant Tasks abuses Maven. The behavior is correct. If one
intends to embed Maven, one should use Maven Embedder.
> artifact:mvn generates "org.apache.tools.ant.ExitException: Permission
> (java.lang.RuntimePermission exitVM) was not granted" when fork=false
>
>
> Key: MANTTASKS-201
> URL: https://issues.apache.org/jira/browse/MANTTASKS-201
> Project: Maven Ant Tasks
> Issue Type: Bug
> Components: mvn task
>Affects Versions: 2.1.1
>Reporter: Matt McHenry
>Priority: Minor
>
> Using this simple ant target:
> {code:xml}
>
>
>
>
> {code}
> I get the correct behaviour:
> {noformat}
> $ M2_HOME=`cygpath -w "$M2_HOME"` ant -Dmvn.goal=-version mvn.invoke
> Searching for build.xml ...
> Buildfile: c:\Users\mmchenry\svn\cli\trunk\runtime\maven\build.xml
> mvn.setversion:
> mvn.invoke:
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family:
> "windows"
> BUILD SUCCESSFUL
> Total time: 0 seconds{noformat}
> But if I set fork="false", then I get:
> {noformat}
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family:
> "windows"
> [artifact:mvn] org.apache.tools.ant.ExitException: Permission
> (java.lang.RuntimePermission exitVM) was not granted.
> [artifact:mvn] at
> org.apache.tools.ant.types.Permissions$MySM.checkExit(Permissions.java:196)
> [artifact:mvn] at java.lang.Runtime.exit(Runtime.java:88)
> [artifact:mvn] at java.lang.System.exit(System.java:904)
> [artifact:mvn] at org.codehaus.classworlds.Launcher.main(Launcher.java:376)
> [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn] at
> org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> [artifact:mvn] at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.run(Java.java:764)
> [artifact:mvn] at
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:218)
> [artifact:mvn] at
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132)
> [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105)
> [artifact:mvn] at org.apache.maven.artifact.ant.Mvn.execute(Mvn.java:81)
> [artifact:mvn] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn] at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> [artifact:mvn] at org.apache.tools.ant.Task.perform(Task.java:348)
> [artifact:mvn] at org.apache.tools.ant.Target.execute(Target.java:357)
> [artifact:mvn] at org.apache.tools.ant.Target.performTasks(Target.java:385)
> [artifact:mvn] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
> [artifact:mvn] at
> org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> [artifact:mvn] at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> [artifact:mvn] at
> org.apache.tools.ant.Project.executeTargets(Project.java:1189)
> [artifact:mvn] at org.apache.tools.ant.Main.runBuild(Main.java:758)
> [artifact:mvn] at org.apache.tools.ant.Main.startAnt(Main.java:217)
> [artifact:mvn] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
> [artifact:mvn] at
> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
> [artifact:mvn] Java Result: 100
> BUILD SUCCESSFUL
> Total time: 0
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735012#comment-14735012 ] Nicolas Juneau commented on MNG-5728: - Just as a note, there is an opened pull request on Github for this issue: https://github.com/apache/maven/pull/36 . Feedback is always appreciated. Thanks, Nicolas > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MANTRUN-172) Properties passed to Maven as -D don't get passed to invocations when a profile sets the same property
[ https://issues.apache.org/jira/browse/MANTRUN-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Lewis reopened MANTRUN-172: - Retested using the zip that was attached. The bug still occurs even after updating the maven-antrun-plugin to 1.8, the latest. > Properties passed to Maven as -D don't get passed to invocations when a > profile sets the same property > > > Key: MANTRUN-172 > URL: https://issues.apache.org/jira/browse/MANTRUN-172 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Derek Lewis > Attachments: maven-antrun-plugin-bug.zip > > > When I invoke Maven as follows: > mvn package -Dmy.test.property="from commandline" -Ptest-profile > Setting my.test.property on the command line, I expect to see the following > output from the testcase: > [echo] pom.xml: ptest = from commandline > [echo] pom.xml: my.test.property = from commandline > [echo] build.xml: ptest = from commandline > [echo] build.xml: my.test.property = from commandline > But instead I see: > [echo] pom.xml: ptest = from commandline > [echo] pom.xml: my.test.property = from commandline > [echo] build.xml: ptest = from commandline > [echo] build.xml: my.test.property = from profile > It looks like the task is causing properties set on the command line to > not be inherited. > When run without -Ptest-profile, the expected output is seen. The comments > on MANTRUN-121 would seem to imply that properties set on the commandline > should always be passed to sub builds, regardless of the value of the > inheritAll property. > I've tested with a profile in the pom as well as in settings.xml, and the > same behavior is observed regardless of where the profile is, so long as it > is activated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SCM-801) Correct SCM URLs mangled in children
Caleb Cushing created SCM-801: - Summary: Correct SCM URLs mangled in children Key: SCM-801 URL: https://issues.apache.org/jira/browse/SCM-801 Project: Maven SCM Issue Type: Bug Reporter: Caleb Cushing http://stackoverflow.com/a/26753032/206466 a lot of git repositories require the repository name to end it .git, only for a few services could this configuration ever be correct. Because I know asking for the behavior to stop auto appending would break backwards compatibility, instead I'd like to see a field added that would allow us to override the behavior, so that we don't have to duplicate this section in every sub pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735211#comment-14735211 ] Michael Osipov commented on MNG-5728: - Consider an artifact is broken on Central what do to beside opening an issue on OSSRH? What if author is gone? I ask myself whether it is ok to change it in a patch version...I guess not. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735355#comment-14735355 ] Nicolas Juneau commented on MNG-5728: - Hello Michael, Thank you for your comment. I agree that if the artifact cannot be modified or updated by the developer trying to use said artifact, fixing it can be harder especially if the maintainer cannot be reached. Then again, _by default_, I don't see a reason for the build to continue without failure. While this may not cause a compilation failure per-se, we cannot predict the effects that it will have on runtime, especially if the checksum failure is the result of an artifact being tampered with. I can appreciate the usage of the "checksumPolicy" tag or "-c" flag to make checksum checking lax in cases where I specifically _trust_ that checksums aren't important, but should it be the _default_? That being said, you are absolutely right that changing default behaviour isn't probably a good thing to do in a patch version. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
