[jira] (MENFORCER-224) Regression from 1.3.1 to 1.4 with bannedDependencies rule
Henning Schmiedehausen created MENFORCER-224: Summary: 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 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.(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 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) ... 20 more Mostly because the version inclusion / exclusion expressions are not regexps. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Nesterenko updated MJAVADOC-425: - Description: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. was: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist. but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) > Outdated doxia's version is used in plugin > -- > > Key: MJAVADOC-425 > URL: https://jira.codehaus.org/browse/MJAVADOC-425 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.10.1 >Reporter: Aleksey Nesterenko > > I've faced problems while generating linkcheck report on our project. > Links are pointing to methods in javadoc generated html pages, but in final > report lots of links are marked as "invalid" > Analyzing of the problem let me noticed that maven-javadoc-plugin is using > doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 > pom: > >... > 1.0 > 1.0 > ... > > My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and > as you see it was fixed in doxia 1.4 > Current latest doxia version is 1.6, so I think there's need of updating > javadoc plugin. > Steps of reproducing my problem: > 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && > git checkout checkstyle-6.3 > 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true > -Dcobertura.skip=true > 3) Open target/site/linkcheck.html > Example of my current report: > http://alexkravin.github.io/linkcheck/linkcheck.html > As you can see - even "invalid" link will redirect you to proper location. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Nesterenko updated MJAVADOC-425: - Description: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) was: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. > Outdated doxia's version is used in plugin > -- > > Key: MJAVADOC-425 > URL: https://jira.codehaus.org/browse/MJAVADOC-425 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.10.1 >Reporter: Aleksey Nesterenko > > I've faced problems while generating linkcheck report on our project. > Links are pointing to methods in javadoc generated html pages, but in final > report lots of links are marked as "invalid" > Analyzing of the problem let me noticed that maven-javadoc-plugin is using > doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 > pom: > >... > 1.0 > 1.0 > ... > > My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and > as you see it was fixed in doxia 1.4 > Current latest doxia version is 1.6, so I think there's need of updating > javadoc plugin. > Steps of reproducing my problem: > 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && > git checkout checkstyle-6.3 > 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true > -Dcobertura.skip=true > 3) Open target/site/linkcheck.html > Example of my current report: > http://alexkravin.github.io/linkcheck/linkcheck.html > As you can see - even "invalid" link will redirect you to proper location. > E.g.: > apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html > error > ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): > doesn't exist > but it's valid > http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, > int) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Nesterenko updated MJAVADOC-425: - Description: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist. but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) was: I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. > Outdated doxia's version is used in plugin > -- > > Key: MJAVADOC-425 > URL: https://jira.codehaus.org/browse/MJAVADOC-425 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.10.1 >Reporter: Aleksey Nesterenko > > I've faced problems while generating linkcheck report on our project. > Links are pointing to methods in javadoc generated html pages, but in final > report lots of links are marked as "invalid" > Analyzing of the problem let me noticed that maven-javadoc-plugin is using > doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 > pom: > >... > 1.0 > 1.0 > ... > > My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and > as you see it was fixed in doxia 1.4 > Current latest doxia version is 1.6, so I think there's need of updating > javadoc plugin. > Steps of reproducing my problem: > 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && > git checkout checkstyle-6.3 > 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true > -Dcobertura.skip=true > 3) Open target/site/linkcheck.html > Example of my current report: > http://alexkravin.github.io/linkcheck/linkcheck.html > As you can see - even "invalid" link will redirect you to proper location. > E.g.: > apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html > error > ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): > doesn't exist. > but it's valid > http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, > int) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
Aleksey Nesterenko created MJAVADOC-425: Summary: Outdated doxia's version is used in plugin Key: MJAVADOC-425 URL: https://jira.codehaus.org/browse/MJAVADOC-425 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Reporter: Aleksey Nesterenko I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as "invalid" Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: ... 1.0 1.0 ... My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git && cd checkstyle/ && git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even "invalid" link will redirect you to proper location. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1142) Summarize at End in multimodule projects
Andreas Gudian created SUREFIRE-1142:
Summary: Summarize at End in multimodule projects
Key: SUREFIRE-1142
URL: https://jira.codehaus.org/browse/SUREFIRE-1142
Project: Maven Surefire
Issue Type: New Feature
Reporter: Andreas Gudian
In multimodule projects with {{testFailureIgnore=true}}, it is very tedious to
find out if / where there were any test failures when building on the console.
Our HTML report format is of no real help there either.
I suggest to display the test summary of failing tests at the end of the
reactor build (or after the last of the reactor projects) in case
{{testFailureIgnore=true}}.
Implementation-wise, we can do it like install / deploy do it with their
{{installAtEnd}} / {{deployAtEnd}} options.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJARSIGNER-44) offline ignored ..enable requiresOnline attribute
Martin Gainty created MJARSIGNER-44: --- Summary: offline ignored ..enable requiresOnline attribute Key: MJARSIGNER-44 URL: https://jira.codehaus.org/browse/MJARSIGNER-44 Project: Maven Jar Signer Plugin Issue Type: Bug Affects Versions: 1.4 Environment: JDK 1.7 MVN 3.1.1 Reporter: Martin Gainty Priority: Minor Andreas/Curtis want the ability to detect offline situation to automatically configure the tsa attribute in maven-jarsigner-plugin .. detecting offline environment can be achieved with requiresOnline from maven-plugin-tools-annotations: http://maven.apache.org/plugin-tools-archives/plugin-tools-3.2/maven-plugin-tools-annotations/apidocs/org/apache/maven/plugin/annotations/datamodel/MojoAnnotationContent.html Requesting the requiresOnline attribute and methods which implement requiresOnline be factored into maven-jarsigner-plugin Thank You Martin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-261) Upgrade to Checkstyle 6.1.1
[ https://jira.codehaus.org/browse/MCHECKSTYLE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-261. --- Resolution: Fixed Fixed in [r1658049|http://svn.apache.org/viewvc?view=revision&revision=1658049]. A 2.15-SNAPSHOT has been deployed, please try it out. http://maven.apache.org/guides/development/guide-testing-development-plugins.html > Upgrade to Checkstyle 6.1.1 > --- > > Key: MCHECKSTYLE-261 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-261 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.14 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.15 > > > Upgrade to the latest 6.x version of Checkstyle, which at the time of writing > is 6.1. > Note that this upgrade will make the Checkstyle plugin require Java 6, > because Checkstyle requires Java 6 since version 5.9. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-277) Require Java 6
[ https://jira.codehaus.org/browse/MCHECKSTYLE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-277. --- Resolution: Fixed Fixed in [r1658048|http://svn.apache.org/viewvc?view=revision&revision=1658048]. > Require Java 6 > -- > > Key: MCHECKSTYLE-277 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-277 > Project: Maven Checkstyle Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.15 > > > Checkstyle versions 5.9 - 6.1.1 requires Java 6, so we need to adjust the > requirements in this plugin to reflect that. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-604) release:branch should take the "commitByProject" parameter into account
[ https://jira.codehaus.org/browse/MRELEASE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reopened MRELEASE-604: -- This still seems to be a valid issue and I am experiencing the same problem. > release:branch should take the "commitByProject" parameter into account > --- > > Key: MRELEASE-604 > URL: https://jira.codehaus.org/browse/MRELEASE-604 > Project: Maven Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 > Environment: Maven 2.2.1, Subversion 1.6, Windows, Java 1.6 >Reporter: werner mueller > > The release:prepare goal allows to adjust tagging to a flat directory layout > by using the 'commitByProject=true' confiuration option: > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#commitByProject > This way the release:perform will add every module into the release tag. > When using release:branch only the parent module is commited to the created > branch. All sub-modules in the flat directory layout are ignored (or end up > somewhere else?). The commitByProject option has no effect for branching. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-261) Upgrade to Checkstyle 6.1.1
[ https://jira.codehaus.org/browse/MCHECKSTYLE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362718#comment-362718 ] Dennis Lundberg commented on MCHECKSTYLE-261: - @Zlika The workaround is now described on the Checkstyle Plugin site at http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html If those instructions does not work, then please file a separate JIRA issue describing why it does not work. Please include a complete minimal pom.xml that can be used to test it. I'm working on version 2.15 of the plugin now, which will include this issue. > Upgrade to Checkstyle 6.1.1 > --- > > Key: MCHECKSTYLE-261 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-261 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.14 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.15 > > > Upgrade to the latest 6.x version of Checkstyle, which at the time of writing > is 6.1. > Note that this upgrade will make the Checkstyle plugin require Java 6, > because Checkstyle requires Java 6 since version 5.9. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-862) excludedGroups property does not work with JUnit
[
https://jira.codehaus.org/browse/SUREFIRE-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362755#comment-362755
]
Elad Tabak commented on SUREFIRE-862:
-
@Tibor
I'm using TestNG version 6.8.5, surefire 2.13.
It seems the resolution of what are the tests to run is somewhat strange. I'm
trying to pin point the exact issue, but I suspect it's related to hierarchy of
tests.
For example, for a base class SlowTest annotated with {code}@Test(groups =
{"slow"}){code}, I would expect that all sub classes that inherits from
SlowTest will be skipped by surefire, and caught be failsafe. However, this is
not the case, and I'm trying to figure out the exact combination of @Test on
the super/sub/method with/without group that will work.
> excludedGroups property does not work with JUnit
>
>
> Key: SUREFIRE-862
> URL: https://jira.codehaus.org/browse/SUREFIRE-862
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Windows, Maven 3.0.3
>Reporter: Rene Grohmann
>Assignee: Kristian Rosenvold
> Fix For: 2.12.3
>
>
> If i use the groups property in my maven configuration everything works how
> expected. The plugin only selects the tests with the specific category. On
> the other Hand, if i use the excludedGroups property the plugin could not
> find any tests to run.
>
> maven-surefire-plugin
> 2.11
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.12
>
>
>
> de.test.junit.categories.IntegrationTest
>
>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-329) Allow generation of empty javadoc JARs
[ https://jira.codehaus.org/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362747#comment-362747 ] John R Fallows edited comment on MJAVADOC-329 at 2/7/15 12:40 PM: -- The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc plugin configuration such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. The problem is further exacerbated when dealing with more than one project (not aggregated). Configuring the javadoc plugin once in the parent POM for all such projects would be ideal. was (Author: jfallows): The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc plugin configuration such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. The problem is further exacerbated when dealing with more than one projects (not aggregated). Configuring the javadoc plugin once in the parent POM for all such projects would be ideal. > Allow generation of empty javadoc JARs > -- > > Key: MJAVADOC-329 > URL: https://jira.codehaus.org/browse/MJAVADOC-329 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Vincent Massol > > Here's my use case: > * I want to be able to deploy my artifacts to Maven Central. There's a > requirement that a javadoc jar exists for the arifact to deploy > * However I have some maven modules of type packaging = jar that have java > files but these files are located in an "internal" package (internal api that > we don't expose to end users since it's not part of our public API contract) > which we exclude from the javadoc generation > The problem is that the javadoc plugin doesn't generate any JAR if there are > no java files matching (even if I have other files such as a package.html > file in my src/main/javadoc/* directories). > I'd like it to be possible to generate an "empty" javadoc JAR containing only > a package.html file for example. > Thanks a lot -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-329) Allow generation of empty javadoc JARs
[ https://jira.codehaus.org/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362747#comment-362747 ] John R Fallows edited comment on MJAVADOC-329 at 2/7/15 12:41 PM: -- The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc plugin configuration such as "generateIfEmpty" and default to false for backwards compatibility. Projects deploying to Maven Central could simply configure "generateIfEmpty" to true. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. The problem is further exacerbated when dealing with more than one project (not aggregated). Configuring the javadoc plugin once in the parent POM for all such projects would be ideal. was (Author: jfallows): The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc plugin configuration such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. The problem is further exacerbated when dealing with more than one project (not aggregated). Configuring the javadoc plugin once in the parent POM for all such projects would be ideal. > Allow generation of empty javadoc JARs > -- > > Key: MJAVADOC-329 > URL: https://jira.codehaus.org/browse/MJAVADOC-329 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Vincent Massol > > Here's my use case: > * I want to be able to deploy my artifacts to Maven Central. There's a > requirement that a javadoc jar exists for the arifact to deploy > * However I have some maven modules of type packaging = jar that have java > files but these files are located in an "internal" package (internal api that > we don't expose to end users since it's not part of our public API contract) > which we exclude from the javadoc generation > The problem is that the javadoc plugin doesn't generate any JAR if there are > no java files matching (even if I have other files such as a package.html > file in my src/main/javadoc/* directories). > I'd like it to be possible to generate an "empty" javadoc JAR containing only > a package.html file for example. > Thanks a lot -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-329) Allow generation of empty javadoc JARs
[ https://jira.codehaus.org/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362747#comment-362747 ] John R Fallows edited comment on MJAVADOC-329 at 2/7/15 12:40 PM: -- The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc plugin configuration such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. The problem is further exacerbated when dealing with more than one projects (not aggregated). Configuring the javadoc plugin once in the parent POM for all such projects would be ideal. was (Author: jfallows): The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc:jar mojo such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. > Allow generation of empty javadoc JARs > -- > > Key: MJAVADOC-329 > URL: https://jira.codehaus.org/browse/MJAVADOC-329 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Vincent Massol > > Here's my use case: > * I want to be able to deploy my artifacts to Maven Central. There's a > requirement that a javadoc jar exists for the arifact to deploy > * However I have some maven modules of type packaging = jar that have java > files but these files are located in an "internal" package (internal api that > we don't expose to end users since it's not part of our public API contract) > which we exclude from the javadoc generation > The problem is that the javadoc plugin doesn't generate any JAR if there are > no java files matching (even if I have other files such as a package.html > file in my src/main/javadoc/* directories). > I'd like it to be possible to generate an "empty" javadoc JAR containing only > a package.html file for example. > Thanks a lot -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-329) Allow generation of empty javadoc JARs
[ https://jira.codehaus.org/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362747#comment-362747 ] John R Fallows commented on MJAVADOC-329: - The requirement for deployment to Maven Central is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc:jar mojo such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. > Allow generation of empty javadoc JARs > -- > > Key: MJAVADOC-329 > URL: https://jira.codehaus.org/browse/MJAVADOC-329 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Vincent Massol > > Here's my use case: > * I want to be able to deploy my artifacts to Maven Central. There's a > requirement that a javadoc jar exists for the arifact to deploy > * However I have some maven modules of type packaging = jar that have java > files but these files are located in an "internal" package (internal api that > we don't expose to end users since it's not part of our public API contract) > which we exclude from the javadoc generation > The problem is that the javadoc plugin doesn't generate any JAR if there are > no java files matching (even if I have other files such as a package.html > file in my src/main/javadoc/* directories). > I'd like it to be possible to generate an "empty" javadoc JAR containing only > a package.html file for example. > Thanks a lot -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-329) Allow generation of empty javadoc JARs
[ https://jira.codehaus.org/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362747#comment-362747 ] John R Fallows edited comment on MJAVADOC-329 at 2/7/15 12:37 PM: -- The requirement for deployment to Maven Central via Sonatype is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc:jar mojo such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. was (Author: jfallows): The requirement for deployment to Maven Central is to always produce a javadoc JAR, empty or otherwise. If a project initially has only internal (excluded) packages and therefore no javadoc JAR, the deployment fails. One of the most straightforward solutions would be to include a boolean flag on the javadoc:jar mojo such as "skipIfEmpty" and default to true for backwards compatibility. Projects deploying to Maven Central could simply configure "skipIfEmpty" to false. The proposal to use assembly plugin could be made to work but creates churn on the POM as the project evolves to include sources that require actual javadoc. > Allow generation of empty javadoc JARs > -- > > Key: MJAVADOC-329 > URL: https://jira.codehaus.org/browse/MJAVADOC-329 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Vincent Massol > > Here's my use case: > * I want to be able to deploy my artifacts to Maven Central. There's a > requirement that a javadoc jar exists for the arifact to deploy > * However I have some maven modules of type packaging = jar that have java > files but these files are located in an "internal" package (internal api that > we don't expose to end users since it's not part of our public API contract) > which we exclude from the javadoc generation > The problem is that the javadoc plugin doesn't generate any JAR if there are > no java files matching (even if I have other files such as a package.html > file in my src/main/javadoc/* directories). > I'd like it to be possible to generate an "empty" javadoc JAR containing only > a package.html file for example. > Thanks a lot -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-862) excludedGroups property does not work with JUnit
[
https://jira.codehaus.org/browse/SUREFIRE-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362753#comment-362753
]
Elad Tabak commented on SUREFIRE-862:
-
I'm using TestNG which configuration is a bit different. The excluded groups
are strings, and the test classes are annotated with @Test(groups = {"slow"})
> excludedGroups property does not work with JUnit
>
>
> Key: SUREFIRE-862
> URL: https://jira.codehaus.org/browse/SUREFIRE-862
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Windows, Maven 3.0.3
>Reporter: Rene Grohmann
>Assignee: Kristian Rosenvold
> Fix For: 2.12.3
>
>
> If i use the groups property in my maven configuration everything works how
> expected. The plugin only selects the tests with the specific category. On
> the other Hand, if i use the excludedGroups property the plugin could not
> find any tests to run.
>
> maven-surefire-plugin
> 2.11
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.12
>
>
>
> de.test.junit.categories.IntegrationTest
>
>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-862) excludedGroups property does not work with JUnit
[ https://jira.codehaus.org/browse/SUREFIRE-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362754#comment-362754 ] Tibor Digana commented on SUREFIRE-862: --- @Elad TestNG 6.x is more buggy than 5.7.x. Can you identify version of TestNG, and version of surefire where it is working and where it's not. We would need project to reproduce the bug if it is our bug. > excludedGroups property does not work with JUnit > > > Key: SUREFIRE-862 > URL: https://jira.codehaus.org/browse/SUREFIRE-862 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12 > Environment: Windows, Maven 3.0.3 >Reporter: Rene Grohmann >Assignee: Kristian Rosenvold > Fix For: 2.12.3 > > > If i use the groups property in my maven configuration everything works how > expected. The plugin only selects the tests with the specific category. On > the other Hand, if i use the excludedGroups property the plugin could not > find any tests to run. > > maven-surefire-plugin > 2.11 > > > org.apache.maven.surefire > surefire-junit47 > 2.12 > > > > de.test.junit.categories.IntegrationTest > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-862) excludedGroups property does not work with JUnit
[
https://jira.codehaus.org/browse/SUREFIRE-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362753#comment-362753
]
Elad Tabak edited comment on SUREFIRE-862 at 2/8/15 2:34 AM:
-
I'm using TestNG which configuration is a bit different. The excluded groups
are strings, and the test classes are annotated with {code}@Test(groups =
{"slow"}){code}
was (Author: tzvatot):
I'm using TestNG which configuration is a bit different. The excluded groups
are strings, and the test classes are annotated with @Test(groups = {"slow"})
> excludedGroups property does not work with JUnit
>
>
> Key: SUREFIRE-862
> URL: https://jira.codehaus.org/browse/SUREFIRE-862
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Windows, Maven 3.0.3
>Reporter: Rene Grohmann
>Assignee: Kristian Rosenvold
> Fix For: 2.12.3
>
>
> If i use the groups property in my maven configuration everything works how
> expected. The plugin only selects the tests with the specific category. On
> the other Hand, if i use the excludedGroups property the plugin could not
> find any tests to run.
>
> maven-surefire-plugin
> 2.11
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.12
>
>
>
> de.test.junit.categories.IntegrationTest
>
>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
