[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
Børre Dalhaug created SCM-723:
-
Summary: On windows mvn release:prepare fails trying commit
changed pom.xml files.
Key: SCM-723
URL: https://jira.codehaus.org/browse/SCM-723
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-mercurial (hg)
Affects Versions: 1.8.1
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
Maven home: C:\maven
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: C:\Java\64bit\jdk1.7.0_21\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
Reporter: Børre Dalhaug
Priority: Blocker
Attachments: MavenReleasePluginBug.png
The commit includes a commit message, but the double quotes (") is not escaped
so the command fails. On Mac (and Linux?) the commit message is in single
quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-597) Duplicate files added to archive when present in both dependencyset and fileset of the same assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dzmitry Paulenka updated MASSEMBLY-597: --- Attachment: ma597.zip Sample projects, demonstrating the issue. > Duplicate files added to archive when present in both dependencyset and > fileset of the same assembly > > > Key: MASSEMBLY-597 > URL: https://jira.codehaus.org/browse/MASSEMBLY-597 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: windows 7, Eclipse indigo though the problem is > reproducible from command line build. Java 6 32 bit >Reporter: Eric Daigneault > Attachments: ma597.zip > > > Comment added to parent bug, could not re-open the issue so I created this > sub-task instead. Comment copied here for convenience : > > Either version 2.2.2 of the Assembly plugin has a regression or the issue has > not been fixed. I am currently creating zip files from the assembly that > contains duplicate jar files. > Some background : I am using the assembly to create a zip file of an > application. Why Zip ? because the application requires multiple > configuration files and spans larger than just Java so I cannot use a uber > Jar (I would prefer that but technical limitations out of my control force me > otherwise). > This package is built correctly. > To make life simpler I made it possible to extend this package with a project > that can add extra classes (plugins and such) and configuration from a > standard layout in the project that gets picked up by the assembly and merged > with the previous vanilla package. the end result is a fully assembled zip > file with all the customized parts in the right place. > Now, behaviour changed across version wheras previously I would overwrite the > original package with the content of the new one, now I have to start from > the overrides and complete withe the original files. Easily fixed through > changing the order I declared the filesets in the assembly. When using > filesets strictly nothing gets added twice, though the replace was changed to > skip which is a bit counter intuitive. > BUT > Since I extend some parts of the original system, I will share some > dependencies with this one. These dependencies are already present in the > original package and get added through a file set (I get the package and > unzip it in a temporary folder where I integrate it`s content inthe assembly > through a fileset). > I also add the dependencies of the new customized project, and these get > added twice. > I think there is a regression here when filesets and dependencysets interact > where if files are present in both they get added twice in the zip file. Now > I would re-open this current task but it seems I cannot so I will open a sub > task instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-597) Duplicate files added to archive when present in both dependencyset and fileset of the same assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326611#comment-326611 ] Dzmitry Paulenka commented on MASSEMBLY-597: I'm attaching sample projects, demonstrating the issue. First you need to mvn install "dependency". Than do mvn install on "project". Now you can see "target/project-full.jar", produced by assembly-plugin. So the issue is that it contains duplicates files under "/subdir" directory. BTW, you can see, that it didn't duplicate file "/file.txt" in the root of the jar, and used the correct one from project resources, which is good, but strange. > Duplicate files added to archive when present in both dependencyset and > fileset of the same assembly > > > Key: MASSEMBLY-597 > URL: https://jira.codehaus.org/browse/MASSEMBLY-597 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: windows 7, Eclipse indigo though the problem is > reproducible from command line build. Java 6 32 bit >Reporter: Eric Daigneault > Attachments: ma597.zip > > > Comment added to parent bug, could not re-open the issue so I created this > sub-task instead. Comment copied here for convenience : > > Either version 2.2.2 of the Assembly plugin has a regression or the issue has > not been fixed. I am currently creating zip files from the assembly that > contains duplicate jar files. > Some background : I am using the assembly to create a zip file of an > application. Why Zip ? because the application requires multiple > configuration files and spans larger than just Java so I cannot use a uber > Jar (I would prefer that but technical limitations out of my control force me > otherwise). > This package is built correctly. > To make life simpler I made it possible to extend this package with a project > that can add extra classes (plugins and such) and configuration from a > standard layout in the project that gets picked up by the assembly and merged > with the previous vanilla package. the end result is a fully assembled zip > file with all the customized parts in the right place. > Now, behaviour changed across version wheras previously I would overwrite the > original package with the content of the new one, now I have to start from > the overrides and complete withe the original files. Easily fixed through > changing the order I declared the filesets in the assembly. When using > filesets strictly nothing gets added twice, though the replace was changed to > skip which is a bit counter intuitive. > BUT > Since I extend some parts of the original system, I will share some > dependencies with this one. These dependencies are already present in the > original package and get added through a file set (I get the package and > unzip it in a temporary folder where I integrate it`s content inthe assembly > through a fileset). > I also add the dependencies of the new customized project, and these get > added twice. > I think there is a regression here when filesets and dependencysets interact > where if files are present in both they get added twice in the zip file. Now > I would re-open this current task but it seems I cannot so I will open a sub > task instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-184) Allow src/main/resources to be searched by Checkstyle
[
https://jira.codehaus.org/browse/MCHECKSTYLE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326613#comment-326613
]
Zlika commented on MCHECKSTYLE-184:
---
Inclusion of *.properties files by default in not consistant with the current
documentation
(http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html).
Moreoever, this lead in my case to a regression: I have a checkstyle rule to
enforce that every java file should begin by a special comment (/* Copyright...
*/). Now checkstyle looks at this pattern also for properties files!
Oddly, *.properties files seem to be taken into account only during the "site"
phase, but not during the default lifecycle.
> Allow src/main/resources to be searched by Checkstyle
> -
>
> Key: MCHECKSTYLE-184
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-184
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> There is a nice check in Checkstyle that allows you to keep your localized
> resource bundles in sync.
>
> http://checkstyle.sourceforge.net/config_misc.html
> In its current state maven-checkstyle-plugin cannot make use of this check,
> for two reasons:
> # maven-checkstyle-plugin only recognizes {{\*\*/\*.java}} files. This can be
> re-configured with the parameter.
> # maven-checkstyle-plugin supports only one source directory, which is
> configured with the parameter.
> We need to be able to add a resource directory (/src/main/resources by
> default) that is searched for {{\*\*/\*.properties}} files by default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTTASKS-239) Requires ant 1.9.1
Stephen Colebourne created MANTTASKS-239:
Summary: Requires ant 1.9.1
Key: MANTTASKS-239
URL: https://jira.codehaus.org/browse/MANTTASKS-239
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: documentation
Reporter: Stephen Colebourne
When using ant v1.8 the ant tasks do not work for me. Upgrading to ant v1.9.1
made them work.
With v1.8, the pom task failed to resolve the pom. The build continued, but
expressions such as pom.version did not resolve.
In addition, the dependencies task failed to read maven-metadata-local.xml:
{code}
Finding dependencies of ${pom.artifactId}-${version}
[echo] POM ${pom.version}
[echo] Finding dependencies of ${pom.artifactId}-${pom.version}
[artifact:dependencies] An error has occurred while processing the Maven artifac
t tasks.
[artifact:dependencies] Diagnosis:
[artifact:dependencies]
[artifact:dependencies] Unable to resolve artifact: Unable to get dependency inf
ormation: Unable to read the metadata file for artifact 'com.opengamma.platform:
og-util:jar': Error getting POM for 'com.opengamma.platform:og-util' from the re
pository: Unable to read local copy of metadata: Cannot read metadata from 'E:\m
aven\repository\com\opengamma\platform\og-util\2.0.0-SNAPSHOT\maven-metadata-loc
al.xml': expected START_TAG or END_TAG not TEXT (position: TEXT seen ...sourceshttp://maven.opengamma.com/nexus/content/gr
oups/public),
[artifact:dependencies] central (http://repo1.maven.org/maven2)
[artifact:dependencies] Path to dependency:
[artifact:dependencies] 1) com.opengamma.platform:og-language:jar:2.0.0-
SNAPSHOT
{code}
Moving to ant v1.9.1 fixed both issues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ https://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MWAR-192: - Assignee: Olivier Lamy > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: https://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers >Assignee: Olivier Lamy > Attachments: maven-war-plugin-2.1.1-patch.jar, > maven-war-plugin.patch, MWAR-192-maven-war-plugin.patch > > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) > at > org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) > at org.codehaus.plexus.util.FileU
[jira] (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ https://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-192. - Resolution: Fixed Fix Version/s: 2.4 patch applied. Thanks! > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: https://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: maven-war-plugin-2.1.1-patch.jar, > maven-war-plugin.patch, MWAR-192-maven-war-plugin.patch > > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) > at > org.codehaus.plexus.util.FileUtils.c
[jira] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-269. - Resolution: Duplicate Fix Version/s: 2.4 Assignee: Olivier Lamy > war fails to build while using m2e in workspace resolution mode > --- > > Key: MWAR-269 > URL: https://jira.codehaus.org/browse/MWAR-269 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1.1 >Reporter: Chris Gamache >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: maven-war-plugin.patch, screenshot-1.png > > > This is my first time for an issue/patch submission. Apologies if I'm doing > it wrong > When building in Eclipse using m2e in workspace resolution mode, the > maven-war-plugin is not prepared for a "dependency" which isn't an assembly > but is instead a folder containing the compiled classes from within the local > workspace. I propose that if the incoming dependency happens to be a > directory that it get packaged up and copied to the destination instead of > blowing up with an exception. > See attached patch for your review... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-176) testCompile does not compile sources under target/generated-test-sources
[ https://jira.codehaus.org/browse/MCOMPILER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326626#comment-326626 ] Andreas Horst commented on MCOMPILER-176: - Hi Anders, I'm sorry for the huge delay. I was planning to provide a test project but thanks to CI I found out that this is obviously a local problem. The problem only occurs in Eclipse and it's probably related to m2e. The problem does not occur on CI or CLI. Please close the issue (invalid). > testCompile does not compile sources under target/generated-test-sources > > > Key: MCOMPILER-176 > URL: https://jira.codehaus.org/browse/MCOMPILER-176 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Andreas Horst > > We use code generators using both target/generated-sources and > target/generated-test-sources as output folders. While source files under > generated-sources get compiled by compile goal, testCompile ignores the > content of generated-test-sources resulting in compiler errors in phase > test-compile. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-176) testCompile does not compile sources under target/generated-test-sources
[ https://jira.codehaus.org/browse/MCOMPILER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326626#comment-326626 ] Andreas Horst edited comment on MCOMPILER-176 at 6/12/13 8:14 AM: -- Hi Anders, I'm sorry for the huge delay. I was planning to provide a test project but thanks to CI I found out that this is obviously a local problem. The problem only occurs in Eclipse and it's probably related to m2e. The problem does not occur on CI or CLI. was (Author: ahorst): Hi Anders, I'm sorry for the huge delay. I was planning to provide a test project but thanks to CI I found out that this is obviously a local problem. The problem only occurs in Eclipse and it's probably related to m2e. The problem does not occur on CI or CLI. Please close the issue (invalid). > testCompile does not compile sources under target/generated-test-sources > > > Key: MCOMPILER-176 > URL: https://jira.codehaus.org/browse/MCOMPILER-176 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Andreas Horst > > We use code generators using both target/generated-sources and > target/generated-test-sources as output folders. While source files under > generated-sources get compiled by compile goal, testCompile ignores the > content of generated-test-sources resulting in compiler errors in phase > test-compile. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-176) testCompile does not compile sources under target/generated-test-sources
[ https://jira.codehaus.org/browse/MCOMPILER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Horst closed MCOMPILER-176. --- Resolution: Not A Bug This was only a local problem and occurred only in an IDE. It was not reproducible on CI or CLI. > testCompile does not compile sources under target/generated-test-sources > > > Key: MCOMPILER-176 > URL: https://jira.codehaus.org/browse/MCOMPILER-176 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Andreas Horst > > We use code generators using both target/generated-sources and > target/generated-test-sources as output folders. While source files under > generated-sources get compiled by compile goal, testCompile ignores the > content of generated-test-sources resulting in compiler errors in phase > test-compile. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-814) Parallel "both" setting does not execute classes in parallel
[ https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326636#comment-326636 ] Chris Hansen commented on SUREFIRE-814: --- I'm seeing this issue in 2.15 as well. Let me know if a sample project would help and I'll put one together. > Parallel "both" setting does not execute classes in parallel > > > Key: SUREFIRE-814 > URL: https://jira.codehaus.org/browse/SUREFIRE-814 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.11 >Reporter: Quantum Mechanics > > jdk 1.6.0_22, windows XP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
[
https://jira.codehaus.org/browse/SCM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326640#comment-326640
]
Robert Scholte commented on SCM-723:
Issue started at MRELEASE-841 and I'm still convinced it has to do with the
length of the command instead of the _printed_ quotes. A small project should
confirm that.
> On windows mvn release:prepare fails trying commit changed pom.xml files.
> -
>
> Key: SCM-723
> URL: https://jira.codehaus.org/browse/SCM-723
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.8.1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: C:\maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: C:\Java\64bit\jdk1.7.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Børre Dalhaug
>Priority: Blocker
> Attachments: MavenReleasePluginBug.png
>
>
> The commit includes a commit message, but the double quotes (") is not
> escaped so the command fails. On Mac (and Linux?) the commit message is in
> single quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-184) Allow src/main/resources to be searched by Checkstyle
[
https://jira.codehaus.org/browse/MCHECKSTYLE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326644#comment-326644
]
Dennis Lundberg commented on MCHECKSTYLE-184:
-
Yes, you are correct. The documenation is a bit lacking at the moment. There
are some technical reasons for that.
The inclusion of *.properties is only done for the src/main/resources
directory. The pattern is currently hard-coded so there is no configuration
parameter where this can be changed, and it's therefor not possible to document
it on the mojo web page.
There does indeed seem to be a bug in that this new feature is only being
invoked for the report, but not for the mojo. I'll open another issue for that
and fix it.
You can only have a regression if you decide to upgrade the version of
maven-checkstyle-plugin that you are using. So one workaround for you is to
stick with the previous version.
I'm curious about what your Checkstyle rule looks like. Is it a custom check or
one of the built-in checks? Is it possible to set the file extensions in the
check? If you are using one of the built-in Regexp checks
(http://checkstyle.sourceforge.net/config_regexp.html) you can configure the
fileExtensions property to tell it which files it should process.
> Allow src/main/resources to be searched by Checkstyle
> -
>
> Key: MCHECKSTYLE-184
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-184
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> There is a nice check in Checkstyle that allows you to keep your localized
> resource bundles in sync.
>
> http://checkstyle.sourceforge.net/config_misc.html
> In its current state maven-checkstyle-plugin cannot make use of this check,
> for two reasons:
> # maven-checkstyle-plugin only recognizes {{\*\*/\*.java}} files. This can be
> re-configured with the parameter.
> # maven-checkstyle-plugin supports only one source directory, which is
> configured with the parameter.
> We need to be able to add a resource directory (/src/main/resources by
> default) that is searched for {{\*\*/\*.properties}} files by default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-192) Properties files are only processed in the report, but not in the mojo
Dennis Lundberg created MCHECKSTYLE-192: --- Summary: Properties files are only processed in the report, but not in the mojo Key: MCHECKSTYLE-192 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-192 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Dennis Lundberg The new feature in MCHECKSTYLE-184 is only being invoked for the report, but not for the mojo. It should work the same way for both. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-310) Set entityExpansionLimit via java code
louis verderber created MCHANGES-310:
Summary: Set entityExpansionLimit via java code
Key: MCHANGES-310
URL: https://jira.codehaus.org/browse/MCHANGES-310
Project: Maven 2.x Changes Plugin
Issue Type: Sub-task
Reporter: louis verderber
Attachments: Screen Shot 2013-06-12 at 2.32.11 PM.png
The page at http://maven.apache.org/plugins/maven-changes-plugin/faq.html says
to reopen MCHANGES-75 if we know of a way to set entityExpansionLimit via java
(replace the argument -DentityExpansionLimit=128000)...
Will the following not work?
{code}
System.setProperty("entityExpansionLimit", "128000");
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-184) Allow src/main/resources to be searched by Checkstyle
[
https://jira.codehaus.org/browse/MCHECKSTYLE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326647#comment-326647
]
Zlika commented on MCHECKSTYLE-184:
---
Thank you for your tips.
In fact I added a suppress check line in my checkstyle-suppressions.xml to
explicitly exclude all checks in *.properties files.
I was not expecting those kinds of "problems" by just upgrading the plugin
version, so it is maybe not a "regression" but at least something that can
bother some users.
> Allow src/main/resources to be searched by Checkstyle
> -
>
> Key: MCHECKSTYLE-184
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-184
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> There is a nice check in Checkstyle that allows you to keep your localized
> resource bundles in sync.
>
> http://checkstyle.sourceforge.net/config_misc.html
> In its current state maven-checkstyle-plugin cannot make use of this check,
> for two reasons:
> # maven-checkstyle-plugin only recognizes {{\*\*/\*.java}} files. This can be
> re-configured with the parameter.
> # maven-checkstyle-plugin supports only one source directory, which is
> configured with the parameter.
> We need to be able to add a resource directory (/src/main/resources by
> default) that is searched for {{\*\*/\*.properties}} files by default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-655) Archive file resolution does not work as documented
Martin Lichtin created MASSEMBLY-655: Summary: Archive file resolution does not work as documented Key: MASSEMBLY-655 URL: https://jira.codehaus.org/browse/MASSEMBLY-655 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Martin Lichtin On page http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html it says that: "one fileSet selects sourceDir1/config.xml and another selects sourceDir2/config.xml to be archived as config/config.xml. In this case, assembly plugin archives the source file selected in the latter fileSet." However, this does not seem true? It seems like the the file is taken from the first fileSet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-192) Properties files are only processed in the report, but not in the mojo
[ https://jira.codehaus.org/browse/MCHECKSTYLE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-192. --- Resolution: Fixed Fix Version/s: 2.11 Assignee: Dennis Lundberg Fixed in [r1492405|http://svn.apache.org/viewvc?view=revision&revision=1492405]. > Properties files are only processed in the report, but not in the mojo > -- > > Key: MCHECKSTYLE-192 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-192 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.11 > > > The new feature in MCHECKSTYLE-184 is only being invoked for the report, but > not for the mojo. It should work the same way for both. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-271) For repository assembly, include pom.xml project plugins, as an option
[
https://jira.codehaus.org/browse/MASSEMBLY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326651#comment-326651
]
Joël Royer commented on MASSEMBLY-271:
--
I've got the same problem.
I want to build a repository archive that allows my customer to build the
projet without access to the central repository.
Plugins described in the pom are not package.
> For repository assembly, include pom.xml project plugins, as an option
> --
>
> Key: MASSEMBLY-271
> URL: https://jira.codehaus.org/browse/MASSEMBLY-271
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.2-beta-1
>Reporter: Elias Ross
>
> One use case for creating a repository archive, like so:
> {code:xml}
>
>
>
> repository
> true
>
>
>
> {code}
> Is to allow the project pom to be runnable at a customer or remote site,
> which does not have access to the central repository. Runnable, in the sense
> that targets such as "exec:java" or the like can be called.
> However, the repository archive does not include any plugins, especially
> custom ones, that may be required to use a remotely deployed pom.xml.
> I classified this as a "bug" since I feel without project plugins included,
> the repository is not complete, but may be considered more of a "feature
> request" instead.
> A work-around is indicate custom plugins using
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-271) For repository assembly, include pom.xml project plugins, as an option
[
https://jira.codehaus.org/browse/MASSEMBLY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326651#comment-326651
]
Joël Royer edited comment on MASSEMBLY-271 at 6/12/13 3:23 PM:
---
I've got the same problem.
I want to build a repository archive that allows my customer to build the
projet without access to the central repository.
Plugins described in the pom are not packaged.
was (Author: jroyer):
I've got the same problem.
I want to build a repository archive that allows my customer to build the
projet without access to the central repository.
Plugins described in the pom are not package.
> For repository assembly, include pom.xml project plugins, as an option
> --
>
> Key: MASSEMBLY-271
> URL: https://jira.codehaus.org/browse/MASSEMBLY-271
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.2-beta-1
>Reporter: Elias Ross
>
> One use case for creating a repository archive, like so:
> {code:xml}
>
>
>
> repository
> true
>
>
>
> {code}
> Is to allow the project pom to be runnable at a customer or remote site,
> which does not have access to the central repository. Runnable, in the sense
> that targets such as "exec:java" or the like can be called.
> However, the repository archive does not include any plugins, especially
> custom ones, that may be required to use a remotely deployed pom.xml.
> I classified this as a "bug" since I feel without project plugins included,
> the repository is not complete, but may be considered more of a "feature
> request" instead.
> A work-around is indicate custom plugins using
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
[
https://jira.codehaus.org/browse/SCM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326653#comment-326653
]
Børre Dalhaug commented on SCM-723:
---
Even though that is the case it is still a bug!
If you write software for a spesific OS it must work on that OS!
> On windows mvn release:prepare fails trying commit changed pom.xml files.
> -
>
> Key: SCM-723
> URL: https://jira.codehaus.org/browse/SCM-723
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.8.1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: C:\maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: C:\Java\64bit\jdk1.7.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Børre Dalhaug
>Priority: Blocker
> Attachments: MavenReleasePluginBug.png
>
>
> The commit includes a commit message, but the double quotes (") is not
> escaped so the command fails. On Mac (and Linux?) the commit message is in
> single quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
[
https://jira.codehaus.org/browse/SCM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326657#comment-326657
]
Robert Scholte commented on SCM-723:
Let me try to rephrase my comments and add links to the related code:
[HgUtils.execute()|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-hg/xref/org/apache/maven/scm/provider/hg/HgUtils.html#83]
is responsible for every execution of a Mercurial command.
{{org.codehaus.plexus.util.cli.Commandline}} is the '_framework_' for
executing. It has intelligence to adjust the executable based on the OS.
This class is used by every SCM Provider and a lot of Maven plugins.
{{CommandLine}} opens a new shell to have full control over environment
variables. So the last argument contains what will actually be executed. This
is not how _you_ want to execute the command, because it'll close the shell
ASAP. So you're only interested in the content of the last argument. In fact
I'm quite happy it is not escaped, otherwise I had to unescape that line first
before I could excecute it and analyze the output. If you still don't agree,
discuss it with, share your thoughts
[here|https://jira.codehaus.org/browse/PLXUTILS] (that'll be my last redirect
;) ).
My intention was to point you to (what I believe is) the real cause. Convince
me I'm wrong by trying the release a single module project (I predict it'll
succeed). Also convince me I'm wrong by replacing the quotes(I predict the same
issue).
> On windows mvn release:prepare fails trying commit changed pom.xml files.
> -
>
> Key: SCM-723
> URL: https://jira.codehaus.org/browse/SCM-723
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.8.1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: C:\maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: C:\Java\64bit\jdk1.7.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Børre Dalhaug
>Priority: Blocker
> Attachments: MavenReleasePluginBug.png
>
>
> The commit includes a commit message, but the double quotes (") is not
> escaped so the command fails. On Mac (and Linux?) the commit message is in
> single quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326661#comment-326661
]
SebbASF commented on MCOMPILER-205:
---
Ant had an issue with the package-info.java files and solved it by creating
empty class files if the javac compiler failed to do so. This is (now) optional
behaviour.
See https://issues.apache.org/bugzilla/show_bug.cgi?id=52096 for a useful
discussion.
It points out that JDK 7 javac has the option -Xpkginfo:always
The difference with Ant is that it does not recompile everything just because a
single p-i file is out of date.
That's an optimisation that Maven could easily implement.
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://jira.codehaus.org/browse/MCOMPILER-205
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
> Attachments: hello.tgz, no-class-in-java-file.zip
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
[
https://jira.codehaus.org/browse/SCM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326662#comment-326662
]
Børre Dalhaug commented on SCM-723:
---
I didn't understand much of what you just wrote. I am only a user of Maven and
don't have the time (or skills) to dive into it or write any modules. Right now
I am not able to make releases of my software on Windows. Whatever the
underlying issue is (escapes, commands, frameworks etc) it still is a bug. Do
you really disagree with me on that?
IS there a workaround or do I have to use mac/linux when running the mvn
release:prepare command?
> On windows mvn release:prepare fails trying commit changed pom.xml files.
> -
>
> Key: SCM-723
> URL: https://jira.codehaus.org/browse/SCM-723
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.8.1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: C:\maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: C:\Java\64bit\jdk1.7.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Børre Dalhaug
>Priority: Blocker
> Attachments: MavenReleasePluginBug.png
>
>
> The commit includes a commit message, but the double quotes (") is not
> escaped so the command fails. On Mac (and Linux?) the commit message is in
> single quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-723) On windows mvn release:prepare fails trying commit changed pom.xml files.
[
https://jira.codehaus.org/browse/SCM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326662#comment-326662
]
Børre Dalhaug edited comment on SCM-723 at 6/13/13 12:55 AM:
-
I didn't understand much of what you just wrote. I am only a user of Maven and
don't have the time (or skills) to dive into it or write any modules. Right now
I am not able to make releases of my software on Windows. Whatever the
underlying issue is (escapes, commands, frameworks etc) it still is a bug. Do
you really disagree with me on that?
Is there a workaround or do I have to use mac/linux when running the mvn
release:prepare command?
was (Author: borre):
I didn't understand much of what you just wrote. I am only a user of Maven
and don't have the time (or skills) to dive into it or write any modules. Right
now I am not able to make releases of my software on Windows. Whatever the
underlying issue is (escapes, commands, frameworks etc) it still is a bug. Do
you really disagree with me on that?
IS there a workaround or do I have to use mac/linux when running the mvn
release:prepare command?
> On windows mvn release:prepare fails trying commit changed pom.xml files.
> -
>
> Key: SCM-723
> URL: https://jira.codehaus.org/browse/SCM-723
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.8.1
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: C:\maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: C:\Java\64bit\jdk1.7.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Børre Dalhaug
>Priority: Blocker
> Attachments: MavenReleasePluginBug.png
>
>
> The commit includes a commit message, but the double quotes (") is not
> escaped so the command fails. On Mac (and Linux?) the commit message is in
> single quotes (') so that works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
