[jira] (MASSEMBLY-753) LineEnding CR to LF conversion output is wrong : All EOL are removed

2015-02-23 Thread Laurent TOURREAU (JIRA) 
Laurent TOURREAU created MASSEMBLY-753:
--

 Summary: LineEnding CR to LF conversion output is wrong : All EOL 
are removed
 Key: MASSEMBLY-753
 URL: https://jira.codehaus.org/browse/MASSEMBLY-753
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.3, 2.5.2, 2.5.1, 2.5
Reporter: Laurent TOURREAU
Priority: Blocker
 Attachments: maven-assembly-plugin-2.5.3-lineEnding-cr-to-lf-wrong.zip

when lineEnding=unix the conversion is not correct if the file contains CR end 
of line characters. The EOL characters are removed

Example on a file containing the text: 
{code}
MKDIR,/apps/myapp/CR
MKDIR,/apps/myapp/repbatch/scripts/eod/CR
MKDIR,/apps/myapp/repbatch//scripts/eod/log/CR
MKDIR,/apps/myapp/repbatch/scripts/cre/CR
{code}

We should expect this:
{code}
MKDIR,/apps/myapp/LF
MKDIR,/apps/myapp/repbatch/scripts/eod/LF
MKDIR,/apps/myapp/repbatch//scripts/eod/log/LF
MKDIR,/apps/myapp/repbatch/scripts/cre/LF
{code}

The result is :
{code}
MKDIR,/apps/myapp/MKDIR,/apps/myapp/repbatch/scripts/eod/MKDIR,/apps/myapp/repbatch//scripts/eod/log/MKDIR,/apps/myapp/repbatch/scripts/cre/
{code}


See zip attachment.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1140) Support anchoring all test case names

2015-02-23 Thread Sean Griffin (JIRA) 

[ 
https://jira.codehaus.org/browse/SUREFIRE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363786#comment-363786
 ] 

Sean Griffin commented on SUREFIRE-1140:


[Pull Request|https://github.com/apache/maven-surefire/pull/85] created.

Regarding the new parameter, it's true there is a new parameter, but there's 
nothing incompatible about it and shouldn't necessitate a major version bump.

 Support anchoring all test case names
 -

 Key: SUREFIRE-1140
 URL: https://jira.codehaus.org/browse/SUREFIRE-1140
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Maven Surefire Report Plugin
Affects Versions: 2.18
Reporter: Sean Griffin
Priority: Minor
 Attachments: anchor_test_case_names.patch


 The report includes anchors to test suite names but not test case names 
 inside the suite.  We would like the ability to externally link to individual 
 test cases in the report.  The anchor should be present whether the test case 
 passes or fails.
 Patch with tests is included.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-753) LineEnding CR to LF conversion output is wrong : All EOL are removed

2015-02-23 Thread Kristian Rosenvold (JIRA) 

 [ 
https://jira.codehaus.org/browse/MASSEMBLY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-753:
-

Fix Version/s: 2.5.4

 LineEnding CR to LF conversion output is wrong : All EOL are removed
 

 Key: MASSEMBLY-753
 URL: https://jira.codehaus.org/browse/MASSEMBLY-753
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5, 2.5.1, 2.5.2, 2.5.3
Reporter: Laurent TOURREAU
Priority: Blocker
 Fix For: 2.5.4

 Attachments: maven-assembly-plugin-2.5.3-lineEnding-cr-to-lf-wrong.zip


 when lineEnding=unix the conversion is not correct if the file contains CR 
 end of line characters. The EOL characters are removed
 Example on a file containing the text: 
 {code}
 MKDIR,/apps/myapp/CR
 MKDIR,/apps/myapp/repbatch/scripts/eod/CR
 MKDIR,/apps/myapp/repbatch//scripts/eod/log/CR
 MKDIR,/apps/myapp/repbatch/scripts/cre/CR
 {code}
 We should expect this:
 {code}
 MKDIR,/apps/myapp/LF
 MKDIR,/apps/myapp/repbatch/scripts/eod/LF
 MKDIR,/apps/myapp/repbatch//scripts/eod/log/LF
 MKDIR,/apps/myapp/repbatch/scripts/cre/LF
 {code}
 The result is :
 {code}
 MKDIR,/apps/myapp/MKDIR,/apps/myapp/repbatch/scripts/eod/MKDIR,/apps/myapp/repbatch//scripts/eod/log/MKDIR,/apps/myapp/repbatch/scripts/cre/
 {code}
 See zip attachment.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-753) LineEnding CR to LF conversion output is wrong : All EOL are removed

