[jira] (MDEP-348) Add skip parameter to copy-dependencies goal
[ https://jira.codehaus.org/browse/MDEP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296138#comment-296138 ] Mikhail Mazursky commented on MDEP-348: --- Any updates on this issue? > Add skip parameter to copy-dependencies goal > > > Key: MDEP-348 > URL: https://jira.codehaus.org/browse/MDEP-348 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies, purge-local-repository, > unpack-dependencies >Affects Versions: 2.4 > Environment: Maven 3.0.4 >Reporter: Mikhail Mazursky > > Copy goal have this parameter but copy-dependencies misses it. I need it now, > please add it. > Also unpack and unpack-dependencies goal have the same issue (and maybe other > goals too). > In general it may be usefull to have this parameter in every goal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
Liya Katz created MWAR-279: -- Summary: WAR plugin fails during incremental build with JDK7 Key: MWAR-279 URL: https://jira.codehaus.org/browse/MWAR-279 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1.1, 2.2 Environment: Windows7 64bit maven 3.0.3 jdk-1.7.0_03 Reporter: Liya Katz Priority: Blocker Same error for war-plugin 2.2 and 2.1.1 Appears when running incremental build with jdk 7. Build from clean works fine. >From the log: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project xxx-web: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor [ERROR] Debugging information [ERROR] message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor [ERROR] cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException [ERROR] cause-message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor [ERROR] class : org.apache.maven.plugin.war.util.WebappStructure [ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure [ERROR] path: /webapp-structure [ERROR] --- [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project skyboxview-system-web: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor Debugging information message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor class : org.apache.maven.plugin.war.util.WebappStructure required-type : org.apache.maven.plugin.war.util.WebappStructure path: /webapp-structure --- at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor Debugging information message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor class : org.apache.maven.plugin.war.util.WebappStructure required-type : org.apache.maven.plugin.war.util.WebappStructure path: /webapp-structure -
[jira] (SUREFIRE-858) Running a single unit test in Windows
Sathyakumar Seshachalam created SUREFIRE-858:
Summary: Running a single unit test in Windows
Key: SUREFIRE-858
URL: https://jira.codehaus.org/browse/SUREFIRE-858
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12
Environment: Windows 7
Reporter: Sathyakumar Seshachalam
Priority: Blocker
I tried running a single unit test via -Dtest=MyTestName in a windows 7
machine, However this test (com\test\MyTestName.class) is not picked up by
surefire. The problem seems to be a call to
SelectorUtils.matchPath from org.apache.maven.surefire.SpecificTestClassFilter
The actual args to matchPath are ("**/MyTestName.class",
"com\\test\\MyTestName.class", true). This always returns false in Windows
environment because of the backslash char in second arg, but might succeed in
linux like OS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-645) Allow File/Directory Patterns for the checkModificationExcludes Option
[
https://jira.codehaus.org/browse/MRELEASE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-645:
Attachment: MRELEASE-645.patch
I've rewritten the patch and replaced the {{DirectoryScanner}} with the
{{SelectorUtils}} which seems to be a better fit. It should require less IO,
because it doesn't have to walk through all the folders on the system, it will
only do some ant-pattern-matches.
With this the Mocks can be removed, but the IT will fail, because the match
should be done on the status-result of the SCM. I haven't found a way to
resolve this yet.
So here's a new patch to start and test with.
> Allow File/Directory Patterns for the checkModificationExcludes Option
> --
>
> Key: MRELEASE-645
> URL: https://jira.codehaus.org/browse/MRELEASE-645
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: branch, prepare, scm
>Affects Versions: 2.1
> Environment: all
>Reporter: Stefan Ferstl
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: maven-release-manager-r1305146.patch,
> maven-release-plugin-it.patch, modification-excludes.patch, MRELEASE-645.patch
>
>
> The {{checkModificationExcludes}} option does currently only allow the
> definition single files to be excluded from the SCM modification check. If
> this option is defined, all files anywhere in the maven project structure
> with the specified name will be excluded from the check. It is currently not
> possible to exclude files only within a specific directory or to exclude
> classes of files, i.e. all files matching a specific file name pattern.
> If the {{checkModificationExcludes}} option allowed the definition of file
> and directory patterns, these things would be possible.
> *Example 1*: I'd like to exclude a test resource
> {{src/test/resources/foo.properties}} from the modification check but the
> real foo.properties in {{src/main/resources}} should still be checked.
> {code:xml}
>
>
> src/test/resources/foo.properties
>
> {code}
> *Example 2*: I'd like to exclude all properties files with the prefix {{bar}}
> from the modification check:
> {code:xml}
>
> **/bar*.properties
>
> {code}
> The attached patch modifies the {{ScmCheckModificationsPhase}} to use the
> {{DirectoryScanner}} from plexus-utils instead of doing a strict file name
> comparison. The patch does not provide more unit tests for this feature but
> it adjusts the existing tests to run without any failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-224) Add documentation on the useUniqueVersions to the index page
Anders Hammar created MSHARED-224: - Summary: Add documentation on the useUniqueVersions to the index page Key: MSHARED-224 URL: https://jira.codehaus.org/browse/MSHARED-224 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-2.5 Environment: n/a Reporter: Anders Hammar Reading in several places there seems to be an useUniqueVersions configuration for archive/manifest. But it is not documented in the reference page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-224) Add documentation on the useUniqueVersions to the index page
[ https://jira.codehaus.org/browse/MSHARED-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MSHARED-224: -- Attachment: MSHARED-224.patch Patch attached. > Add documentation on the useUniqueVersions to the index page > > > Key: MSHARED-224 > URL: https://jira.codehaus.org/browse/MSHARED-224 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-2.5 > Environment: n/a >Reporter: Anders Hammar > Attachments: MSHARED-224.patch > > > Reading in several places there seems to be an useUniqueVersions > configuration for archive/manifest. But it is not documented in the reference > page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-645) Allow File/Directory Patterns for the checkModificationExcludes Option
[
https://jira.codehaus.org/browse/MRELEASE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296174#comment-296174
]
Stefan Ferstl commented on MRELEASE-645:
I modified the integration test so that it uses a dummy scm provider
(src/it/setup/maven-scm-provider-mrelease-645). The {{status()}} method of this
scm provider indicates modified files that are excluded in the POM of the
integration test.
What is still missing, is a negative integration test which fails when files
are modified but not excluded. However, I haven't figured out yet how to write
such a test (i.e. how to configure the invoker-plugin to consider a build
failure as success).
Here is the new patch (maven-release-plugin-it-with-scm-provider.patch).
> Allow File/Directory Patterns for the checkModificationExcludes Option
> --
>
> Key: MRELEASE-645
> URL: https://jira.codehaus.org/browse/MRELEASE-645
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: branch, prepare, scm
>Affects Versions: 2.1
> Environment: all
>Reporter: Stefan Ferstl
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: maven-release-manager-r1305146.patch,
> maven-release-plugin-it.patch,
> maven-release-plugin-it-with-scm-provider.patch, modification-excludes.patch,
> MRELEASE-645.patch
>
>
> The {{checkModificationExcludes}} option does currently only allow the
> definition single files to be excluded from the SCM modification check. If
> this option is defined, all files anywhere in the maven project structure
> with the specified name will be excluded from the check. It is currently not
> possible to exclude files only within a specific directory or to exclude
> classes of files, i.e. all files matching a specific file name pattern.
> If the {{checkModificationExcludes}} option allowed the definition of file
> and directory patterns, these things would be possible.
> *Example 1*: I'd like to exclude a test resource
> {{src/test/resources/foo.properties}} from the modification check but the
> real foo.properties in {{src/main/resources}} should still be checked.
> {code:xml}
>
>
> src/test/resources/foo.properties
>
> {code}
> *Example 2*: I'd like to exclude all properties files with the prefix {{bar}}
> from the modification check:
> {code:xml}
>
> **/bar*.properties
>
> {code}
> The attached patch modifies the {{ScmCheckModificationsPhase}} to use the
> {{DirectoryScanner}} from plexus-utils instead of doing a strict file name
> comparison. The patch does not provide more unit tests for this feature but
> it adjusts the existing tests to run without any failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-645) Allow File/Directory Patterns for the checkModificationExcludes Option
[
https://jira.codehaus.org/browse/MRELEASE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Ferstl updated MRELEASE-645:
---
Attachment: maven-release-plugin-it-with-scm-provider.patch
new patch as described before
> Allow File/Directory Patterns for the checkModificationExcludes Option
> --
>
> Key: MRELEASE-645
> URL: https://jira.codehaus.org/browse/MRELEASE-645
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: branch, prepare, scm
>Affects Versions: 2.1
> Environment: all
>Reporter: Stefan Ferstl
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: maven-release-manager-r1305146.patch,
> maven-release-plugin-it.patch,
> maven-release-plugin-it-with-scm-provider.patch, modification-excludes.patch,
> MRELEASE-645.patch
>
>
> The {{checkModificationExcludes}} option does currently only allow the
> definition single files to be excluded from the SCM modification check. If
> this option is defined, all files anywhere in the maven project structure
> with the specified name will be excluded from the check. It is currently not
> possible to exclude files only within a specific directory or to exclude
> classes of files, i.e. all files matching a specific file name pattern.
> If the {{checkModificationExcludes}} option allowed the definition of file
> and directory patterns, these things would be possible.
> *Example 1*: I'd like to exclude a test resource
> {{src/test/resources/foo.properties}} from the modification check but the
> real foo.properties in {{src/main/resources}} should still be checked.
> {code:xml}
>
>
> src/test/resources/foo.properties
>
> {code}
> *Example 2*: I'd like to exclude all properties files with the prefix {{bar}}
> from the modification check:
> {code:xml}
>
> **/bar*.properties
>
> {code}
> The attached patch modifies the {{ScmCheckModificationsPhase}} to use the
> {{DirectoryScanner}} from plexus-utils instead of doing a strict file name
> comparison. The patch does not provide more unit tests for this feature but
> it adjusts the existing tests to run without any failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5272) SSL client-side certificates stopped working in maven 3.0.4
Igor von Nyssen created MNG-5272: Summary: SSL client-side certificates stopped working in maven 3.0.4 Key: MNG-5272 URL: https://jira.codehaus.org/browse/MNG-5272 Project: Maven 2 & 3 Issue Type: Bug Components: Command Line, Deployment Affects Versions: 3.0.4 Environment: Fedora, Ubuntu Reporter: Igor von Nyssen The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem to open the key store and therefore client side certificate authentication fails as maven never presents a certificate to the server. mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 adding -Djavax.net.debug=all reveals that the keystore is never loaded. Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-645) Allow File/Directory Patterns for the checkModificationExcludes Option
[
https://jira.codehaus.org/browse/MRELEASE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296180#comment-296180
]
Robert Scholte commented on MRELEASE-645:
-
To let the invoker-plugin check for a build failure you should add a
{{invoker.properties}} with {{invoker.buildResult = failure}} (see
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile)
After going through the SCM-code, it looks like a consumer is used to read the
output and to filter out the files. I'd hoped that an {{ScmFile.getPath()}}
always returns me a path relative to the working directory, but it looks like
it cannot guarantee that. In that case it doesn't matter if there's an IT.
I'll try to figure out what different SCM's can return and see if I should add
some adjustments.
> Allow File/Directory Patterns for the checkModificationExcludes Option
> --
>
> Key: MRELEASE-645
> URL: https://jira.codehaus.org/browse/MRELEASE-645
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: branch, prepare, scm
>Affects Versions: 2.1
> Environment: all
>Reporter: Stefan Ferstl
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: maven-release-manager-r1305146.patch,
> maven-release-plugin-it.patch,
> maven-release-plugin-it-with-scm-provider.patch, modification-excludes.patch,
> MRELEASE-645.patch
>
>
> The {{checkModificationExcludes}} option does currently only allow the
> definition single files to be excluded from the SCM modification check. If
> this option is defined, all files anywhere in the maven project structure
> with the specified name will be excluded from the check. It is currently not
> possible to exclude files only within a specific directory or to exclude
> classes of files, i.e. all files matching a specific file name pattern.
> If the {{checkModificationExcludes}} option allowed the definition of file
> and directory patterns, these things would be possible.
> *Example 1*: I'd like to exclude a test resource
> {{src/test/resources/foo.properties}} from the modification check but the
> real foo.properties in {{src/main/resources}} should still be checked.
> {code:xml}
>
>
> src/test/resources/foo.properties
>
> {code}
> *Example 2*: I'd like to exclude all properties files with the prefix {{bar}}
> from the modification check:
> {code:xml}
>
> **/bar*.properties
>
> {code}
> The attached patch modifies the {{ScmCheckModificationsPhase}} to use the
> {{DirectoryScanner}} from plexus-utils instead of doing a strict file name
> comparison. The patch does not provide more unit tests for this feature but
> it adjusts the existing tests to run without any failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MNG-5272 to WAGON-372: - Complexity: (was: Intermediate) Component/s: (was: Deployment) (was: Command Line) wagon-ftp Affects Version/s: (was: 3.0.4) 2.2 Key: WAGON-372 (was: MNG-5272) Project: Maven Wagon (was: Maven 2 & 3) > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ftp >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-372: --- Component/s: (was: wagon-ftp) wagon-http > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296181#comment-296181 ] Olivier Lamy commented on WAGON-372: as workaround you can put the file from http://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-http-lightweight/2.2/wagon-http-lightweight-2.2.jar to $M2_HOME/lib/ext . > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296187#comment-296187 ] Joseph Walton commented on MRELEASE-577: This change seems to publish the passwords from a private settings.xml into a world-readable file in /tmp during a build. > release:prepare does not pass argument "--settings" with current settings.xml > to inner maven > > > Key: MRELEASE-577 > URL: https://jira.codehaus.org/browse/MRELEASE-577 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9, 2.0 >Reporter: Petr Kozelka >Assignee: Stephen Connolly >Priority: Critical > Labels: contributers-welcome > Fix For: 2.2.2 > > > The impact is that release:prepare tries to use $HOME/.m2/settings.xml > instead of the one supplied by --settings cmdline option, which leads to > unexpected behavior > Of course if it does not exist, the inhouse repository is avoided and release > often fails due to a ResourceDoesNotExistException when an inhouse artifact > is requested by the pom. > To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml > and run this: > mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296189#comment-296189 ] Joseph Walton commented on MRELEASE-577: Note that this change will *not* work in Maven 3.0.3 due to MNG-5224. > release:prepare does not pass argument "--settings" with current settings.xml > to inner maven > > > Key: MRELEASE-577 > URL: https://jira.codehaus.org/browse/MRELEASE-577 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9, 2.0 >Reporter: Petr Kozelka >Assignee: Stephen Connolly >Priority: Critical > Labels: contributers-welcome > Fix For: 2.2.2 > > > The impact is that release:prepare tries to use $HOME/.m2/settings.xml > instead of the one supplied by --settings cmdline option, which leads to > unexpected behavior > Of course if it does not exist, the inhouse repository is avoided and release > often fails due to a ResourceDoesNotExistException when an inhouse artifact > is requested by the pom. > To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml > and run this: > mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
