[jira] (MENFORCER-127) Add new standard rule to handle encoding text file
Joris QUENEE created MENFORCER-127: -- Summary: Add new standard rule to handle encoding text file Key: MENFORCER-127 URL: https://jira.codehaus.org/browse/MENFORCER-127 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.1 Reporter: Joris QUENEE Hello, It will be very useful to have a standard rule to check encoding text file as : *.java, *.jsp, *.xml, *.properties, *.sql Indeed, following my experience in big project development there's many time error due to heterogeneous encoding file. So a simple standard to check every text file in same encoding could be very useful. Let me know, if my point of is relevant. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285955#comment-285955
]
Petr Kozelka commented on MNG-5218:
---
thanks I didn't know ...
still, I believe that using this can lead to much less usable builds, for the
reasons I wrote before.
One more thing I didn't mention before: your suggestion is well defined when
the parent is reachable via relativePath(s).
But that is not always the case. What should "productDistribution" contain in
this case ? Or should it fail ?
In general, I think that the build works best when every module is standalone
and isolated, in the sense that it does not directly access files belonging to
any other module.
Which is - as I guess - opposite of what your suggestion tries to achieve...
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-200) [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata
[
https://jira.codehaus.org/browse/MSHARED-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-200.
--
Resolution: Fixed
Fix Version/s: maven-doxia-tools-1.5
Assignee: Robert Scholte
Fixed in [rev. 1214494|http://svn.apache.org/viewvc?rev=1214494&view=rev]
The patch wasn't correct, it started with:
{noformat}
diff -Naur maven-doxia-tools-1.4.orig/pom.xml maven-doxia-tools-1.4/pom.xml
{noformat}
The _maven-doxia-tools-1.4.orig_ is an invalid path. Anyhow, the patch was
small enough to do it by hand. Thanks!
> [PATCH] Migration from obsolete plexus-maven-plugin to
> plexus-containers-component-metadata
> ---
>
> Key: MSHARED-200
> URL: https://jira.codehaus.org/browse/MSHARED-200
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-doxia-tools
>Affects Versions: maven-doxia-tools-1.4
> Environment: Fedora Rawhide
>Reporter: Jaromír Cápík
>Assignee: Robert Scholte
> Fix For: maven-doxia-tools-1.5
>
> Attachments: maven-doxia-tools-migration-to-component-metadata.patch
>
>
> The attached patch retires the obsolete plexus-maven-plugin and generates the
> metadata with plexus-containers-component-metadata instead.
> NOTE : The result XML file can have a different order of elements, but all of
> them should be present.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-810) Endorsed dirs mechanism not working
[
https://jira.codehaus.org/browse/SUREFIRE-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285950#comment-285950
]
Kristian Rosenvold commented on SUREFIRE-810:
-
I think this is mostly a documentation issue; there are some vm attributes that
need to be set upon boot, and somewhere around 2.6 we stopped sending them
"all" through the command line. I will close this issue when I have added
sufficient docs.
> Endorsed dirs mechanism not working
> ---
>
> Key: SUREFIRE-810
> URL: https://jira.codehaus.org/browse/SUREFIRE-810
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: José Cervera
> Attachments: pom.xml, TestSurefire.java, TEST-TestSurefire.xml
>
>
> The endorsed mechanism doesn't seem to work.
> You can reproduce this test by creating a new maven project, placing the java
> file in test/java, and using the provided pom.xml
> The test class checks the jar from which the WebFault class is loaded. It's
> expected to use the one in the webservices library, as can be checked by
> executing the test from command line with the required parameters.
> When executing mvn test, the test fails:
> C:\Users\Jose\\SurefireBug>mvn test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - SurefireBug:SurefireBug:jar:0.0.1-SNAPSHOT
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy {execution: process}]
> [INFO] Configured Artifact: org.glassfish.metro:webservices-rt:2.2-b10:jar
> [INFO] Configured Artifact: org.glassfish.metro:webservices-api:2.2-b10:jar
> [INFO] org.glassfish.metro:webservices-rt:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] org.glassfish.metro:webservices-api:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,
> i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy-dependencies {execution: install}]
> [INFO] junit-4.10.jar already exists in destination.
> [INFO] javax.annotation-3.1.1-b06.jar already exists in destination.
> [INFO] webservices-api-2.2-b10.jar already exists in destination.
> [INFO] webservices-rt-2.2-b10.jar already exists in destination.
> [INFO] hamcrest-core-1.1.jar already exists in destination.
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> C:\Users\Jose\\SurefireBug\target\surefire-reports
> ---
> T E S T S
> ---
> Running TestSurefire
> WebFault class:/C:/Program%20Files/Java/jdk1.6.0_25/jre/lib/rt.jar
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec <<<
> FAILURE!
> Results :
> Failed tests: test(TestSurefire)
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] There are test failures.
> Please refer to C:\Users\Jose\\SurefireBug\target\surefire-reports for
> the individual test results.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Dec 14 13:18:49 CET 2011
> [INFO] Final Memory: 25M/346M
> [INFO]
>
> And from command line:
> C:\Users\Jose\\SurefireBug>java -Djava.endorsed.dirs=target\endorsed
> -classpath
> target\test-classes;target\lib\hamcrest-core-1.1.jar;target\lib\junit-4.10.jar;target\lib\webservices-api-2.2-b10.jar;target\lib\webservices-rt-2.2-b10.jar
> org.junit.runner.JUnitCore TestSurefire
> JUnit version 4.10
> .WebFault
> class:/C:/Users/Jose/agentmanagement/SurefireBug/target/endorsed
[jira] (SUREFIRE-793) JUnit47 provider reports incorrect time in the XML report
[
https://jira.codehaus.org/browse/SUREFIRE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285949#comment-285949
]
Kristian Rosenvold commented on SUREFIRE-793:
-
Because we only run 1 class at a time with JUnit4, whereas with 4.7+ we send
junit the whole load of classes in one go
> JUnit47 provider reports incorrect time in the XML report
> -
>
> Key: SUREFIRE-793
> URL: https://jira.codehaus.org/browse/SUREFIRE-793
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.11, 2.12
>
> Attachments: surefire_793_trunk.v3.patch
>
>
> With this test:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The time presented in the XML report is wrong (close to zero), both for the
> total time and the time spent in the method. It's a side effect of the replay
> mechanism. I can't make it working without hacking the code quite a lot and
> probably breaking the other use cases, so a clean fix would be really
> appreciated. The complete test case would include before & after stuff, like
> this:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> @Test
> public void testT1() throws Exception {
> Thread.sleep(2000);
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> Thread.sleep(2000);
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> Thread.sleep(2000);
> }
> @Before
> public void setUp() throws Exception {
> Thread.sleep(2000);
> }
> @After
> public void tearDown() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The data are correct (at least individual method time) when using JUnit4
> provider.
> It's important, because the XML reports are used by Jenkins, and the test
> time is something we monitor very carefully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-806) Make ignoring of and on -Dtest=... optional (for multiple Surefire executions)
[
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285946#comment-285946
]
John Casey commented on SUREFIRE-806:
-
I've been looking at the code, and it seems like the most elegant solution
might be to create a new implementation of ScannerFilter that would wrap any
provider-specific filters in the event -Dtest= is specified on the command
line. Then, rather than including the -Dtest= classes in the includes for the
scanner, they would be managed via a separate property list, and populate the
new filter. When the DirectoryScanner filters the classes it finds based on
includes/excludes, the new ScannerFilter would first make sure (a) the tests
list is empty, or (b) the class matches something in the tests list...if it did
match, it would pass the class on to the provider-specific filter for ultimate
acceptance.
This requires three basic changes:
1. Alter the handling of -Dtest= so the enumerated tests are serialized in a
different list of properties (not in the includes list)
2. Read the new property list for -Dtest=, and use it to construct a new
ScannerFilter that wraps the provider-specific one. If -Dtest= is specified,
only allow classes that match that property list (subject to the
provider-specific filter's acceptance).
3. Provide a flag to turn on/off this test-vs-includes separation. When off,
the -Dtest= properties would be used as includes, and everything acts as it
does today. Otherwise, steps 1 and 2 are executed.
As far as the flag used to turn on this option, I'm less sure...maybe something
like true|false?
> Make ignoring of and on -Dtest=... optional (for
> multiple Surefire executions)
>
>
> Key: SUREFIRE-806
> URL: https://jira.codehaus.org/browse/SUREFIRE-806
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
> Attachments: surefire-806-testParam-hits-all-executions.zip
>
>
> Let's have a single module with multiple Surefire executions (e.g. with
> different Arquillian configs)
> Tests are divided to run in either one, using and .
> Then, if you use -Dtest=..., the specified test(s) is run twice - once for
> each execution (and usually fails in one of them in our scenario).
> My suggestion is to introduce a Surefire config property which would make
> this behavior optional:
> {code}
>
> false
>
> {code}
> This would cause Surefire to run the intersection of the two sets -
> one created by the mask from -Dtest=...,
> second created by the includes and excludes of the respective execution.
> Current description from
> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
> {quote}
> Specify this parameter to run individual tests by file name, overriding the
> includes/excludes parameters. Each pattern you specify here will be used to
> create an include pattern formatted like **/${test}.java, so you can just
> type "-Dtest=MyTest" to run a single test called "foo/MyTest.java".
> This parameter overrides the includes/excludes parameters, and the TestNG
> suiteXmlFiles parameter.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-806) Make ignoring of and on -Dtest=... optional (for multiple Surefire executions)
[
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285947#comment-285947
]
John Casey commented on SUREFIRE-806:
-
Oh, also, following up on SUREFIRE-778 ...if -DfilterCLITests=true and -Dtest=
is supplied, then failIfNoTests should be set to false automatically (unless
specifically overridden?)
> Make ignoring of and on -Dtest=... optional (for
> multiple Surefire executions)
>
>
> Key: SUREFIRE-806
> URL: https://jira.codehaus.org/browse/SUREFIRE-806
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
> Attachments: surefire-806-testParam-hits-all-executions.zip
>
>
> Let's have a single module with multiple Surefire executions (e.g. with
> different Arquillian configs)
> Tests are divided to run in either one, using and .
> Then, if you use -Dtest=..., the specified test(s) is run twice - once for
> each execution (and usually fails in one of them in our scenario).
> My suggestion is to introduce a Surefire config property which would make
> this behavior optional:
> {code}
>
> false
>
> {code}
> This would cause Surefire to run the intersection of the two sets -
> one created by the mask from -Dtest=...,
> second created by the includes and excludes of the respective execution.
> Current description from
> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
> {quote}
> Specify this parameter to run individual tests by file name, overriding the
> includes/excludes parameters. Each pattern you specify here will be used to
> create an include pattern formatted like **/${test}.java, so you can just
> type "-Dtest=MyTest" to run a single test called "foo/MyTest.java".
> This parameter overrides the includes/excludes parameters, and the TestNG
> suiteXmlFiles parameter.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-217) Separate inheritance and interpolation
[
https://jira.codehaus.org/browse/MSHARED-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-217.
--
Resolution: Fixed
Fix Version/s: maven-doxia-tools-1.5
Fixed in [rev. 1214470|http://svn.apache.org/viewvc?rev=1214470&view=rev]
> Separate inheritance and interpolation
> ---
>
> Key: MSHARED-217
> URL: https://jira.codehaus.org/browse/MSHARED-217
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-doxia-tools
>Affects Versions: maven-doxia-tools-1.4
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: maven-doxia-tools-1.5
>
>
> The implementation uses recursion to get an inherited model of the site.xml,
> but every step does the interpolation too.
> So if the parent site.xml contains something like ${project.name}, its value
> will be an ancestor project name, often an unexpected value.
> By moving the interpolation from the recursive method to the method-caller
> you will get the name of the active project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-217) Separate inheritance and interpolation
Robert Scholte created MSHARED-217:
--
Summary: Separate inheritance and interpolation
Key: MSHARED-217
URL: https://jira.codehaus.org/browse/MSHARED-217
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-doxia-tools
Affects Versions: maven-doxia-tools-1.4
Reporter: Robert Scholte
The implementation uses recursion to get an inherited model of the site.xml,
but every step does the interpolation too.
So if the parent site.xml contains something like ${project.name}, its value
will be an ancestor project name, often an unexpected value.
By moving the interpolation from the recursive method to the method-caller you
will get the name of the active project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285934#comment-285934
]
Ondrej Zizka edited comment on MNG-5218 at 12/14/11 12:55 PM:
--
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
And works everywhere except Ant plugin.
was (Author: pekarna):
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285934#comment-285934
]
Ondrej Zizka commented on MNG-5218:
---
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285926#comment-285926
]
Ondrej Zizka commented on MNG-5218:
---
Oliver, it would break nothing - default behavior would be as it is now.
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-702) Could not release project due to GIT clone error when working in sub-directory
[
https://jira.codehaus.org/browse/MRELEASE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285923#comment-285923
]
Robson Ximenes commented on MRELEASE-702:
-
I get similar problem... (https://github.com/demoiselle/report)
I have a project with outside parents... but the maven try to clone the parent.
I need to put the tag in all pom.xml? I dont want to make a release of
the parent... only a deploy...
> Could not release project due to GIT clone error when working in sub-directory
> --
>
> Key: MRELEASE-702
> URL: https://jira.codehaus.org/browse/MRELEASE-702
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.2.1
> Environment: LINUX, GIT, Maven 3.X, maven-release-plugin:2.2.1:perform
>Reporter: jurevert
>
> We have multi modules project structure like :
> {code}
> ParentPom
> |-- pom.xml (Modules : SampleProjectEAR,SampleProjectWeb,SampleProjectCommons)
> SampleProjectEAR
> |-- pom.xml (Parent : ParentPom pom.xml)
> SampleProjectWeb
> |-- pom.xml (Parent : ParentPom pom.xml)
> SampleProjectCommons
> |-- pom.xml (Parent : ParentPom pom.xml)
> {code}
> Our goal is to release the project. Th eparent project is in a subdir.
> When running the following command from root directory; we've got the
> following error :
> {code}
> mvn release:clean release:prepare release:perform -B -U -X -f
> ParentPom/pom.xml
> [...]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.2.1:perform (default-cli) on
> project WelcomTutorial: Unable to checkout from SCM
> [ERROR] Provider message:
> [ERROR] The git-clone command failed.
> [ERROR] Command output:
> [ERROR] fatal:
> '/app/DINB/bamboo-agent-home/xml-data/build-dir/WTUT-RELEASE-JOB1/ParentPom'
> does not appear to be a git repository
> [ERROR] fatal: The remote end hung up unexpectedly
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.2.1:perform
> (default-cli) on project WelcomTutorial: Unable to checkout from SCM
> Provider message:
> The git-clone command failed.
> Command output:
> fatal:
> '/app/DINB/bamboo-agent-home/xml-data/build-dir/WTUT-RELEASE-JOB1/ParentPom'
> does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to checkout
> from SCM
> Provider message:
> The git-clone command failed.
> Command output:
> fatal:
> '/app/DINB/bamboo-agent-home/xml-data/build-dir/WTUT-RELEASE-JOB1/ParentPom'
> does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
> at
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:140)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.l
[jira] (SUREFIRE-771) TestNG no longer creates TestSuite.txt file
[ https://jira.codehaus.org/browse/SUREFIRE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kutzinski closed SUREFIRE-771. Resolution: Cannot Reproduce Don't know why I was seeing that behaviour. Currently, all is fine again and I constantly get the TestSuite.txt > TestNG no longer creates TestSuite.txt file > --- > > Key: SUREFIRE-771 > URL: https://jira.codehaus.org/browse/SUREFIRE-771 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.9, 2.10 >Reporter: Christoph Kutzinski >Priority: Minor > > When running TestNG tests with surefire up to v2.8 only a single file > TestSuite.txt was generated in the output directory with a summary about the > tests including output from all failed tests. I found this format much more > helpful than the JUnit format with a single file per test class. > Since surefire 2.9 TestNG files seem to follow the same format - i.e. one > *.txt file per test class. > While one *could* argue that this would be a good thing to unify the output > from JUnit and TestNG, I couldn't find anything related in the release notes > ( > http://maven.40175.n5.nabble.com/Maven-Surefire-Plugin-2-9-Released-td4501032.html > ), so it doesn't look like a conscious change to me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-810) Endorsed dirs mechanism not working
[
https://jira.codehaus.org/browse/SUREFIRE-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285913#comment-285913
]
José Cervera commented on SUREFIRE-810:
---
Yes, this works (thanks!).
But isn't it a bug to ignore the java.endorsed.dirs property ? Besides, the
behavior has changed between 2.5 and 2.11.
> Endorsed dirs mechanism not working
> ---
>
> Key: SUREFIRE-810
> URL: https://jira.codehaus.org/browse/SUREFIRE-810
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: José Cervera
> Attachments: pom.xml, TestSurefire.java, TEST-TestSurefire.xml
>
>
> The endorsed mechanism doesn't seem to work.
> You can reproduce this test by creating a new maven project, placing the java
> file in test/java, and using the provided pom.xml
> The test class checks the jar from which the WebFault class is loaded. It's
> expected to use the one in the webservices library, as can be checked by
> executing the test from command line with the required parameters.
> When executing mvn test, the test fails:
> C:\Users\Jose\\SurefireBug>mvn test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - SurefireBug:SurefireBug:jar:0.0.1-SNAPSHOT
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy {execution: process}]
> [INFO] Configured Artifact: org.glassfish.metro:webservices-rt:2.2-b10:jar
> [INFO] Configured Artifact: org.glassfish.metro:webservices-api:2.2-b10:jar
> [INFO] org.glassfish.metro:webservices-rt:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] org.glassfish.metro:webservices-api:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,
> i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy-dependencies {execution: install}]
> [INFO] junit-4.10.jar already exists in destination.
> [INFO] javax.annotation-3.1.1-b06.jar already exists in destination.
> [INFO] webservices-api-2.2-b10.jar already exists in destination.
> [INFO] webservices-rt-2.2-b10.jar already exists in destination.
> [INFO] hamcrest-core-1.1.jar already exists in destination.
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> C:\Users\Jose\\SurefireBug\target\surefire-reports
> ---
> T E S T S
> ---
> Running TestSurefire
> WebFault class:/C:/Program%20Files/Java/jdk1.6.0_25/jre/lib/rt.jar
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec <<<
> FAILURE!
> Results :
> Failed tests: test(TestSurefire)
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] There are test failures.
> Please refer to C:\Users\Jose\\SurefireBug\target\surefire-reports for
> the individual test results.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Dec 14 13:18:49 CET 2011
> [INFO] Final Memory: 25M/346M
> [INFO]
>
> And from command line:
> C:\Users\Jose\\SurefireBug>java -Djava.endorsed.dirs=target\endorsed
> -classpath
> target\test-classes;target\lib\hamcrest-core-1.1.jar;target\lib\junit-4.10.jar;target\lib\webservices-api-2.2-b10.jar;target\lib\webservices-rt-2.2-b10.jar
> org.junit.runner.JUnitCore TestSurefire
> JUnit version 4.10
> .WebFault
> class:/C:/Users/Jose/agentmanagement/SurefireBug/target/endorsed/webservices-api-2.2-b10.jar
> Time: 0,005
> OK (1 test)
> I've tried changing the forkMode, useSystemClassLoade
[jira] (SUREFIRE-793) JUnit47 provider reports incorrect time in the XML report
[
https://jira.codehaus.org/browse/SUREFIRE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285911#comment-285911
]
nkeywal commented on SUREFIRE-793:
--
I checked, you're right, this works with forkMode=always only. How comes JUnit4
provider works when forkMode=once?
> JUnit47 provider reports incorrect time in the XML report
> -
>
> Key: SUREFIRE-793
> URL: https://jira.codehaus.org/browse/SUREFIRE-793
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.11, 2.12
>
> Attachments: surefire_793_trunk.v3.patch
>
>
> With this test:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The time presented in the XML report is wrong (close to zero), both for the
> total time and the time spent in the method. It's a side effect of the replay
> mechanism. I can't make it working without hacking the code quite a lot and
> probably breaking the other use cases, so a clean fix would be really
> appreciated. The complete test case would include before & after stuff, like
> this:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> @Test
> public void testT1() throws Exception {
> Thread.sleep(2000);
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> Thread.sleep(2000);
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> Thread.sleep(2000);
> }
> @Before
> public void setUp() throws Exception {
> Thread.sleep(2000);
> }
> @After
> public void tearDown() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The data are correct (at least individual method time) when using JUnit4
> provider.
> It's important, because the XML reports are used by Jenkins, and the test
> time is something we monitor very carefully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-591) Empty classifier in dependency causes extra dash
[ https://jira.codehaus.org/browse/MASSEMBLY-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Petrelli updated MASSEMBLY-591: --- Attachment: assembly-dash-classifier-patch.diff Added patch to fix the problem locally to maven-assembly-plugin. > Empty classifier in dependency causes extra dash > > > Key: MASSEMBLY-591 > URL: https://jira.codehaus.org/browse/MASSEMBLY-591 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.2 >Reporter: Antonio Petrelli >Priority: Minor > Attachments: assemblybug.zip, assembly-dash-classifier-patch.diff > > > When having a dependency with an empty classifier element, adding it as a > dependency set causes an extra dash to appear in the file name. > For example, when I add a dependency of this type (notice the empty > classifier element): > [snip] > > org.apache.tiles > tiles-api > 2.2.2 > > > [/snip] > and I put it inside the assembly descriptor: > [snip] > > > / > > > [/snip] > I see that the tiles-api jar contains an extra dash in its name: > tiles-api-2.2.2-.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-810) Endorsed dirs mechanism not working
[
https://jira.codehaus.org/browse/SUREFIRE-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285908#comment-285908
]
Kristian Rosenvold commented on SUREFIRE-810:
-
YOu probably need to set this using a -D option on "argLine"
> Endorsed dirs mechanism not working
> ---
>
> Key: SUREFIRE-810
> URL: https://jira.codehaus.org/browse/SUREFIRE-810
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: José Cervera
> Attachments: pom.xml, TestSurefire.java, TEST-TestSurefire.xml
>
>
> The endorsed mechanism doesn't seem to work.
> You can reproduce this test by creating a new maven project, placing the java
> file in test/java, and using the provided pom.xml
> The test class checks the jar from which the WebFault class is loaded. It's
> expected to use the one in the webservices library, as can be checked by
> executing the test from command line with the required parameters.
> When executing mvn test, the test fails:
> C:\Users\Jose\\SurefireBug>mvn test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - SurefireBug:SurefireBug:jar:0.0.1-SNAPSHOT
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy {execution: process}]
> [INFO] Configured Artifact: org.glassfish.metro:webservices-rt:2.2-b10:jar
> [INFO] Configured Artifact: org.glassfish.metro:webservices-api:2.2-b10:jar
> [INFO] org.glassfish.metro:webservices-rt:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] org.glassfish.metro:webservices-api:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,
> i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy-dependencies {execution: install}]
> [INFO] junit-4.10.jar already exists in destination.
> [INFO] javax.annotation-3.1.1-b06.jar already exists in destination.
> [INFO] webservices-api-2.2-b10.jar already exists in destination.
> [INFO] webservices-rt-2.2-b10.jar already exists in destination.
> [INFO] hamcrest-core-1.1.jar already exists in destination.
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> C:\Users\Jose\\SurefireBug\target\surefire-reports
> ---
> T E S T S
> ---
> Running TestSurefire
> WebFault class:/C:/Program%20Files/Java/jdk1.6.0_25/jre/lib/rt.jar
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec <<<
> FAILURE!
> Results :
> Failed tests: test(TestSurefire)
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] There are test failures.
> Please refer to C:\Users\Jose\\SurefireBug\target\surefire-reports for
> the individual test results.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Dec 14 13:18:49 CET 2011
> [INFO] Final Memory: 25M/346M
> [INFO]
>
> And from command line:
> C:\Users\Jose\\SurefireBug>java -Djava.endorsed.dirs=target\endorsed
> -classpath
> target\test-classes;target\lib\hamcrest-core-1.1.jar;target\lib\junit-4.10.jar;target\lib\webservices-api-2.2-b10.jar;target\lib\webservices-rt-2.2-b10.jar
> org.junit.runner.JUnitCore TestSurefire
> JUnit version 4.10
> .WebFault
> class:/C:/Users/Jose/agentmanagement/SurefireBug/target/endorsed/webservices-api-2.2-b10.jar
> Time: 0,005
> OK (1 test)
> I've tried changing the forkMode, useSystemClassLoader and childDelegation
> parameters.
> In the Test report we can see that th
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285907#comment-285907
]
Kristian Rosenvold commented on SUREFIRE-800:
-
Well the "NonConcurrentReporterManager" is the one thing I /will/ try to fix ;)
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
> Fix For: Backlog
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-793) JUnit47 provider reports incorrect time in the XML report
[
https://jira.codehaus.org/browse/SUREFIRE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285905#comment-285905
]
Kristian Rosenvold commented on SUREFIRE-793:
-
As far as I am aware, testSetStarting/testSetCompleted is only fired once per
test-run, which can span multiple classes. Maybe not entirely what we're
looking for...?
> JUnit47 provider reports incorrect time in the XML report
> -
>
> Key: SUREFIRE-793
> URL: https://jira.codehaus.org/browse/SUREFIRE-793
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.11, 2.12
>
> Attachments: surefire_793_trunk.v3.patch
>
>
> With this test:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The time presented in the XML report is wrong (close to zero), both for the
> total time and the time spent in the method. It's a side effect of the replay
> mechanism. I can't make it working without hacking the code quite a lot and
> probably breaking the other use cases, so a clean fix would be really
> appreciated. The complete test case would include before & after stuff, like
> this:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> @Test
> public void testT1() throws Exception {
> Thread.sleep(2000);
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> Thread.sleep(2000);
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> Thread.sleep(2000);
> }
> @Before
> public void setUp() throws Exception {
> Thread.sleep(2000);
> }
> @After
> public void tearDown() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The data are correct (at least individual method time) when using JUnit4
> provider.
> It's important, because the XML reports are used by Jenkins, and the test
> time is something we monitor very carefully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-793) JUnit47 provider reports incorrect time in the XML report
[
https://jira.codehaus.org/browse/SUREFIRE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285895#comment-285895
]
nkeywal commented on SUREFIRE-793:
--
I have a partial fix for it: with the fix, the time reported on the screen and
on the .txt file is right. The time reported in the .xml remains wrong.
I used the testSetStarting / testSetCompleted timestamps. Is it an issue?
The diff is there:
https://github.com/nkeywal/maven-surefire/commit/2543565ed23ed9b7f9c2db730cd0a92448b7a824
> JUnit47 provider reports incorrect time in the XML report
> -
>
> Key: SUREFIRE-793
> URL: https://jira.codehaus.org/browse/SUREFIRE-793
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.11, 2.12
>
> Attachments: surefire_793_trunk.v3.patch
>
>
> With this test:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The time presented in the XML report is wrong (close to zero), both for the
> total time and the time spent in the method. It's a side effect of the replay
> mechanism. I can't make it working without hacking the code quite a lot and
> probably breaking the other use cases, so a clean fix would be really
> appreciated. The complete test case would include before & after stuff, like
> this:
> {noformat}
> public class Test0 {
> @Test
> public void testT0() throws Exception {
> Thread.sleep(2000);
> }
> @Test
> public void testT1() throws Exception {
> Thread.sleep(2000);
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> Thread.sleep(2000);
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> Thread.sleep(2000);
> }
> @Before
> public void setUp() throws Exception {
> Thread.sleep(2000);
> }
> @After
> public void tearDown() throws Exception {
> Thread.sleep(2000);
> }
> }
> {noformat}
> The data are correct (at least individual method time) when using JUnit4
> provider.
> It's important, because the XML reports are used by Jenkins, and the test
> time is something we monitor very carefully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-134) Update to PMD 4.3 -- allow target to java 7
[
https://jira.codehaus.org/browse/MPMD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285893#comment-285893
]
Eric Barboni edited comment on MPMD-134 at 12/14/11 8:55 AM:
-
Hi Dennis,
The previous file remove the fail in junit for default configuration.
There is a failing test remaining in CpdReportTest line 132-133:
str = readFile( new File( getBasedir(),
"target/test/unit/custom-configuration/target/site/cpd.html" ) );
assertTrue( str.toLowerCase().indexOf( "private String unusedMethod( String
unusedParam )".toLowerCase() ) != -1 );
I do some testing
with default pmd 4.2.5 UI report contains "private String unusedMethod( String
unusedParam )"
with default pmd 4.3 UI report contains "private String unusedMethod()"
As this configuration is based on a 25 minimumTokens check I would change the
assertion by
assertTrue( str.toLowerCase().indexOf( "private String
unusedMethod(".toLowerCase() ) != -1 );
because we are not checking the duplication of parameter is "out of bounds"
was (Author: skygolanur):
Hi Dennis,
The previous file remove the fail in junit for default configuration.
There is a failing test remaining in CpdReportTest line 132-133:
{{str = readFile( new File( getBasedir(),
"target/test/unit/custom-configuration/target/site/cpd.html" ) );
assertTrue( str.toLowerCase().indexOf( "private String unusedMethod( String
unusedParam )".toLowerCase() ) != -1 );}}
I do some testing
with default pmd 4.2.5 UI report contains * "private String unusedMethod(
String unusedParam )" *
with default pmd 4.3 UI report contains * "private String unusedMethod()" *
> Update to PMD 4.3 -- allow target to java 7
> ---
>
> Key: MPMD-134
> URL: https://jira.codehaus.org/browse/MPMD-134
> Project: Maven 2.x PMD Plugin
> Issue Type: Wish
> Components: PMD
>Reporter: Eric Barboni
> Attachments: CpdReportGenerator.java
>
>
> After patching some source file with new Java 7 diamond operator (i.e. new
> HashMap<>()) all reports on this files are broken due to parsing error.
> It would be nice to patch the next 2.7 plug-in with 4.3 PMD to support all
> Java version grammar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-134) Update to PMD 4.3 -- allow target to java 7
[
https://jira.codehaus.org/browse/MPMD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285893#comment-285893
]
Eric Barboni commented on MPMD-134:
---
Hi Dennis,
The previous file remove the fail in junit for default configuration.
There is a failing test remaining in CpdReportTest line 132-133:
{{str = readFile( new File( getBasedir(),
"target/test/unit/custom-configuration/target/site/cpd.html" ) );
assertTrue( str.toLowerCase().indexOf( "private String unusedMethod( String
unusedParam )".toLowerCase() ) != -1 );}}
I do some testing
with default pmd 4.2.5 UI report contains * "private String unusedMethod(
String unusedParam )" *
with default pmd 4.3 UI report contains * "private String unusedMethod()" *
> Update to PMD 4.3 -- allow target to java 7
> ---
>
> Key: MPMD-134
> URL: https://jira.codehaus.org/browse/MPMD-134
> Project: Maven 2.x PMD Plugin
> Issue Type: Wish
> Components: PMD
>Reporter: Eric Barboni
> Attachments: CpdReportGenerator.java
>
>
> After patching some source file with new Java 7 diamond operator (i.e. new
> HashMap<>()) all reports on this files are broken due to parsing error.
> It would be nice to patch the next 2.7 plug-in with 4.3 PMD to support all
> Java version grammar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-266) It is not possible to disable the plugin in submodules
[ https://jira.codehaus.org/browse/MCHANGES-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285892#comment-285892 ] Igor Bljahhin commented on MCHANGES-266: I have the same problem with "changes:changes-validate" goal in multimodule project. The changes.xml is present in the parent project. The plugin tries to validate the file in every child project. > It is not possible to disable the plugin in submodules > -- > > Key: MCHANGES-266 > URL: https://jira.codehaus.org/browse/MCHANGES-266 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Reporter: Krzysztof Krason >Priority: Critical > > In a multi-module project there is no way to tell the plugin to generate > changes only for the parent module. > It would be best to have something like this: > > true > > This way anyone could set if he wants to generate reporst for submodules also. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285891#comment-285891
]
nkeywal commented on SUREFIRE-800:
--
Note that with "category" implementation, we're now using JUnit47 provider in
non parallel runs. And with the implementation of parallel run at the process
level, it's a little bit less necessary than before to parallelize at the
method/class level, so may be a specific NonConcurrentReporterManager could do
the trick?
Today, we're using *output.txt to analyze the behavior when something went
wrong. In this file, there is no split per method, it's only per class.
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
> Fix For: Backlog
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-134) Update to PMD 4.3 -- allow target to java 7
[ https://jira.codehaus.org/browse/MPMD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barboni updated MPMD-134: -- Attachment: CpdReportGenerator.java new CPDReport generator based on iterator on TokenEntry instead of getFirstMark and getSecondMark Allows more than two duplicate mark. Compatible with 4.2.5 > Update to PMD 4.3 -- allow target to java 7 > --- > > Key: MPMD-134 > URL: https://jira.codehaus.org/browse/MPMD-134 > Project: Maven 2.x PMD Plugin > Issue Type: Wish > Components: PMD >Reporter: Eric Barboni > Attachments: CpdReportGenerator.java > > > After patching some source file with new Java 7 diamond operator (i.e. new > HashMap<>()) all reports on this files are broken due to parsing error. > It would be nice to patch the next 2.7 plug-in with 4.3 PMD to support all > Java version grammar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-591) Empty classifier in dependency causes extra dash
[ https://jira.codehaus.org/browse/MASSEMBLY-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285887#comment-285887 ] Antonio Petrelli commented on MASSEMBLY-591: Using Maven 3.0.3 as a dependency for maven-assembly-plugin the bug still exists. > Empty classifier in dependency causes extra dash > > > Key: MASSEMBLY-591 > URL: https://jira.codehaus.org/browse/MASSEMBLY-591 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.2 >Reporter: Antonio Petrelli >Priority: Minor > Attachments: assemblybug.zip > > > When having a dependency with an empty classifier element, adding it as a > dependency set causes an extra dash to appear in the file name. > For example, when I add a dependency of this type (notice the empty > classifier element): > [snip] > > org.apache.tiles > tiles-api > 2.2.2 > > > [/snip] > and I put it inside the assembly descriptor: > [snip] > > > / > > > [/snip] > I see that the tiles-api jar contains an extra dash in its name: > tiles-api-2.2.2-.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-591) Empty classifier in dependency causes extra dash
Antonio Petrelli created MASSEMBLY-591: -- Summary: Empty classifier in dependency causes extra dash Key: MASSEMBLY-591 URL: https://jira.codehaus.org/browse/MASSEMBLY-591 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.2 Reporter: Antonio Petrelli Priority: Minor Attachments: assemblybug.zip When having a dependency with an empty classifier element, adding it as a dependency set causes an extra dash to appear in the file name. For example, when I add a dependency of this type (notice the empty classifier element): [snip] org.apache.tiles tiles-api 2.2.2 [/snip] and I put it inside the assembly descriptor: [snip] / [/snip] I see that the tiles-api jar contains an extra dash in its name: tiles-api-2.2.2-.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-396) Using profile for multimodule archetype creation from project
Mariano Alonso Ortiz created ARCHETYPE-396: -- Summary: Using profile for multimodule archetype creation from project Key: ARCHETYPE-396 URL: https://jira.codehaus.org/browse/ARCHETYPE-396 Project: Maven Archetype Issue Type: Improvement Components: Plugin Affects Versions: 2.2 Reporter: Mariano Alonso Ortiz Priority: Minor As a user I would like that archetypes created from a multi module project (through archetype:create-from-project goal) take into account the profile chosen during the goal execution, in order to determine the chosen modules for archetype creation. For example, if I have the current parent project: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.test test-parent 1.0.0-SNAPSHOT pom Parent a a b c b d e And I choose to create an archetype for the "a" profile: mvn -P a archetype:create-from-project I would like that the archetype created contains only the modules specified in profile "a", that is modules "a", "b" and "c". This feature could enhance multimodule archetype maintenance and combinations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-810) Endorsed dirs mechanism not working
José Cervera created SUREFIRE-810:
-
Summary: Endorsed dirs mechanism not working
Key: SUREFIRE-810
URL: https://jira.codehaus.org/browse/SUREFIRE-810
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: José Cervera
Attachments: pom.xml, TestSurefire.java, TEST-TestSurefire.xml
The endorsed mechanism doesn't seem to work.
You can reproduce this test by creating a new maven project, placing the java
file in test/java, and using the provided pom.xml
The test class checks the jar from which the WebFault class is loaded. It's
expected to use the one in the webservices library, as can be checked by
executing the test from command line with the required parameters.
When executing mvn test, the test fails:
C:\Users\Jose\\SurefireBug>mvn test
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - SurefireBug:SurefireBug:jar:0.0.1-SNAPSHOT
[INFO]task-segment: [test]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources,i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] [dependency:copy {execution: process}]
[INFO] Configured Artifact: org.glassfish.metro:webservices-rt:2.2-b10:jar
[INFO] Configured Artifact: org.glassfish.metro:webservices-api:2.2-b10:jar
[INFO] org.glassfish.metro:webservices-rt:2.2-b10:jar already exists in
C:\Users\Jose\\SurefireBug\target\endorsed
[INFO] org.glassfish.metro:webservices-api:2.2-b10:jar already exists in
C:\Users\Jose\\SurefireBug\target\endorsed
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] [dependency:copy-dependencies {execution: install}]
[INFO] junit-4.10.jar already exists in destination.
[INFO] javax.annotation-3.1.1-b06.jar already exists in destination.
[INFO] webservices-api-2.2-b10.jar already exists in destination.
[INFO] webservices-rt-2.2-b10.jar already exists in destination.
[INFO] hamcrest-core-1.1.jar already exists in destination.
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
C:\Users\Jose\\SurefireBug\target\surefire-reports
---
T E S T S
---
Running TestSurefire
WebFault class:/C:/Program%20Files/Java/jdk1.6.0_25/jre/lib/rt.jar
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec <<<
FAILURE!
Results :
Failed tests: test(TestSurefire)
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
Please refer to C:\Users\Jose\\SurefireBug\target\surefire-reports for the
individual test results.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Dec 14 13:18:49 CET 2011
[INFO] Final Memory: 25M/346M
[INFO]
And from command line:
C:\Users\Jose\\SurefireBug>java -Djava.endorsed.dirs=target\endorsed
-classpath
target\test-classes;target\lib\hamcrest-core-1.1.jar;target\lib\junit-4.10.jar;target\lib\webservices-api-2.2-b10.jar;target\lib\webservices-rt-2.2-b10.jar
org.junit.runner.JUnitCore TestSurefire
JUnit version 4.10
.WebFault
class:/C:/Users/Jose/agentmanagement/SurefireBug/target/endorsed/webservices-api-2.2-b10.jar
Time: 0,005
OK (1 test)
I've tried changing the forkMode, useSystemClassLoader and childDelegation
parameters.
In the Test report we can see that the java.endorsed.dirs property is not
changed.
I've also tried using a previous version (2.5). In this case, the property is
changed, but the test also fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