2015-02-23 Thread Kristian Rosenvold (JIRA) 

 [ 
https://jira.codehaus.org/browse/MASSEMBLY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reassigned MASSEMBLY-753:


Assignee: Kristian Rosenvold

 LineEnding CR to LF conversion output is wrong : All EOL are removed
 

 Key: MASSEMBLY-753
 URL: https://jira.codehaus.org/browse/MASSEMBLY-753
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5, 2.5.1, 2.5.2, 2.5.3
Reporter: Laurent TOURREAU
Assignee: Kristian Rosenvold
Priority: Blocker
 Fix For: 2.5.4

 Attachments: maven-assembly-plugin-2.5.3-lineEnding-cr-to-lf-wrong.zip


 when lineEnding=unix the conversion is not correct if the file contains CR 
 end of line characters. The EOL characters are removed
 Example on a file containing the text: 
 {code}
 MKDIR,/apps/myapp/CR
 MKDIR,/apps/myapp/repbatch/scripts/eod/CR
 MKDIR,/apps/myapp/repbatch//scripts/eod/log/CR
 MKDIR,/apps/myapp/repbatch/scripts/cre/CR
 {code}
 We should expect this:
 {code}
 MKDIR,/apps/myapp/LF
 MKDIR,/apps/myapp/repbatch/scripts/eod/LF
 MKDIR,/apps/myapp/repbatch//scripts/eod/log/LF
 MKDIR,/apps/myapp/repbatch/scripts/cre/LF
 {code}
 The result is :
 {code}
 MKDIR,/apps/myapp/MKDIR,/apps/myapp/repbatch/scripts/eod/MKDIR,/apps/myapp/repbatch//scripts/eod/log/MKDIR,/apps/myapp/repbatch/scripts/cre/
 {code}
 See zip attachment.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1087) New option rerunFailingTestsCount

2015-02-23 Thread Tibor Digana (JIRA) 

[ 
https://jira.codehaus.org/browse/SUREFIRE-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363803#comment-363803
 ] 

Tibor Digana commented on SUREFIRE-1087:


Not yet,  but you can implement it on GitHub if you like. We are not going to 
extendmuch  till the EO surefire:2.x.

 New option rerunFailingTestsCount
 -

 Key: SUREFIRE-1087
 URL: https://jira.codehaus.org/browse/SUREFIRE-1087
 Project: Maven Surefire
  Issue Type: New Feature
Reporter: Qingzhou Luo
Assignee: Andreas Gudian
 Fix For: 2.18


 Pull Request 40:
 https://github.com/apache/maven-surefire/pull/40
 
 Add rerunFailingTestsCount option for maven surefire to rerun failing tests 
 immediately after they fail.
 
 When rerunFailingTestsCount is set to  a value k larger than 0, a failing 
 test will get re-run
 up to k times until it passes. If a test passes in any of its reruns,
 the build will be marked as successful and the test will count as a
 flake (or flaky test). If it fails all those k times then it will
 still be marked as a failed test.
 
 In the console output all the flaky tests will be count as Flakes:
 N. The generated test report XML file is augmented with additional
 information, while still being compatible with existing consumers
 (such as Jenkins). A flaky test will have flakyFailure or/and
 flakyError under its testcase element, to store all the flaky
 runs' information (such as output, stackTrace). So existing consumers
 will still consider it as a passing test, while potential future
 consumers can parse those flaky runs information. A failing test will
 still have failure or error under testcase, but all the
 subsequent re-run information will be stored under rerunFailure or
 rerunError. So existing consumers will still be able to see it's a
 failed test and parse its failure information, and potential future
 consumers will be able to get all the flaky runs.
 
 It is implemented by keeping a map between test full class name and a
 map between all its test methods and the list of runs. It also takes
 into account Fork and Parallel and have them covered by integration
 tests.
 
 Currently only supports JUnit4.x



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHARED-409) maven-shared-jar fail to analyse jar containing new jdk8 code

