[jira] [Reopened] (DOXIA-203) Add support for level 6 sections and generalize Sink API for sections
[ https://issues.apache.org/jira/browse/DOXIA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol reopened DOXIA-203: -- Still valid > Add support for level 6 sections and generalize Sink API for sections > - > > Key: DOXIA-203 > URL: https://issues.apache.org/jira/browse/DOXIA-203 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Massol > > XWiki supports 6 levels (see > http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax) and thus I cannot > write a valid parser if the Sink API doesn't support a level 6. > I'd even suggest to unify all sink method for sections into a single method > with a level parameter passed instead of having sectionTitle1(), etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNGSITE-151) Document how to use our Checkstyle rules from within an IDE
[ https://issues.apache.org/jira/browse/MNGSITE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733422#comment-14733422 ] Michael Osipov commented on MNGSITE-151: What about http://eclipse-cs.sourceforge.net/? Can't we build on top? > Document how to use our Checkstyle rules from within an IDE > --- > > Key: MNGSITE-151 > URL: https://issues.apache.org/jira/browse/MNGSITE-151 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Dennis Lundberg > > This will require using a plugin for the IDE that in turn can be told to use > our maven_checks.xml configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DOXIA-207) Add events for recognizing words in the Sink API
[ https://issues.apache.org/jira/browse/DOXIA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol reopened DOXIA-207: -- Still valid > Add events for recognizing words in the Sink API > > > Key: DOXIA-207 > URL: https://issues.apache.org/jira/browse/DOXIA-207 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Massol > > See > http://www.nabble.com/Need-for-onWords-events-%28and-more%29--td14557242.html#a14557242 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MENFORCER-240) Link to page does not work
Karl Heinz Marbaise created MENFORCER-240: - Summary: Link to page does not work Key: MENFORCER-240 URL: https://issues.apache.org/jira/browse/MENFORCER-240 Project: Maven Enforcer Plugin Issue Type: Bug Components: Documentation Affects Versions: 1.4.1 Reporter: Karl Heinz Marbaise Priority: Minor Fix For: 1.4.2 http://maven.apache.org/enforcer/enforcer-api/index.html The link in the left navigation bar "Maven Enforcer Plugin" is not correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MCHECKSTYLE-304) Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MCHECKSTYLE-304:
---
Fix Version/s: 2.17
> Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
> --
>
> Key: MCHECKSTYLE-304
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-304
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check, checkstyle:checkstyle
>Affects Versions: 2.16
> Environment: Windows, Maven 3.3.3
>Reporter: Pierre Maréchal
>Assignee: Michael Osipov
> Fix For: 2.17
>
>
> Using a slightly modified version of google_checks.xml as inline
> configuration, checkstyle:check fails with the following XML validation error
> :
> unable to parse configuration stream - Element type "message" must be
> declared.
> Looking at the generated checkstyle-checker.xml, it still uses
> {code:xml}
> "http://www.puppycrawl.com/dtds/configuration_1_2.dtd;>
> {code}
> where it should be
> {code:xml}
>"-//Puppy Crawl//DTD Check Configuration 1.3//EN"
> "http://www.puppycrawl.com/dtds/configuration_1_3.dtd;>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733631#comment-14733631 ] ASF GitHub Bot commented on MNG-5297: - Github user josephw commented on the pull request: https://github.com/apache/maven/pull/51#issuecomment-138286028 @kwin, @mosabua - is this current form acceptable as a fix? > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Priority: Minor > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-307) Upgrade to Checkstyle 6.9
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733542#comment-14733542
]
Michael Osipov commented on MCHECKSTYLE-307:
Intermediate upgrade to Checkstyle 6.3 in
[r1701605|http://svn.apache.org/r1701605]. Problem with {{fileExtensions}} have
been resolve in the IT.
I am waiting now for the GitHub issue to be resolved. [~romani], can we make
some progress here?
> Upgrade to Checkstyle 6.9
> -
>
> Key: MCHECKSTYLE-307
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-307
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 2.16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Hi folks,
> I have upraded Checkstyle locally and almost all ITs pass except for the
> issues [~denn...@apache.org] already has described:
> {quote}
> Changes in Checkstyle 6.3 that impact this plugin:
> * The IT MCHECKSTYLE-214-basedir-resource fails after upgrade to Checkstyle
> 6.3 with NPE - I have not found a solution for this yet
> Changes in Checkstyle 6.6 that impact this plugin:
> * DefaultLogger( OutputStream, boolean ) now throws
> UnsupportedEncodingException - this is easy to fix
> {quote}
> The first issue is caused because the default checkfiles apply to specific
> file extensions now, so IT for MCHECKSTYLE-214. [~rfscholte], what do you
> think about it. We can invert the test or add a custom {{sun_checks.xml}}.
> The second one can be fixed with the linked GH issue.
> I am willing to promote a release if I get some help to resolve the issues
> above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MCHECKSTYLE-304) Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MCHECKSTYLE-304:
--
Assignee: Michael Osipov
> Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
> --
>
> Key: MCHECKSTYLE-304
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-304
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check, checkstyle:checkstyle
>Affects Versions: 2.16
> Environment: Windows, Maven 3.3.3
>Reporter: Pierre Maréchal
>Assignee: Michael Osipov
> Fix For: 2.17
>
>
> Using a slightly modified version of google_checks.xml as inline
> configuration, checkstyle:check fails with the following XML validation error
> :
> unable to parse configuration stream - Element type "message" must be
> declared.
> Looking at the generated checkstyle-checker.xml, it still uses
> {code:xml}
> "http://www.puppycrawl.com/dtds/configuration_1_2.dtd;>
> {code}
> where it should be
> {code:xml}
>"-//Puppy Crawl//DTD Check Configuration 1.3//EN"
> "http://www.puppycrawl.com/dtds/configuration_1_3.dtd;>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MDEP-501) Filtering dependencies does not retain the order of the unfiltered list
Beirtí Ó'Nunáin created MDEP-501: Summary: Filtering dependencies does not retain the order of the unfiltered list Key: MDEP-501 URL: https://issues.apache.org/jira/browse/MDEP-501 Project: Maven Dependency Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Beirtí Ó'Nunáin If you use the build-classpath mojo, you get the dependency list as specified in the pom. However, if you introduce filtering, you end up losing the dependency order. It seems that the org.apache.maven.shared.artifact.filter.collection.ArtifactsFilter declares 'Set' instead of 'SortedSet' and that the org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter returns a HashSet instead of a LinkedHashSet, even though a LinkedHashSet is being passed in. The impact of this is that you cannot generate a correctly-ordered classpath when using filters. The fix is very straightforward, simply change the filterIncludes and filterExcludes methods of AbstractArtifactFeatureFilter to use a LinkedHashSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MDEP-501) Filtering dependencies does not retain the order of the unfiltered list
[
https://issues.apache.org/jira/browse/MDEP-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733627#comment-14733627
]
Beirtí Ó'Nunáin commented on MDEP-501:
--
Index: AbstractArtifactFeatureFilter.java
===
--- AbstractArtifactFeatureFilter.java (revision 1701613)
+++ AbstractArtifactFeatureFilter.java (working copy)
@@ -20,7 +20,7 @@
*/
import java.util.Arrays;
-import java.util.HashSet;
+import java.util.LinkedHashSet;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
@@ -83,7 +83,7 @@
*/
private Set filterIncludes( Set artifacts, List theIncludes )
{
-Set result = new HashSet();
+Set result = new LinkedHashSet();
Iterator includeIter = theIncludes.iterator();
while ( includeIter.hasNext() )
@@ -116,7 +116,7 @@
*/
private Set filterExcludes( Set artifacts, List theExcludes )
{
-Set result = new HashSet();
+Set result = new LinkedHashSet();
Iterator iter = artifacts.iterator();
while ( iter.hasNext() )
> Filtering dependencies does not retain the order of the unfiltered list
> ---
>
> Key: MDEP-501
> URL: https://issues.apache.org/jira/browse/MDEP-501
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Beirtí Ó'Nunáin
>
> If you use the build-classpath mojo, you get the dependency list as specified
> in the pom. However, if you introduce filtering, you end up losing the
> dependency order. It seems that the
> org.apache.maven.shared.artifact.filter.collection.ArtifactsFilter declares
> 'Set' instead of 'SortedSet' and that the
> org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter
> returns a HashSet instead of a LinkedHashSet, even though a LinkedHashSet is
> being passed in.
> The impact of this is that you cannot generate a correctly-ordered classpath
> when using filters. The fix is very straightforward, simply change the
> filterIncludes and filterExcludes methods of AbstractArtifactFeatureFilter to
> use a LinkedHashSet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733689#comment-14733689 ] ASF GitHub Bot commented on MNG-5297: - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/51#issuecomment-138295450 No. The enforcer plugin is for build-time enforcement. The element is for runtime enforcement. We certainly don't want to have to inspect the any plugin configuration elements to help Maven know that the current environment won't run the plugin. Also, if we ever get around to having the build vs consumption POM this information would not be available at all. > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Priority: Minor > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733874#comment-14733874 ] Michael Osipov commented on SUREFIRE-528: - If you don't care, there is no need to reopen it. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[
https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733885#comment-14733885
]
Martin Todorov commented on MRELEASE-649:
-
As I haven't seen a fix for this, I assume it is still not working.
The very simplest way to test it would be to either define a {{}} in a
{{}} (or not even necessarily inside one). Set it's version
to a SNAPSHOT.
I believe the same was valid for SNAPSHOT dependencies of plugins as well.
> release:prepare - ignores SNAPSHOT version in pluginManagement section
> --
>
> Key: MRELEASE-649
> URL: https://issues.apache.org/jira/browse/MRELEASE-649
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
>Reporter: Marcus Linke
>
> When release prepare a project with a pom.xml that defines a SNAPSHOT version
> in its section, the plugin should detect that and ask the
> user for the release version as is does it for dependencies versions already.
> This is especially needed if the project to be released is of package type
> 'pom' and acts as a parent pom for other projects. Otherwise this raises an
> error later when try to release one of these child projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733832#comment-14733832 ] Michael Osipov commented on SUREFIRE-528: - If you feel strong about this, provide a PR. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733835#comment-14733835 ] Martin Todorov commented on MRELEASE-649: - I don't have the permissions to do so, but I still believe this is a valid request that needs to be addressed. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MCHECKSTYLE-304) Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov resolved MCHECKSTYLE-304.
Resolution: Fixed
Fixed with [r1701637|http://svn.apache.org/r1701637].
> Using inline configuration, checkstyle-checker.xml is generated using DTD v1.2
> --
>
> Key: MCHECKSTYLE-304
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-304
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check, checkstyle:checkstyle
>Affects Versions: 2.16
> Environment: Windows, Maven 3.3.3
>Reporter: Pierre Maréchal
>Assignee: Michael Osipov
> Fix For: 2.17
>
>
> Using a slightly modified version of google_checks.xml as inline
> configuration, checkstyle:check fails with the following XML validation error
> :
> unable to parse configuration stream - Element type "message" must be
> declared.
> Looking at the generated checkstyle-checker.xml, it still uses
> {code:xml}
> "http://www.puppycrawl.com/dtds/configuration_1_2.dtd;>
> {code}
> where it should be
> {code:xml}
>"-//Puppy Crawl//DTD Check Configuration 1.3//EN"
> "http://www.puppycrawl.com/dtds/configuration_1_3.dtd;>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733858#comment-14733858 ] Emmanuel Lecharny commented on SUREFIRE-528: I don't care. If you feel it's not important, or don't have time to fix it, then close the issue, but please, explain *why* you close the issue, instead of purging your bug tracking system from all the issues that have died because you didn't had time to fix them or discard them properly. And please, don't PR me. This is not the way OSS works. Respect your users. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733852#comment-14733852 ] Michael Osipov commented on MRELEASE-649: - If you can provide a way to reproduce with recent versions, I will gladly reopen this issue. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733884#comment-14733884 ] Emmanuel Lecharny commented on SUREFIRE-528: I *do* care to have an issue I have opened being close for a stupid reason. I don't care that it's closed for a valid reason. If you think that Surefire output, where you have hundreds of files mixing success and failures without any indication of what is a failure and what is a success, is just fine, be my hguest, this is your project, not mine. Or you can also consider that my request is important from a user experience POV. That's your decision to make. In any case, please don't close it just because it's 2 years old. Say that it's a frivolous request, or too costly to implement, or whatever reason; > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733700#comment-14733700 ] ASF GitHub Bot commented on MNG-5297: - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/51#issuecomment-138297887 I'm reasonably sure it's never been used for build-time enforcement. Anything to make it clear that the enforcer is for build-time and the prerequisite element is for runtime is good. > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Priority: Minor > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny reopened SUREFIRE-528: Next time you don't want to fix an issue, just say so instead of saying it was just laying down for too long and thus need to be closed... > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733694#comment-14733694 ] ASF GitHub Bot commented on MNG-5297: - Github user josephw commented on the pull request: https://github.com/apache/maven/pull/51#issuecomment-138297080 @jvanzyl although the original change was unconditional deprecation, I changed it after comments so the current language in the patch is intended to reflect that distinction: > For a plugin project, the minimum version of Maven required to use the resulting plugin. > For specifying the minimum version of Maven required to build a project, this element is deprecated. My intention here is to make clear that it's deprecated for *some* purposes. > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Priority: Minor > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733698#comment-14733698
]
ASF GitHub Bot commented on MNG-5837:
-
Github user josephw commented on the pull request:
https://github.com/apache/maven/pull/50#issuecomment-138297741
@birkedal, does this change look okay after the switch to backticks? Or, if
you're a Solaris user, does that other idiom seem better?
> Syntax error in bin/mvn on Solaris SPARC
>
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `('
> unexpected{code}
> Looks like similas issues as in MNG-5658
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733782#comment-14733782 ] Martin Todorov commented on MRELEASE-649: - [~michael-o], Was this ever fixed? This is a serious issue. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNGSITE-151) Document how to use our Checkstyle rules from within an IDE
[ https://issues.apache.org/jira/browse/MNGSITE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733739#comment-14733739 ] Dennis Lundberg commented on MNGSITE-151: - Sure, the idea with this issue is to create instructions for the most popular IDEs, and their respective plugins for Checkstyle, so that we can use *our* settings for Checkstyle in them. > Document how to use our Checkstyle rules from within an IDE > --- > > Key: MNGSITE-151 > URL: https://issues.apache.org/jira/browse/MNGSITE-151 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Dennis Lundberg > > This will require using a plugin for the IDE that in turn can be told to use > our maven_checks.xml configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733830#comment-14733830 ] Michael Osipov commented on MRELEASE-649: - As laid out in the close comment, the creator of this ticket or you are invited to retest this issue and reopen it. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1176) Maven surefire plugin sets systemPropertyVariables too late
[
https://issues.apache.org/jira/browse/SUREFIRE-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733945#comment-14733945
]
Tibor Digana commented on SUREFIRE-1176:
[~matihost]
I only want to know if you can help yourself and use configuration
parameter.
Unfortunately I cannot rewrite JVM so you have to make the choice in POM
configuration or in code.
Do you agree with me to close this?
If you have some wish we can help you.
> Maven surefire plugin sets systemPropertyVariables too late
> ---
>
> Key: SUREFIRE-1176
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1176
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Mateusz Nowakowski
>
> I have a couple of test which need to be run under specific locale.
> It is achieved by this surefire plugin configuration:
> Under Java 7 this plugin configuration works:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.18.1
>
>
> America/Chicago
>
>
>
> {code}
> but under Java 8 the test sensitive test still uses default system locale and
> they fail.
> Surefire plugin sets system properties too late, because in Java 8, several
> locale-dependent variables are set much earlier than in Java 7, e.g.
> TimeZone.getDefault() and
> properties specified in systemPropertyVariables section don't have influence
> on tests.
> Workaround for it is setting system properties in argLine section, e.g.
> -Duser.timezone=America/Chicago.
> Workaround:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.18.1
>
> -Duser.timezone=America/Chicago
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-307) Upgrade to Checkstyle 6.10.1+
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733949#comment-14733949
]
Michael Osipov commented on MCHECKSTYLE-307:
After applying the PR to Checkstyle master and trying with 6.11-SNAPSHOT, all
ITs pass except for MCHECKSTYLE-268. It seems like the Google checks have been
expanded and there are three instead of two violations now. I will modify
{{verify.groovy}} as soon as 6.11 is out.
> Upgrade to Checkstyle 6.10.1+
> -
>
> Key: MCHECKSTYLE-307
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-307
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 2.16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Hi folks,
> I have upraded Checkstyle locally and almost all ITs pass except for the
> issues [~denn...@apache.org] already has described:
> {quote}
> Changes in Checkstyle 6.3 that impact this plugin:
> * The IT MCHECKSTYLE-214-basedir-resource fails after upgrade to Checkstyle
> 6.3 with NPE - I have not found a solution for this yet
> Changes in Checkstyle 6.6 that impact this plugin:
> * DefaultLogger( OutputStream, boolean ) now throws
> UnsupportedEncodingException - this is easy to fix
> {quote}
> The first issue is caused because the default checkfiles apply to specific
> file extensions now, so IT for MCHECKSTYLE-214. [~rfscholte], what do you
> think about it. We can invert the test or add a custom {{sun_checks.xml}}.
> The second one can be fixed with the linked GH issue.
> I am willing to promote a release if I get some help to resolve the issues
> above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733951#comment-14733951 ] Tibor Digana commented on SUREFIRE-528: --- [~elecharny] :)) We want to provide the fix in surefire 3.0. That's the reason we have related issue SUREFIRE-726 still open. This issue will won't be forgotten because it's part of Test List Processor in SUREFIRE-726. I don't mind if this is close, I can see what's behind of 726. Surefire is walking through a big rework in 2.19 which was done to get to more stable 3.0. We have a prototype of 3.0 in a branch and I want to release an experimental release of 3.0 in 2.20 with limited features. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733954#comment-14733954 ] Michael Osipov commented on SUREFIRE-528: - [~tibor17], can you kindly target this issue and set appropriate links to dependent issues. It should make the issue much more clearer. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1176) Maven surefire plugin sets systemPropertyVariables too late
[
https://issues.apache.org/jira/browse/SUREFIRE-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733900#comment-14733900
]
Mateusz Nowakowski commented on SUREFIRE-1176:
--
It depends what perspective we choose.
We can say that the surefire plugin has a feature to change system feature by
changing system properties by its custom configuration systemPropertyVariables.
So in this case surefire can call TimeZone.setDefault(null) before changing
system properties - making user.timezone property working as expected.
Or we can also say that surefire only changes system properties, but it should
not be used to change system properties indicating some JVM features.
The first one is easier from client perspective.
> Maven surefire plugin sets systemPropertyVariables too late
> ---
>
> Key: SUREFIRE-1176
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1176
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Mateusz Nowakowski
>
> I have a couple of test which need to be run under specific locale.
> It is achieved by this surefire plugin configuration:
> Under Java 7 this plugin configuration works:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.18.1
>
>
> America/Chicago
>
>
>
> {code}
> but under Java 8 the test sensitive test still uses default system locale and
> they fail.
> Surefire plugin sets system properties too late, because in Java 8, several
> locale-dependent variables are set much earlier than in Java 7, e.g.
> TimeZone.getDefault() and
> properties specified in systemPropertyVariables section don't have influence
> on tests.
> Workaround for it is setting system properties in argLine section, e.g.
> -Duser.timezone=America/Chicago.
> Workaround:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.18.1
>
> -Duser.timezone=America/Chicago
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MRELEASE-649: - Martin, I am reoping this on your request but do not expect that someone will pick this up anytime soon. I'd still like to urge to retest this with a sample project. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733904#comment-14733904 ] Michael Osipov commented on SUREFIRE-528: - I am not judging your issue and I won't. No one took this on for more than two years and it is highly unlikely that someone ever will. It was just a routine issue cleanup. Nothing more, nothing less. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-529) Add macro support to XHTML
[ https://issues.apache.org/jira/browse/DOXIA-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734095#comment-14734095 ] Masatake Iwasaki commented on DOXIA-529: ping: I will appreciate reviewer's comment for this. > Add macro support to XHTML > --- > > Key: DOXIA-529 > URL: https://issues.apache.org/jira/browse/DOXIA-529 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Xhtml >Reporter: Masatake Iwasaki > Attachments: DOXIA-529.001.patch > > > Adding macro support to XhtmlParser. It could be used by MarkdownParser which > uses XHTML as intermediate format for conversion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734036#comment-14734036 ] Dan Tran commented on MRELEASE-649: --- this a known issue, never been fixed. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ https://issues.apache.org/jira/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734041#comment-14734041 ] Emmanuel Lecharny commented on SUREFIRE-528: Thanks Tibor. > Splitting tests names in two categories : success and failure > - > > Key: SUREFIRE-528 > URL: https://issues.apache.org/jira/browse/SUREFIRE-528 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.0 (2.2 plugin) >Reporter: Emmanuel Lecharny > > We have to check all the *.txt files to find the ones which contain some > errors. The fact that failed tests are listed before does not help a lot when > you have hundred of tests run with sometime lot of logs. > I would rather propose that we either create two sub-directories > (failure/success) or that we postfix tests. > A good example : > ... > Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the > individual test results. > ... > Would be better to have : > Please refer to > /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for > the individual test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MINVOKER-194) wrong maven.compiler.source value in pom interpolation when run with Maven 3.3.x
[
https://issues.apache.org/jira/browse/MINVOKER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MINVOKER-194.
--
Resolution: Not A Problem
no bug here, just unknown parameter in parent pom that only works with Maven 3.3
> wrong maven.compiler.source value in pom interpolation when run with Maven
> 3.3.x
>
>
> Key: MINVOKER-194
> URL: https://issues.apache.org/jira/browse/MINVOKER-194
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8, 2.0.0
>Reporter: Hervé Boutemy
>
> when working on MPIR, I found that java-version IT failed when build run with
> with Maven 3.3.x, but not when run with Maven 3.2.x or less
> I found that
> {code:xml}
> 1.3
> ${maven.compiler.source}
> {code}
> is interpolated to
> {code:xml}
> 1.3
> 1.5
> {code}
> when the IT is run with Maven 3.3.x
> but when the IT project is not run through invoker, there is no such
> interpolation value issue, so I suppose m-invoker-p has some role when used
> in conjunction with Maven 3.3.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MCHECKSTYLE-307) Upgrade to Checkstyle 6.10.1+
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MCHECKSTYLE-307:
---
Summary: Upgrade to Checkstyle 6.10.1+ (was: Upgrade to Checkstyle 6.9)
> Upgrade to Checkstyle 6.10.1+
> -
>
> Key: MCHECKSTYLE-307
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-307
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 2.16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Hi folks,
> I have upraded Checkstyle locally and almost all ITs pass except for the
> issues [~denn...@apache.org] already has described:
> {quote}
> Changes in Checkstyle 6.3 that impact this plugin:
> * The IT MCHECKSTYLE-214-basedir-resource fails after upgrade to Checkstyle
> 6.3 with NPE - I have not found a solution for this yet
> Changes in Checkstyle 6.6 that impact this plugin:
> * DefaultLogger( OutputStream, boolean ) now throws
> UnsupportedEncodingException - this is easy to fix
> {quote}
> The first issue is caused because the default checkfiles apply to specific
> file extensions now, so IT for MCHECKSTYLE-214. [~rfscholte], what do you
> think about it. We can invert the test or add a custom {{sun_checks.xml}}.
> The second one can be fixed with the linked GH issue.
> I am willing to promote a release if I get some help to resolve the issues
> above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-501) Filtering dependencies does not retain the order of the unfiltered list
[ https://issues.apache.org/jira/browse/MDEP-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14733622#comment-14733622 ] Beirtí Ó'Nunáin commented on MDEP-501: -- I noticed that there is a separate jira for the maven common artifact filters project, but will leave it up to the admin's of this project to decide placement as I suspect the impact of non-ordered filtering is mostly on the classpath mojos. > Filtering dependencies does not retain the order of the unfiltered list > --- > > Key: MDEP-501 > URL: https://issues.apache.org/jira/browse/MDEP-501 > Project: Maven Dependency Plugin > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Beirtí Ó'Nunáin > > If you use the build-classpath mojo, you get the dependency list as specified > in the pom. However, if you introduce filtering, you end up losing the > dependency order. It seems that the > org.apache.maven.shared.artifact.filter.collection.ArtifactsFilter declares > 'Set' instead of 'SortedSet' and that the > org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter > returns a HashSet instead of a LinkedHashSet, even though a LinkedHashSet is > being passed in. > The impact of this is that you cannot generate a correctly-ordered classpath > when using filters. The fix is very straightforward, simply change the > filterIncludes and filterExcludes methods of AbstractArtifactFeatureFilter to > use a LinkedHashSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MENFORCER-234) Link to plugin's web site is reported as redirected by maven linkcheck plugin.
[ https://issues.apache.org/jira/browse/MENFORCER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-234: -- Fix Version/s: (was: 2.0) 1.4.2 > Link to plugin's web site is reported as redirected by maven linkcheck plugin. > -- > > Key: MENFORCER-234 > URL: https://issues.apache.org/jira/browse/MENFORCER-234 > Project: Maven Enforcer Plugin > Issue Type: Bug >Affects Versions: 1.4 > Environment: maven enforcer plugin, checkstyle >Reporter: Andrei Selkin >Assignee: Tibor Digana > Fix For: 1.4.2 > > > Hello! > We use maven linkcheck plugin to check links on checkstyle's website: > http://checkstyle.sourceforge.net/ . The plugin reports that on page > http://checkstyle.sourceforge.net/plugins.html the following link is > redirected: > http://maven.apache.org/enforcer/maven-enforcer-plugin (301 Moved > Permanently) at > http://maven.apache.org/components/enforcer/maven-enforcer-plugin/ . > Links on plugins.html are generated by Apache Maven Project Info Reports > Plugin. All URLs are grabbed from effective POMs of plugins. > Here is the code: > https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L239 > https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L269 > In effective POM of maven enforcer plugin the problematic link is: > http://maven.apache.org/enforcer/maven-enforcer-plugin > Should be: > http://maven.apache.org/components/enforcer/maven-enforcer-plugin/ > As a result, we do not have an ability to change plugins urls on that page, > because those links are specified by plugins developers. > So, please correct the link, because there are contradictions between > linkcheck and maven enforcer plugin. > Thank in advance! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MENFORCER-240) Link to page does not work
[ https://issues.apache.org/jira/browse/MENFORCER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-240. - Resolution: Fixed Assignee: Karl Heinz Marbaise Fixed in [r1701670|http://svn.apache.org/r1701670] > Link to page does not work > -- > > Key: MENFORCER-240 > URL: https://issues.apache.org/jira/browse/MENFORCER-240 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Affects Versions: 1.4.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2 > > > http://maven.apache.org/enforcer/enforcer-api/index.html The link in the left > navigation bar "Maven Enforcer Plugin" is not correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MENFORCER-228) DependencyConvergence: Simplify logging errors
[
https://issues.apache.org/jira/browse/MENFORCER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-228.
-
Resolution: Fixed
Fixed in [r1701672|http://svn.apache.org/r1701672]
> DependencyConvergence: Simplify logging errors
> --
>
> Key: MENFORCER-228
> URL: https://issues.apache.org/jira/browse/MENFORCER-228
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2; Oracle JDK 8
>Reporter: Stephan Krull
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4.2
>
>
> The dependency convergence rule check works great. I just wonder if it is
> really necessary to log the according error messages two times:
> see source code
> http://svn.apache.org/viewvc/maven/enforcer/tags/1.4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup
> {code:title=lines 127 to 134}
> for ( CharSequence errorMsg : errorMsgs )
> {
> log.warn( errorMsg );
> }
> if ( errorMsgs.size() > 0 )
> {
> throw new EnforcerRuleException( "Failed while enforcing releasability
> the error(s) are " + errorMsgs );
> }
> {code}
> this produces outputs like:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4:enforce (enforce dependency convergence)
> @ bom ---
> [WARNING]
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> [WARNING]
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> ,
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> ]
> {noformat}
> the warning log messages are identical to the messages of the exception. so
> just skip one of the outputs if possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MNG-5649) Stop abusing IllegalArgumentException in case of null
[
https://issues.apache.org/jira/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5649:
---
Assignee: Michael Osipov
> Stop abusing IllegalArgumentException in case of null
> -
>
> Key: MNG-5649
> URL: https://issues.apache.org/jira/browse/MNG-5649
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> In several spots of Maven Core, IAE is thrown where an argument is null. This
> should be turned into {{NullPointerException}} since JDK adheres to is and
> the
> [description|http://docs.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html]
> of this exception indicates that and Effective Java does that too.
> I possible fix version could next minor: 3.3. Is no one is opposed it could
> even be 3.2.2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MENFORCER-228) DependencyConvergence: Simplify logging errors
[
https://issues.apache.org/jira/browse/MENFORCER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-228:
--
Fix Version/s: (was: more-investigation)
1.4.2
> DependencyConvergence: Simplify logging errors
> --
>
> Key: MENFORCER-228
> URL: https://issues.apache.org/jira/browse/MENFORCER-228
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2; Oracle JDK 8
>Reporter: Stephan Krull
>Priority: Minor
> Fix For: 1.4.2
>
>
> The dependency convergence rule check works great. I just wonder if it is
> really necessary to log the according error messages two times:
> see source code
> http://svn.apache.org/viewvc/maven/enforcer/tags/1.4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup
> {code:title=lines 127 to 134}
> for ( CharSequence errorMsg : errorMsgs )
> {
> log.warn( errorMsg );
> }
> if ( errorMsgs.size() > 0 )
> {
> throw new EnforcerRuleException( "Failed while enforcing releasability
> the error(s) are " + errorMsgs );
> }
> {code}
> this produces outputs like:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4:enforce (enforce dependency convergence)
> @ bom ---
> [WARNING]
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> [WARNING]
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> ,
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> ]
> {noformat}
> the warning log messages are identical to the messages of the exception. so
> just skip one of the outputs if possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MENFORCER-228) DependencyConvergence: Simplify logging errors
[
https://issues.apache.org/jira/browse/MENFORCER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-228:
-
Assignee: Karl Heinz Marbaise
> DependencyConvergence: Simplify logging errors
> --
>
> Key: MENFORCER-228
> URL: https://issues.apache.org/jira/browse/MENFORCER-228
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2; Oracle JDK 8
>Reporter: Stephan Krull
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4.2
>
>
> The dependency convergence rule check works great. I just wonder if it is
> really necessary to log the according error messages two times:
> see source code
> http://svn.apache.org/viewvc/maven/enforcer/tags/1.4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup
> {code:title=lines 127 to 134}
> for ( CharSequence errorMsg : errorMsgs )
> {
> log.warn( errorMsg );
> }
> if ( errorMsgs.size() > 0 )
> {
> throw new EnforcerRuleException( "Failed while enforcing releasability
> the error(s) are " + errorMsgs );
> }
> {code}
> this produces outputs like:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4:enforce (enforce dependency convergence)
> @ bom ---
> [WARNING]
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> [WARNING]
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> ,
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> ]
> {noformat}
> the warning log messages are identical to the messages of the exception. so
> just skip one of the outputs if possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
