[jira] (ARCHETYPE-469) Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml?
[ https://jira.codehaus.org/browse/ARCHETYPE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siva Prasad updated ARCHETYPE-469: -- Attachment: (was: pom.xml) Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml? - Key: ARCHETYPE-469 URL: https://jira.codehaus.org/browse/ARCHETYPE-469 Project: Maven Archetype Issue Type: Task Components: Archetypes, Plugin Reporter: Siva Prasad Attachments: consolelogEclipse.txt I have done a check out from svn as in Eclipse(luna) as Checkout Maven Project as SCM.After doing that i am getting g error in pom.xml.How to resolve the error.?Below is the error...Please verifiy the attached file.How to resole this error and what it means.? Thank you... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-469) Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml?
[ https://jira.codehaus.org/browse/ARCHETYPE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siva Prasad updated ARCHETYPE-469: -- Attachment: errormaven.png pom.xml Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml? - Key: ARCHETYPE-469 URL: https://jira.codehaus.org/browse/ARCHETYPE-469 Project: Maven Archetype Issue Type: Task Components: Archetypes, Plugin Reporter: Siva Prasad Attachments: consolelogEclipse.txt, errormaven.png, pom.xml I have done a check out from svn as in Eclipse(luna) as Checkout Maven Project as SCM.After doing that i am getting g error in pom.xml.How to resolve the error.?Below is the error...Please verifiy the attached file.How to resole this error and what it means.? Thank you... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-469) Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml?
Siva Prasad created ARCHETYPE-469: - Summary: Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml? Key: ARCHETYPE-469 URL: https://jira.codehaus.org/browse/ARCHETYPE-469 Project: Maven Archetype Issue Type: Task Components: Archetypes, Plugin Reporter: Siva Prasad Attachments: consolelogEclipse.txt, pom.xml I have done a check out from svn as in Eclipse(luna) as Checkout Maven Project as SCM.After doing that i am getting g error in pom.xml.How to resolve the error.?Below is the error...Please verifiy the attached file.How to resole this error and what it means.? Thank you... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-410) Get the stylesheet file from an URL
[
https://jira.codehaus.org/browse/MJAVADOC-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361083#comment-361083
]
Vincent Zurczak commented on MJAVADOC-410:
--
Hi,
Any news about this?
{quote}If the external source changes, or is removed, your build will change
and/or fail.{quote}
If my build fails, I know I will have to fix something.
And in this case, the external resource. That's all. And if for some reason,
the URL changed, I will update my build in consequence to point to another URL.
Get the stylesheet file from an URL
---
Key: MJAVADOC-410
URL: https://jira.codehaus.org/browse/MJAVADOC-410
Project: Maven Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.10
Reporter: Vincent Zurczak
Priority: Minor
Hi,
When we generate Javadoc with the maven-javadoc-plugin, we can use the
*stylesheetfile* parameter to specify a custom CSS file for the generated
HTML pages.
This file can be a local file, as well as a resource located in Maven
dependencies. However, it does not work if the parameter value is set to a
public URL (a static resource on a web server). This would be a nice
enhancement. Initially, I had created a Maven module that would contain such
resources, but it resulted in adding a lot of complexity to my release
process. Having some static resources on a web server is much more simple.
I wanted to submit a patch myself for this feature.
But I was wondering how I could do that. This
[page|http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch]
indicates we should attach a patch file to this issue. I was wondering if
proposing pull requests on the GitHub mirror was also working.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361091#comment-361091
]
Alexander Ashitkin edited comment on MNG-5750 at 1/12/15 7:35 AM:
--
The fix worked for me. 30 builds succesfull builds in sequence. Based on
previous expirience i expected at lesat 5 failures here with ~100% probability.
Could somebody please provide some feedback and advise on the code change?
thank you
was (Author: alex_ashitkin):
The fix worked for me. 30 builds succesfull builds in sequence. Based on
previous expirience i expected at leat 5 failures here. Could somebody please
provide some feedback and advise on the code change?
thank you
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361092#comment-361092
]
Jason van Zyl commented on MNG-5750:
It is always a good thing to run the integration tests with any patches. For
guidance you can look at:
http://takari.io/2014/06/01/contributing-to-maven-core.html
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361091#comment-361091
]
Alexander Ashitkin commented on MNG-5750:
-
The fix worked for me. 30 builds succesfull builds in sequence. Based on
previous expirience i expected at leat 5 failures here. Could somebody please
provide some feedback and advise on the issue?
thank you
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361095#comment-361095
]
Kristian Rosenvold commented on MNG-5750:
-
This issue seems to be a bit of a hot potato. We need to find a better
solution, and I'm afraid it has to be somewhat more long-term than what
Alexander proposes, although it's a nice POC.
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361091#comment-361091
]
Alexander Ashitkin edited comment on MNG-5750 at 1/12/15 7:26 AM:
--
The fix worked for me. 30 builds succesfull builds in sequence. Based on
previous expirience i expected at leat 5 failures here. Could somebody please
provide some feedback and advise on the code change?
thank you
was (Author: alex_ashitkin):
The fix worked for me. 30 builds succesfull builds in sequence. Based on
previous expirience i expected at leat 5 failures here. Could somebody please
provide some feedback and advise on the issue?
thank you
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upperlimits for comma-separated list of tests)
Paul Hammant created SUREFIRE-1134: -- Summary: Take list of tests from file (-Dtest has upperlimits for comma-separated list of tests) Key: SUREFIRE-1134 URL: https://jira.codehaus.org/browse/SUREFIRE-1134 Project: Maven Surefire Issue Type: New Feature Reporter: Paul Hammant Priority: Minor -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list of tests. There are upper limits to that in the context of command line arguments. Could we additionally have: -DtestListFile=testsToRun.txt Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking Maven. Refer http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361087#comment-361087
]
Kristian Rosenvold commented on SUREFIRE-1134:
--
@Andres @Tibor This sounds like a really nice POC for the extension points we
were talking about :)
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[ https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Hammant updated SUREFIRE-1134: --- Description: -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list of tests. There are upper limits to that in the context of command line arguments. Could we additionally have: -DtestListFile=testsToRun.txt Also for Failsafe: -Dit.testListFile=testsToRun.txt Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking Maven. Refer http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/ was: -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list of tests. There are upper limits to that in the context of command line arguments. Could we additionally have: -DtestListFile=testsToRun.txt Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking Maven. Refer http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/ Summary: Take list of tests from file (-Dtest has upper limits for comma-separated list of tests) (was: Take list of tests from file (-Dtest has upperlimits for comma-separated list of tests)) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests) Key: SUREFIRE-1134 URL: https://jira.codehaus.org/browse/SUREFIRE-1134 Project: Maven Surefire Issue Type: New Feature Reporter: Paul Hammant Priority: Minor -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list of tests. There are upper limits to that in the context of command line arguments. Could we additionally have: -DtestListFile=testsToRun.txt Also for Failsafe: -Dit.testListFile=testsToRun.txt Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking Maven. Refer http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Hammant updated SUREFIRE-1134:
---
Description:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list
of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn param}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn param}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
was:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list
of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
-DtestListFile=testsToRun.txt
Also for Failsafe:
-Dit.testListFile=testsToRun.txt
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn param}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn param}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Hammant updated SUREFIRE-1134:
---
Description:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list
of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
was:
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a list
of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn param}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn param}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361102#comment-361102
]
Jason van Zyl commented on MNG-5750:
I think we should have a dev hangout dedicated to performance monitoring and
testing. Part of this includes concurrency issues so that the system can go
fast in parallel. Igor and I will eventually have to deal with this in our
large build but we are alleviating this issue right now by using a file-based
repository. We will soon a repository manager based system and we'll have to
flush this out. Our timeframe is the next 12 weeks. But I think a hangout topic
would be good. We have a harness for perf that I would likely to employ as
standard part of our build.
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-191) Update to PMD 5.2.1
[ https://jira.codehaus.org/browse/MPMD-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361103#comment-361103 ] Mirko Friedenhagen commented on MPMD-191: - Thanks, Michael, http://svn.apache.org/r1651126 should help with this. Update to PMD 5.2.1 --- Key: MPMD-191 URL: https://jira.codehaus.org/browse/MPMD-191 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Andreas Dangel Assignee: Mirko Friedenhagen Fix For: 3.3 Changes in PMD: * http://pmd.sourceforge.net/pmd-5.2.1/overview/changelog.html * http://pmd.sourceforge.net/pmd-5.2.0/overview/changelog.html * http://pmd.sourceforge.net/pmd-5.1.3/changelog.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-756) Allow ability to capture executed random runOrder for re-play purposes
[ https://jira.codehaus.org/browse/SUREFIRE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361115#comment-361115 ] Tibor Digana commented on SUREFIRE-756: --- The solution would be to use the existing includesFile parameter. The excludesFile should not work together with runOrder. The functionality runOrder creates file name which starts with .surefire- in base dir. We can recognize the File name in the form of + .surefire-configurationHash or + .surefire-* and configurationHash will computed upon current plugin configuration. The format for files produced by runOrder and includesFile are different, we can load only the name of the test upon regognized file patter .surefire-* in base dir. Any objections to this concept? Allow ability to capture executed random runOrder for re-play purposes -- Key: SUREFIRE-756 URL: https://jira.codehaus.org/browse/SUREFIRE-756 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 2.9 Reporter: Joshua Spiewak Assignee: Tibor Digana Priority: Minor As a user of the runOrder=random feature, I would like to be able to capture a given ordering of tests and re-play that order, so that if a particular ordering exposes hidden dependencies between tests I can reproduce in my development environment, fix the problem, and then runs the tests again to confirm the fix. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-191) Update to PMD 5.2.1
[ https://jira.codehaus.org/browse/MPMD-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361118#comment-361118 ] Michael Osipov commented on MPMD-191: - Großartig, danke! Update to PMD 5.2.1 --- Key: MPMD-191 URL: https://jira.codehaus.org/browse/MPMD-191 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Andreas Dangel Assignee: Mirko Friedenhagen Fix For: 3.3 Changes in PMD: * http://pmd.sourceforge.net/pmd-5.2.1/overview/changelog.html * http://pmd.sourceforge.net/pmd-5.2.0/overview/changelog.html * http://pmd.sourceforge.net/pmd-5.1.3/changelog.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-469) analyze-report java.io.FileNotFoundException:
[
https://jira.codehaus.org/browse/MDEP-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361116#comment-361116
]
David Phillips commented on MDEP-469:
-
We see this error all the time, but for the analyze-only goal which we run in
the process-test-classes phase.
analyze-report java.io.FileNotFoundException:
-
Key: MDEP-469
URL: https://jira.codehaus.org/browse/MDEP-469
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 2.9
Reporter: jieryn
Apache Maven 3.2.3, multi-module project,
maven-dependency-plugin:analyze-report:2.9 throws FileNotFoundException
during site phase (same exact project and configuration but with 2.8 is
successful):
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
dao: Error generating maven-dependency-plugin:2.9:analyze-report: Cannot
analyze dependencies:
/var/lib/jenkins/jobs/site_com.acme.proj/workspace/domain/target/classes (Is
a directory) - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
project dao: Error generating maven-dependency-plugin:2.9:analyze-report:
Cannot analyze dependencies
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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.MojoExecutionException: Error generating
maven-dependency-plugin:2.9:analyze-report: Cannot analyze dependencies
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:146)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
generating maven-dependency-plugin:2.9:analyze-report: Cannot analyze
dependencies
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:182)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141)
... 21 more
Caused by: org.apache.maven.reporting.MavenReportException: Cannot analyze
dependencies
at
org.apache.maven.plugin.dependency.analyze.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:145)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:196)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:224)
... 25 more
Caused by:
org.apache.maven.shared.dependency.analyzer.ProjectDependencyAnalyzerException:
Cannot analyze dependencies
at
[jira] (MNG-5750) Sporadic failures in concurrent build
[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361121#comment-361121
]
Kristian Rosenvold commented on MNG-5750:
-
Please update this issue if the hangout comes to any noteworthy conclusion :)
Sporadic failures in concurrent build
-
Key: MNG-5750
URL: https://jira.codehaus.org/browse/MNG-5750
Project: Maven
Issue Type: Bug
Components: General
Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
HotSpot JDK 7u25
windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
Reporter: Alexander Ashitkin
Priority: Critical
We have a large project of 300+ modules which regularly fails with different
kind of errors in different places. The issue is reliably reproduced with
parallel build and is not happens in single threaded. The optimal concurrency
level for our project ~10 threads. At this level ~%20 of builds fail. To
workaround the issue we reduced concurrency to 4 in development builds and
reverted production build to 1 thread.
Main point of failures:
# Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
# Compiler - unexpected failure because of incorrect classpath (literally all
dependencies are not on the classpath), like: {code}
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
org.joda.time does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
import only from classes and interfaces
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
com.google.common.base does not exist
20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
import only from classes and interfaces
{code}
# Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
plusgin seems to be also affected)
At this point the issue looks like problem with MavenProject#getArtifacts in
concurrent builds.
To help with the issue im happy to implement or evaluate any custom assembly
to trace this down. Unfortunately i cannot submit my project - it is
proprietary.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1134:
--
Assignee: Tibor Digana
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Assignee: Tibor Digana
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361128#comment-361128
]
Damon Smith commented on MJAVADOC-408:
--
It's all very well to say remember to specify every version of every plugin
but I was not even aware that my release build was using the javadoc plugin!
About a year ago I painstakingly set up a full build with config for release,
signed artifacts, nexus repositories, deployment, everything was working well,
and then I come back, make some code changes and run a release and the javadoc
plugin (that I didn't even realise I was running and have no interest in) is
now breaking my entire build and requiring lots of investigation, changes to my
versions and pluginManagement config, all of the skip config from the command
line fails (I assume it's because it's a release build so the skip isn't passed
through). And there's no good documentation on how to even run the generate
javadoc step, let alone how to prevent it from running. The root cause of this
bug is that the release build runs javadoc by default and fails if it doesn't
work.
changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
-
Key: MJAVADOC-408
URL: https://jira.codehaus.org/browse/MJAVADOC-408
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
Reporter: Volker Seibt
Priority: Critical
Attachments: console.log, pom.xml, pom.xml
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361128#comment-361128
]
Damon Smith edited comment on MJAVADOC-408 at 1/12/15 5:13 PM:
---
It's all very well to say remember to specify every version of every plugin
but I was not even aware that my release build was using the javadoc plugin!
About a year ago I painstakingly set up a full build with config for release,
signed artifacts, nexus repositories, deployment, everything was working well,
and then I come back, make some code changes and run a release and the javadoc
plugin (that I didn't even realise I was running and have no interest in) is
now breaking my entire build and requiring lots of investigation, changes to my
versions and pluginManagement config, all of the skip config from the command
line fails (I assume it's because it's a release build so the skip isn't passed
through). And there's no good documentation on how to even run the generate
javadoc step, let alone how to prevent it from running.
was (Author: damonsmith):
It's all very well to say remember to specify every version of every plugin
but I was not even aware that my release build was using the javadoc plugin!
About a year ago I painstakingly set up a full build with config for release,
signed artifacts, nexus repositories, deployment, everything was working well,
and then I come back, make some code changes and run a release and the javadoc
plugin (that I didn't even realise I was running and have no interest in) is
now breaking my entire build and requiring lots of investigation, changes to my
versions and pluginManagement config, all of the skip config from the command
line fails (I assume it's because it's a release build so the skip isn't passed
through). And there's no good documentation on how to even run the generate
javadoc step, let alone how to prevent it from running. The root cause of this
bug is that the release build runs javadoc by default and fails if it doesn't
work.
changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
-
Key: MJAVADOC-408
URL: https://jira.codehaus.org/browse/MJAVADOC-408
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
Reporter: Volker Seibt
Priority: Critical
Attachments: console.log, pom.xml, pom.xml
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361138#comment-361138
]
Dennis Lundberg commented on MJAVADOC-408:
--
Damon,
The Release Plugin uses a special release profile that produces Javadoc and
Source artifacts for your project. This is enabled by default. If you want to
you can disable it:
http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile
The release profile is defined in the Super POM, which is the parent of all
Maven project and is embedded inside Maven itself. The exact details of the
release profile can be found here:
http://maven.apache.org/pom.html#The_Super_POM
changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
-
Key: MJAVADOC-408
URL: https://jira.codehaus.org/browse/MJAVADOC-408
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
Reporter: Volker Seibt
Priority: Critical
Attachments: console.log, pom.xml, pom.xml
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-333) announcement-generate for JIRA doesn't query for relevant issues
[
https://jira.codehaus.org/browse/MCHANGES-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361137#comment-361137
]
Thomas Scheffler commented on MCHANGES-333:
---
I noticed the same behaviour. We switched from SourceForge to JIRA and therefor
from changes.xml to JIRA, too. But I cannot get the announcement to work. Here
are some numbers:
- Issues count: *667*
- Issues fixed in the current release: *2*
- Issues fetched from JIRA to accidentally get the current release name: *25*
- Fields fetched to get the fixVersion field: *all*
You see I have to configure: {{maxEntries666/maxEntries}} (which is a bad
number) for {{changes:announcement-generate}} to work.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-changes-plugin:2.11:announcement-generate
(default-cli) on project mycore: No releases found in any of the configured
issue management systems. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-changes-plugin:2.11:announcement-generate
(default-cli) on project mycore: No releases found in any of the configured
issue management systems.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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.MojoExecutionException: No releases found in
any of the configured issue management systems.
at
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:580)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
{noformat}
Instead of querying *all* issues with *all* fields to get a list of all
versions, it would be better to use
*_[/rest/api/2/project/\{projectIdOrKey\}/versions|https://docs.atlassian.com/jira/REST/latest/#d2e231]_*.
announcement-generate for JIRA doesn't query for relevant issues
Key: MCHANGES-333
URL: https://jira.codehaus.org/browse/MCHANGES-333
Project: Maven Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.9
Reporter: Richard Barnett
Attachments: MCHANGES-333.patch
{{announcement-generate}} for JIRA submits a JQL query eg
{code}
Address: https://palomamobile.atlassian.net/rest/api/2/search
...
Payload: {jql:project = PCSV AND status in (5, 6) AND resolution in (1,
8),maxResults:25,fields:[*all]}
{code}
and then selects issues from the response which were fixed in the current
version. If no issues are selected the goal fails, eg:
{code}
Couldn't find the release '1.0.76' among the supplied releases:
[Release[version='1.0.73.1', date='null', description='null', actionsSize=2],
Release[version='1.0.73', date='null', description='null', actionsSize=3],
Release[version='1.0.72', date='null', description='null', actionsSize=2],
Release[version='1.0.75', date='null', description='null', actionsSize=5],
Release[version='1.0.74', date='null', description='null', actionsSize=4],
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361106#comment-361106
]
Robert Scholte commented on SUREFIRE-1134:
--
I think for SUREFIRE-756 you need the same kind of thing: create a testplan
(tests to execute and their order), next execute it.
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361109#comment-361109
]
Tibor Digana edited comment on SUREFIRE-1134 at 1/12/15 12:31 PM:
--
@Paul
We have such parameters: includesFile, excludesFile.
If unavailable system properties is the only issue, we get it in the next
release.
was (Author: tibor17):
@Paul
We have such parameters: includesFile, excludesFile.
If unavailable system properties is the only issue, we get get it in the next
release.
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://jira.codehaus.org/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361109#comment-361109
]
Tibor Digana commented on SUREFIRE-1134:
@Paul
We have such parameters: includesFile, excludesFile.
If unavailable system properties is the only issue, we get get it in the next
release.
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://jira.codehaus.org/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Priority: Minor
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