2015-02-23 Thread Eric Barboni (JIRA) 
Eric Barboni created MSHARED-409:


 Summary: maven-shared-jar fail to analyse  jar containing new 
jdk8 code
 Key: MSHARED-409
 URL: https://jira.codehaus.org/browse/MSHARED-409
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-shared-jar
Affects Versions: maven-shared-jar-1.1
 Environment: windows 8.1 jdk 8.31
Reporter: Eric Barboni
 Attachments: jdk8jar.zip, jdk8.patch

Maven shared jar fail to analyse jdk8 artifact (containing jdk8 stream ). 
Apache BCEL raise an exception.

I discover this issue by using maven project info report plugin (dependencies 
section)

jdk8.patch contains a unit test expecting to have a true answer to 
isDebugPresent (as maven compiler generate debug info by default).

jdk8jar.zip is a multimode project to reproduce the jar used in the tests.

upgrading to bcel 6.0 SNAPSHOT works but as it's not release yet I guess I have 
to wait :p




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1087) New option rerunFailingTestsCount

2015-02-23 Thread brian schultz (JIRA) 

[ 
https://jira.codehaus.org/browse/SUREFIRE-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363796#comment-363796
 ] 

brian schultz commented on SUREFIRE-1087:
-

are there any plans for this to work with TestNG, or is this strictly JUnit?  
thanks!

 New option rerunFailingTestsCount
 -

 Key: SUREFIRE-1087
 URL: https://jira.codehaus.org/browse/SUREFIRE-1087
 Project: Maven Surefire
  Issue Type: New Feature
Reporter: Qingzhou Luo
Assignee: Andreas Gudian
 Fix For: 2.18


 Pull Request 40:
 https://github.com/apache/maven-surefire/pull/40
 
 Add rerunFailingTestsCount option for maven surefire to rerun failing tests 
 immediately after they fail.
 
 When rerunFailingTestsCount is set to  a value k larger than 0, a failing 
 test will get re-run
 up to k times until it passes. If a test passes in any of its reruns,
 the build will be marked as successful and the test will count as a
 flake (or flaky test). If it fails all those k times then it will
 still be marked as a failed test.
 
 In the console output all the flaky tests will be count as Flakes:
 N. The generated test report XML file is augmented with additional
 information, while still being compatible with existing consumers
 (such as Jenkins). A flaky test will have flakyFailure or/and
 flakyError under its testcase element, to store all the flaky
 runs' information (such as output, stackTrace). So existing consumers
 will still consider it as a passing test, while potential future
 consumers can parse those flaky runs information. A failing test will
 still have failure or error under testcase, but all the
 subsequent re-run information will be stored under rerunFailure or
 rerunError. So existing consumers will still be able to see it's a
 failed test and parse its failure information, and potential future
 consumers will be able to get all the flaky runs.
 
 It is implemented by keeping a map between test full class name and a
 map between all its test methods and the list of runs. It also takes
 into account Fork and Parallel and have them covered by integration
 tests.
 
 Currently only supports JUnit4.x



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-224) Regression from 1.3.1 to 1.4 with bannedDependencies rule

2015-02-23 Thread Brian Jackson (JIRA) 

[ 
https://jira.codehaus.org/browse/MENFORCER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364011#comment-364011
 ] 

Brian Jackson commented on MENFORCER-224:
-

This just bit me too.  Any workaround?

 Regression from 1.3.1 to 1.4 with bannedDependencies rule
 -

 Key: MENFORCER-224
 URL: https://jira.codehaus.org/browse/MENFORCER-224
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Plugin
Affects Versions: 1.4
 Environment: mvn --version
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
 2014-12-14T09:29:23-08:00)
 Maven home: /home/henning/.apache-maven
 Java version: 1.7.0_67, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.17.7-200.fc20.x86_64, arch: amd64, family: 
 unix
