[jira] [Updated] (MRELEASE-961) release plugin tries to use .bat instead of .cmd on windows
[
https://issues.apache.org/jira/browse/MRELEASE-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Cushing updated MRELEASE-961:
---
Description:
{code}PS C:\Users\xeno\IdeaProjects\rpf-security> mvn release:prepare
--batch-mode release:clean
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building rpf-security 0.1.4
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.3.2:prepare (default-cli) @ rpf-security ---
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing goals 'clean verify'...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.240 s
[INFO] Finished at: 2016-09-02T22:19:43-05:00
[INFO] Final Memory: 17M/307M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project rpf-security: Failed to invoke Maven build. Error configuring
command-line. Reason: Maven executable not found at:
C:\Users\xeno\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException{code}
for a workaround I copied {{mvn.cmd}} to {{mvn.bat}}
was:
{code}PS C:\Users\xeno\IdeaProjects\rpf-security> mvn release:prepare
--batch-mode release:clean
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building rpf-security 0.1.4
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.3.2:prepare (default-cli) @ rpf-security ---
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing goals 'clean verify'...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.240 s
[INFO] Finished at: 2016-09-02T22:19:43-05:00
[INFO] Final Memory: 17M/307M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project rpf-security: Failed to invoke Maven build. Error configuring
command-line. Reason: Maven executable not found at:
C:\Users\xeno\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException{code}
> release plugin tries to use .bat instead of .cmd on windows
> ---
>
> Key: MRELEASE-961
> URL: https://issues.apache.org/jira/browse/MRELEASE-961
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Caleb Cushing
>
> {code}PS C:\Users\xeno\IdeaProjects\rpf-security> mvn release:prepare
> --batch-mode release:clean
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building rpf-security 0.1.4
> [INFO]
>
> [INFO]
> [INFO] --- maven-release-plugin:2.3.2:prepare (default-cli) @ rpf-security ---
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing goals 'clean verify'...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.240 s
> [INFO] Finished at: 2016-09-02T22:19:43-05:00
> [INFO] Final Memory: 17M/307M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project rpf-security: Failed to invoke Maven build. Error configuring
> command-line. Reason: Maven executable not found at:
> C:\Users\xeno\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]
> [ERROR]
> [ERROR] To see the full
[jira] [Created] (MRELEASE-961) release plugin tries to use .bat instead of .cmd on windows
Caleb Cushing created MRELEASE-961:
--
Summary: release plugin tries to use .bat instead of .cmd on
windows
Key: MRELEASE-961
URL: https://issues.apache.org/jira/browse/MRELEASE-961
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Caleb Cushing
{code}PS C:\Users\xeno\IdeaProjects\rpf-security> mvn release:prepare
--batch-mode release:clean
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building rpf-security 0.1.4
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.3.2:prepare (default-cli) @ rpf-security ---
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing goals 'clean verify'...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.240 s
[INFO] Finished at: 2016-09-02T22:19:43-05:00
[INFO] Final Memory: 17M/307M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project rpf-security: Failed to invoke Maven build. Error configuring
command-line. Reason: Maven executable not found at:
C:\Users\xeno\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551 ] Robert Patrick edited comment on MNG-6083 at 9/2/16 8:50 PM: - Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile, one for every developer/environment, with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. The concern is whether those will work properly with the Maven release process or not... was (Author: rhpatrick00): Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile, one for every developer/environment, with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Blocker > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551 ] Robert Patrick edited comment on MNG-6083 at 9/2/16 8:46 PM: - Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile, one for every developer/environment, with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. was (Author: rhpatrick00): Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile--one for every developer/environment--with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Blocker > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551 ] Robert Patrick commented on MNG-6083: - Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile--one for every developer/environment--with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Blocker > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459480#comment-15459480 ] Robert Patrick edited comment on MNG-6083 at 9/2/16 8:13 PM: - And how exactly do you propose that would work if the property values vary across the environments where it needs to run (e.g., Windows vs. Linux)? You have made it very clear that you believe in checking the maven.config file into source control. What you haven't made clear is how you would handle environment-specific dependencies that the project has without the developers stepping on each other by overwriting maven.config every time they check in. Clearly, you don't feel like maven.config is the solution for this. So what is? was (Author: rhpatrick00): And how exactly do you propose that would work if the property values vary across the environments where it needs to run (e.g., Windows vs. Linux)? You have made it very clear that you believe in checking the maven.config file into source control. What you haven't made clear is how you you handle environment-specific dependencies that the project has without the developers stepping on each other by overwriting maven.config every time they check in. Clearly, you don't feel like maven.config is the solution for this. So what is? > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Blocker > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459480#comment-15459480 ] Robert Patrick commented on MNG-6083: - And how exactly do you propose that would work if the property values vary across the environments where it needs to run (e.g., Windows vs. Linux)? You have made it very clear that you believe in checking the maven.config file into source control. What you haven't made clear is how you you handle environment-specific dependencies that the project has without the developers stepping on each other by overwriting maven.config every time they check in. Clearly, you don't feel like maven.config is the solution for this. So what is? > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Blocker > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6084) Support JSR250 annotations
[ https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated MNG-6084: -- Summary: Support JSR250 annotations (was: Support JSR250 security annotations) > Support JSR250 annotations > -- > > Key: MNG-6084 > URL: https://issues.apache.org/jira/browse/MNG-6084 > Project: Maven > Issue Type: New Feature > Components: core >Affects Versions: 3.3.9 >Reporter: Dan Tran > > JSR330 ( @Named, @Singeton, etc) currently supported for plugin development. > Would like to see JSR250 as well(@PostConstruct, etc) > Detail discussion is at > http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-6084) Support JSR250 security annotations
Dan Tran created MNG-6084: - Summary: Support JSR250 security annotations Key: MNG-6084 URL: https://issues.apache.org/jira/browse/MNG-6084 Project: Maven Issue Type: New Feature Components: core Affects Versions: 3.3.9 Reporter: Dan Tran JSR330 ( @Named, @Singeton, etc) currently supported for plugin development. Would like to see JSR250 as well(@PostConstruct, etc) Detail discussion is at http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458725#comment-15458725
]
Karl Heinz Marbaise commented on MNG-6083:
--
And that's exactly the reason to checkin the {{.mvn/maven.config}} file with
your project
> Maven 3.3.9 breaks release:perform by not including maven.config
>
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests. The
> integration tests rely on our project root directory's .mvn/maven.config file
> to run properly. The maven.config file is NOT checked into the source tree
> because it contains environment-specific values so each developer has their
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in
> another location and with Maven 3.3.9, the maven.config from the original
> location is not being used. The build specifies the release-plugin version
> so the difference seems to be in the core Maven distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