Reporter: Henning Schmiedehausen
Assignee: Karl-Heinz Marbaise
 Fix For: 1.4.1

 Attachments: pom.xml


 the attached pom, when running mvn enforcer:enforce in the project will 
 work with the enforcer plugin 1.3.1 but fail with the enforcer plugin 1.4 with
 [,4\.11)
^
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
   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:116)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
   at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-cli of goal 
 org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: Unclosed 
 character class near index 7
 [,4\.11)
^
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
   ... 19 more
 Caused by: java.util.regex.PatternSyntaxException: Unclosed character class 
 near index 7
 [,4\.11)
^
   at java.util.regex.Pattern.error(Pattern.java:1924)
   at java.util.regex.Pattern.clazz(Pattern.java:2493)
   at java.util.regex.Pattern.sequence(Pattern.java:2030)
   at java.util.regex.Pattern.expr(Pattern.java:1964)
   at java.util.regex.Pattern.compile(Pattern.java:1665)
   at java.util.regex.Pattern.init(Pattern.java:1337)
   at java.util.regex.Pattern.compile(Pattern.java:1022)
   at java.util.regex.Pattern.matches(Pattern.java:1128)
   at 
 org.apache.maven.plugins.enforcer.utils.ArtifactMatcher$Pattern.matches(ArtifactMatcher.java:148)
   at 
 org.apache.maven.plugins.enforcer.utils.ArtifactMatcher$Pattern.match(ArtifactMatcher.java:113)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.compareDependency(BannedDependencies.java:149)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.checkDependencies(BannedDependencies.java:117)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.checkDependencies(BannedDependencies.java:76)
   at 
 org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:94)
   at 
 org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:150)
   at

[jira] (MCOMPILER-122) -sourcepath shall include resources

2015-02-23 Thread Vincent Massol (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363752#comment-363752
 ] 

Vincent Massol commented on MCOMPILER-122:
--

{quote}
Also, including target/classes to sourcepath could lead to classes being 
compiled or recompiled [...]
{quote}

Not sure why we would include those... What's needed is 
${project.basedir}/src/main/resources


 -sourcepath shall include resources
 ---

 Key: MCOMPILER-122
 URL: https://jira.codehaus.org/browse/MCOMPILER-122
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Milos Kleint

 annotation processors which load non-Java resources from the sourcepath, will 
 currently get only the src/main/java folder.
 Unfortunately just adding src/main/resources to -sourcepath does not suffice, 
 due to a bug in javac:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404
 see MCOMPILER-98 for more



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-122) -sourcepath shall include resources

2015-02-23 Thread Thomas Broyer (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363753#comment-363753
 ] 

Thomas Broyer commented on MCOMPILER-122:
-

How about resource filtering? relocation? includes/excludes patterns? or just 
more resources root directory than just the default src/main/resources? cf. 
https://maven.apache.org/pom.html#Resources

 -sourcepath shall include resources
 ---

 Key: MCOMPILER-122
 URL: https://jira.codehaus.org/browse/MCOMPILER-122
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Milos Kleint

 annotation processors which load non-Java resources from the sourcepath, will 
 currently get only the src/main/java folder.
 Unfortunately just adding src/main/resources to -sourcepath does not suffice, 
 due to a bug in javac:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404
 see MCOMPILER-98 for more



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-122) -sourcepath shall include resources

2015-02-23 Thread Vincent Massol (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363758#comment-363758
 ] 

Vincent Massol commented on MCOMPILER-122:
--

Indeed, good point Thomas about target/classes. The same applies for generated 
java sources: they're currently not taken into account I guess.

 -sourcepath shall include resources
 ---

 Key: MCOMPILER-122
 URL: https://jira.codehaus.org/browse/MCOMPILER-122
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Milos Kleint

 annotation processors which load non-Java resources from the sourcepath, will 
 currently get only the src/main/java folder.
 Unfortunately just adding src/main/resources to -sourcepath does not suffice, 
 due to a bug in javac:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404
 see MCOMPILER-98 for more



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-224) Regression from 1.3.1 to 1.4 with bannedDependencies rule

2015-02-23 Thread Brian Jackson (JIRA) 

 [ 
https://jira.codehaus.org/browse/MENFORCER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Jackson updated MENFORCER-224:


Attachment: ArtifactMatcher.patch

I've attached a patch that fixes this issue. It includes integration tests to 
validate the fix.

 Regression from 1.3.1 to 1.4 with bannedDependencies rule
 -

 Key: MENFORCER-224
 URL: https://jira.codehaus.org/browse/MENFORCER-224
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Plugin
Affects Versions: 1.4
 Environment: mvn --version
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
 2014-12-14T09:29:23-08:00)
 Maven home: /home/henning/.apache-maven
 Java version: 1.7.0_67, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.17.7-200.fc20.x86_64, arch: amd64, family: 
 unix
Reporter: Henning Schmiedehausen
Assignee: Karl-Heinz Marbaise
 Fix For: 1.4.1

 Attachments: ArtifactMatcher.patch, pom.xml


 the attached pom, when running mvn enforcer:enforce in the project will 
 work with the enforcer plugin 1.3.1 but fail with the enforcer plugin 1.4 with
 [,4\.11)
^
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
   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:116)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
   at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-cli of goal 
 org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: Unclosed 
 character class near index 7
 [,4\.11)
^
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
   ... 19 more
 Caused by: java.util.regex.PatternSyntaxException: Unclosed character class 
 near index 7
 [,4\.11)
^
   at java.util.regex.Pattern.error(Pattern.java:1924)
   at java.util.regex.Pattern.clazz(Pattern.java:2493)
   at java.util.regex.Pattern.sequence(Pattern.java:2030)
   at java.util.regex.Pattern.expr(Pattern.java:1964)
   at java.util.regex.Pattern.compile(Pattern.java:1665)
   at java.util.regex.Pattern.init(Pattern.java:1337)
   at java.util.regex.Pattern.compile(Pattern.java:1022)
   at java.util.regex.Pattern.matches(Pattern.java:1128)
   at 
 org.apache.maven.plugins.enforcer.utils.ArtifactMatcher$Pattern.matches(ArtifactMatcher.java:148)
   at 
 org.apache.maven.plugins.enforcer.utils.ArtifactMatcher$Pattern.match(ArtifactMatcher.java:113)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.compareDependency(BannedDependencies.java:149)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.checkDependencies(BannedDependencies.java:117)
   at 
 org.apache.maven.plugins.enforcer.BannedDependencies.checkDependencies(BannedDependencies.java:76)
   at 
 org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:94)
   at 
 org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:150)
   at

[jira] (MDEP-479) Find duplicate properties

2015-02-23 Thread chibbe ... (JIRA) 

[ 
https://jira.codehaus.org/browse/MDEP-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364020#comment-364020
 ] 

chibbe ... commented on MDEP-479:
-

I set all version(s) for dependencies as properties, and sometimes when many 
dependencies and properties there has been duplicates. 
Want some way to catch this fault(s).

Attached a pom.xml with duplicated property.

 Find duplicate properties
 -

 Key: MDEP-479
 URL: https://jira.codehaus.org/browse/MDEP-479
 Project: Maven Dependency Plugin
  Issue Type: New Feature
Reporter: chibbe ...
 Fix For: waiting-for-feedback

 Attachments: pom.xml


 Would be good if a used property duplicated properties can be found as well.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MDEP-479) Find duplicate properties

2015-02-23 Thread chibbe ... (JIRA) 

 [ 
https://jira.codehaus.org/browse/MDEP-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chibbe ... updated MDEP-479:


Attachment: pom.xml

 Find duplicate properties
 -

 Key: MDEP-479
 URL: https://jira.codehaus.org/browse/MDEP-479
 Project: Maven Dependency Plugin
  Issue Type: New Feature
Reporter: chibbe ...
 Fix For: waiting-for-feedback

 Attachments: pom.xml


 Would be good if a used property duplicated properties can be found as well.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)