[jira] Commented: (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=284891#comment-284891
]
nkeywal commented on SUREFIRE-793:
--
As a side note, the times reported on screen differ as well:
{noformat}
2.12-snapshot/Junit47:
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.004 sec
{noformat}
{noformat}
2.12-snapshot/Junit4:
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.056 sec
{noformat}
{noformat}
2.10/Junit47:
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.003 sec
{noformat}
> 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: Critical
> Fix For: 2.11
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5206) plexus container never disposed
[ https://jira.codehaus.org/browse/MNG-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284893#comment-284893 ] Tamás Cservenák commented on MNG-5206: -- AFAIK, Maven CLI does not call PlexusContainer.dispose(), it simply exists the JVM. Meaning, no "clean shutdown" happens wrt Plexus in this case. > plexus container never disposed > --- > > Key: MNG-5206 > URL: https://jira.codehaus.org/browse/MNG-5206 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.3 >Reporter: Jan Sievers > Attachments: plexusDisposeBug.zip > > > When I use a plexus component which implements > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable, dispose() > is never called. > Since maven is creating the plexus container, it should also dispose it (on > maven session end?). > Also see discussion on sisu-dev: > http://dev.eclipse.org/mhonarc/lists/sisu-dev/msg1.html > Attached sample project demonstrates the issue. > Steps to reproduce: > 1. 'mvn install' sample project > 2. Use the test mojo: 'mvn > org.apache.maven.plugins.test:plexusDisposeBug:0.0.1-SNAPSHOT:test' > => plexus component is injected but never disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5210) I cannot compile mixing modules and dependencies
I cannot compile mixing modules and dependencies
Key: MNG-5210
URL: https://jira.codehaus.org/browse/MNG-5210
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.3
Environment: maven 3.0.3
Reporter: Luca Stancapiano
Attachments: exampletest.zip
I have three two simple projects:
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/xsd/maven-4.0.0.xsd";>
prova
Mioframework
0.4.0-SNAPSHOT
../pom.xml
4.0.0
my-mioprogetto
Mio progetto
${project.groupId}
my-mioprogetto2
${project.version}
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/xsd/maven-4.0.0.xsd";>
prova
Mioframework
0.4.0-SNAPSHOT
../pom.xml
4.0.0
my-mioprogetto2
Mio progetto 2
and one 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/xsd/maven-4.0.0.xsd";>
4.0.0
prova
Mioframework
0.4.0-SNAPSHOT
Mioframework
pom
mioprogetto
mioprogetto2
mioprogetto as mioprogetto2 as dependency. Mioframework has the two projects as
modules.
If I compile mioframework I have no problems.
If I compile only mioprogetto2 I have no problems.
If I compile only mioprogetto I have problems because the dependency is not
matched. Here the error:
[ERROR] Failed to execute goal on project my-mioprogetto: Could not resolve
dependencies for project prova:my-mioprogetto:jar:0.4.0-SNAPSHOT: Could not
find artifact prova:my-mioprogetto2:jar:0.4.0-SNAPSHOT in myrepo-xxx
(http://repository.x) -> [Help 1]
I attach the complete example test
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5206) plexus container never disposed
[ https://jira.codehaus.org/browse/MNG-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5206: -- Attachment: MNG-5206.patch attach a patch > plexus container never disposed > --- > > Key: MNG-5206 > URL: https://jira.codehaus.org/browse/MNG-5206 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.3 >Reporter: Jan Sievers > Attachments: MNG-5206.patch, plexusDisposeBug.zip > > > When I use a plexus component which implements > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable, dispose() > is never called. > Since maven is creating the plexus container, it should also dispose it (on > maven session end?). > Also see discussion on sisu-dev: > http://dev.eclipse.org/mhonarc/lists/sisu-dev/msg1.html > Attached sample project demonstrates the issue. > Steps to reproduce: > 1. 'mvn install' sample project > 2. Use the test mojo: 'mvn > org.apache.maven.plugins.test:plexusDisposeBug:0.0.1-SNAPSHOT:test' > => plexus component is injected but never disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5208) Parallel (-T option) multi module build fires wrong "project failed event"
[ https://jira.codehaus.org/browse/MNG-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Eder updated MNG-5208: - Attachment: maven-core.patch This is how I solved the problem (it seems to work for me). Maybe some interested Maven developer could review it and commit it. > Parallel (-T option) multi module build fires wrong "project failed event" > -- > > Key: MNG-5208 > URL: https://jira.codehaus.org/browse/MNG-5208 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.3 > Environment: Maven 3.0.3 (+ Jenkins 1.430) >Reporter: Stefan Eder > Attachments: maven-core.patch > > > It seems that a parallel multi module build reports the wrong failed module > to an event spy. Interestingly the reactor summary shows the right one but I > imho the event for the listeners/spys is fired in a wrong fashion. > Let's assume the following scenario: > * Master > ** M1 > ** M2 > * M1 and M2 will be built parallel > * M2 will fail because of a compilation error > The events fired for this small scenario will look like this (simplified): > # projectStarted(Master) > # projectSucceeded(Master) > # projectStarted(M1) > # projectStarted(M2) > # projectFailed(Master) > In my opinion the last event should be fired with "M2", because this is the > module that actually fails. > The code where this happens can be found here: > http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuilderCommon.java?view=markup > (@handleBuildError():137) > http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java?view=markup > (@buildProject():95) > So probably it is not right that the "rootSession" is used in the fire event > statement (at least that seems to confuse Jenkins), or am I mistaken? > I almost forgot to mention: When a serial build is started then the last > event would be projectFailed(M2). > For the curious this is the issue I opened (and closed) @Jenkins JIRA: > https://issues.jenkins-ci.org/browse/JENKINS-11869 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5206) plexus container never disposed
[ https://jira.codehaus.org/browse/MNG-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284904#comment-284904 ] Jan Sievers commented on MNG-5206: -- I tried the above steps to reproduce with a locally built maven-3 with your patch applied. Unfortunately it seems that it does not solve the problem for this case. >From debugging MavenCli it seems that this is because MavenCli#classWorld == >null and thus also MavenCli#container == null and so won't be disposed. > plexus container never disposed > --- > > Key: MNG-5206 > URL: https://jira.codehaus.org/browse/MNG-5206 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.3 >Reporter: Jan Sievers > Attachments: MNG-5206.patch, plexusDisposeBug.zip > > > When I use a plexus component which implements > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable, dispose() > is never called. > Since maven is creating the plexus container, it should also dispose it (on > maven session end?). > Also see discussion on sisu-dev: > http://dev.eclipse.org/mhonarc/lists/sisu-dev/msg1.html > Attached sample project demonstrates the issue. > Steps to reproduce: > 1. 'mvn install' sample project > 2. Use the test mojo: 'mvn > org.apache.maven.plugins.test:plexusDisposeBug:0.0.1-SNAPSHOT:test' > => plexus component is injected but never disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5206) plexus container never disposed
[ https://jira.codehaus.org/browse/MNG-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284905#comment-284905 ] Olivier Lamy commented on MNG-5206: --- oh I tested with a mojo which implemented disposable but not with a component injected in a mojo. this need more investigations and changes in sisu. With the provided patch you can at least implements Disposable in the mojo and call dispose of the injected component. > plexus container never disposed > --- > > Key: MNG-5206 > URL: https://jira.codehaus.org/browse/MNG-5206 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.3 >Reporter: Jan Sievers > Attachments: MNG-5206.patch, plexusDisposeBug.zip > > > When I use a plexus component which implements > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable, dispose() > is never called. > Since maven is creating the plexus container, it should also dispose it (on > maven session end?). > Also see discussion on sisu-dev: > http://dev.eclipse.org/mhonarc/lists/sisu-dev/msg1.html > Attached sample project demonstrates the issue. > Steps to reproduce: > 1. 'mvn install' sample project > 2. Use the test mojo: 'mvn > org.apache.maven.plugins.test:plexusDisposeBug:0.0.1-SNAPSHOT:test' > => plexus component is injected but never disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-763) environmentVariables fails with useSystemClassLoader=false or forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284912#comment-284912
]
Marius Kruger commented on SUREFIRE-763:
As far as I can tell this issue is fixed in 2.10 (although I have lots of other
failures),
but in 2.11 this fails again (but all my other stuff works).
> environmentVariables fails with useSystemClassLoader=false or forkMode=always
> -
>
> Key: SUREFIRE-763
> URL: https://jira.codehaus.org/browse/SUREFIRE-763
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 2.7, 2.7.2, 2.9
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 19:31:09+0200)
> Maven home: /stf/opt/apache-maven-3.0.3
> Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
> Default locale: en_ZA, platform encoding: UTF-8
> OS name: "linux", version: "2.6.38-11-generic", arch: "amd64", family: "unix"
>Reporter: Marius Kruger
>Assignee: Kristian Rosenvold
> Fix For: 2.10
>
>
> I can't upgrade from surefire 2.6 because environmentVariables does not get
> properly populuated from 2.7 when using useSystemClassLoader=false or
> forkMode=always .
> In 2.6 my tests pass. From 2.7 if I only run the the test that requires the
> PATH to be set and have forkMode=once,
> the test passes, but if run all the tests or set forkMode=always then it
> breaks.
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> 2.9
>
> false
>
>
> ${env.HOME}
> ${env.PATH}
>
>
>
> my tests work fine with 2.6:
> useSystemClassLoader=false and forkMode=once or forkMode=always
> mvn test -Dtest=TestTaskUtils
> [INFO] --- maven-surefire-plugin:2.6:test (default-test)
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] BUILD SUCCESS
> 2.7:
> useSystemClassLoader=false and forkMode=once
> mvn test
> Tests run: 92, Failures: 1, Errors: 1, Skipped: 0
> [INFO] BUILD FAILURE
> mvn test -Dtest=TestTaskUtils
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] BUILD SUCCESS
> useSystemClassLoader=false and forkMode=always
> mvn test -Dtest=TestTaskUtils
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.7:test (default-test) on
> project ebr-orchestration-engine: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.7:test (default-test)
> on project ebr-orchestration-engine: There are test failures.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> (**/target/surefire-reports does not exist)
> With 2.9 I get other strange behaviour:
> useSystemClassLoader=false and forkMode=always
> Forking command line: /bin/sh -c cd
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine &&
> /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java
> org.apache.maven.surefire.booter.ForkedBooter
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire/surefire6100107079468387212tmp
>
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire/surefire6665672219640431542tmp
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.ClassNotFoundException: za.co.enerweb.ebr.task.TestTaskUtils;
> nested exception is java.lang.ClassNotFoundException:
> za.co.enerweb.ebr.task.TestTaskUtils
> java.lang.ClassNotFoundException: za.co.enerweb.ebr.task.TestTaskUtils
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.util.ReflectionUtils.loadClass(ReflectionUtils.java:203)
> at
> org.apache.maven.surefire.booter.PropertiesWrapper.getParamValue(PropertiesWrapper.java:132)
> at
> org.apache.maven.surefire.booter.PropertiesWrapper.getTypeDecoded(PropertiesWrapper.java:117)
> at
> org.apache.maven.surefire.booter.BooterDeserializer.deser
[jira] Commented: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284913#comment-284913 ] Dennis Lundberg commented on MEAR-60: - Here's a status report. I've managed to extract a patch from Eric's Github repo. It's applied locally and I have modified it so that all the current integration tests pass. There were two cases where the current ITs failed. A new integration test for skinny wars have been added. This is a change that will affect many projects, and I feel that we should have a parameter in the EarMojo to enable this new functionality. It should be disabled by default, to preserve the current behavior. I suggest a boolean parameter called "skinnyWars". What do you think? > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Priority: Critical > Attachments: maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-804) Testcase fails with forkMode=always and useSystemClassLoader=false
Testcase fails with forkMode=always and useSystemClassLoader=false -- Key: SUREFIRE-804 URL: https://jira.codehaus.org/browse/SUREFIRE-804 Project: Maven Surefire Issue Type: Bug Reporter: Kristian Rosenvold surefire-integration-tests/src/test/resources/environment-variables$ mvn -Dsurefire.version=2.11 -DforkMode=always -DuseSystemClassLoader=false test Requires forkMode=always *AND* useSystemClassLoader=false to reproduce, all other combinations work. forkMode=once works too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-763) environmentVariables fails with useSystemClassLoader=false or forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284914#comment-284914
]
Kristian Rosenvold commented on SUREFIRE-763:
-
I created SUREFIRE-804 for this issue, which is linked to this issue.
> environmentVariables fails with useSystemClassLoader=false or forkMode=always
> -
>
> Key: SUREFIRE-763
> URL: https://jira.codehaus.org/browse/SUREFIRE-763
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 2.7, 2.7.2, 2.9
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 19:31:09+0200)
> Maven home: /stf/opt/apache-maven-3.0.3
> Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
> Default locale: en_ZA, platform encoding: UTF-8
> OS name: "linux", version: "2.6.38-11-generic", arch: "amd64", family: "unix"
>Reporter: Marius Kruger
>Assignee: Kristian Rosenvold
> Fix For: 2.10
>
>
> I can't upgrade from surefire 2.6 because environmentVariables does not get
> properly populuated from 2.7 when using useSystemClassLoader=false or
> forkMode=always .
> In 2.6 my tests pass. From 2.7 if I only run the the test that requires the
> PATH to be set and have forkMode=once,
> the test passes, but if run all the tests or set forkMode=always then it
> breaks.
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> 2.9
>
> false
>
>
> ${env.HOME}
> ${env.PATH}
>
>
>
> my tests work fine with 2.6:
> useSystemClassLoader=false and forkMode=once or forkMode=always
> mvn test -Dtest=TestTaskUtils
> [INFO] --- maven-surefire-plugin:2.6:test (default-test)
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] BUILD SUCCESS
> 2.7:
> useSystemClassLoader=false and forkMode=once
> mvn test
> Tests run: 92, Failures: 1, Errors: 1, Skipped: 0
> [INFO] BUILD FAILURE
> mvn test -Dtest=TestTaskUtils
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] BUILD SUCCESS
> useSystemClassLoader=false and forkMode=always
> mvn test -Dtest=TestTaskUtils
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.7:test (default-test) on
> project ebr-orchestration-engine: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.7:test (default-test)
> on project ebr-orchestration-engine: There are test failures.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> (**/target/surefire-reports does not exist)
> With 2.9 I get other strange behaviour:
> useSystemClassLoader=false and forkMode=always
> Forking command line: /bin/sh -c cd
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine &&
> /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java
> org.apache.maven.surefire.booter.ForkedBooter
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire/surefire6100107079468387212tmp
>
> /stf_fast/prj/e-breadboard/work/ebr-orchestration-engine/target/surefire/surefire6665672219640431542tmp
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.ClassNotFoundException: za.co.enerweb.ebr.task.TestTaskUtils;
> nested exception is java.lang.ClassNotFoundException:
> za.co.enerweb.ebr.task.TestTaskUtils
> java.lang.ClassNotFoundException: za.co.enerweb.ebr.task.TestTaskUtils
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.util.ReflectionUtils.loadClass(ReflectionUtils.java:203)
> at
> org.apache.maven.surefire.booter.PropertiesWrapper.getParamValue(PropertiesWrapper.java:132)
> at
> org.apache.maven.surefire.booter.PropertiesWrapper.getTypeDecoded(PropertiesWrapper.java:117)
> at
> org.apache.maven.surefire.booter.BooterDeserializer.deserialize(BooterDeserializer.java:63)
> at
> org.apache.maven.surefir
[jira] Created: (SUREFIRE-805) Regression: surefire 2.11 seems to break excludeGroups config with TestNG
Regression: surefire 2.11 seems to break excludeGroups config with TestNG
-
Key: SUREFIRE-805
URL: https://jira.codehaus.org/browse/SUREFIRE-805
Project: Maven Surefire
Issue Type: Bug
Reporter: Christoph Kutzinski
I've a configuration to differentiate between unit and integration tests via
TestNG groups.
I cannot provide the full POM/project, but the relevant parts of the POMs like
this:
{noformat}
${skipTests}
true
maven-surefire-plugin
2.10
true
surefire-unit
test
test
${skipUnitTests}
INTEGRATION
surefire-it
integration-test
test
${skipIntegrationTests}
UNIT
once
it-tests
true
false
{noformat}
With Surefire this works fine - i.e. integration tests are only disabled with
the it-tests profile. With Surefire 2.11 the it tests are executed in the
default profile!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284920#comment-284920 ] Jeroen Ruijgers commented on MEAR-60: - Thanks! A long awaited change. I think the name is good and descriptive. > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Priority: Critical > Attachments: maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-805) Regression: surefire 2.11 seems to break excludeGroups config with TestNG
[
https://jira.codehaus.org/browse/SUREFIRE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284924#comment-284924
]
selckin commented on SUREFIRE-805:
--
Hit the same problem 2.11 seems to ignore excludedGroups with testng, works
with 2.10
> Regression: surefire 2.11 seems to break excludeGroups config with TestNG
> -
>
> Key: SUREFIRE-805
> URL: https://jira.codehaus.org/browse/SUREFIRE-805
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Christoph Kutzinski
>
> I've a configuration to differentiate between unit and integration tests via
> TestNG groups.
> I cannot provide the full POM/project, but the relevant parts of the POMs
> like this:
> {noformat}
>
> ${skipTests}
> true
>
>
> maven-surefire-plugin
> 2.10
>
>
> true
>
>
>
> surefire-unit
> test
>
> test
>
>
> ${skipUnitTests}
> INTEGRATION
>
>
>
> surefire-it
> integration-test
>
> test
>
>
> ${skipIntegrationTests}
> UNIT
> once
>
>
>
>
>
>
> it-tests
>
> true
> false
>
>
>
> {noformat}
> With Surefire this works fine - i.e. integration tests are only disabled with
> the it-tests profile. With Surefire 2.11 the it tests are executed in the
> default profile!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-652) Exception UnsatisfiedLinkError when running under Linux
Exception UnsatisfiedLinkError when running under Linux
---
Key: SCM-652
URL: https://jira.codehaus.org/browse/SCM-652
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-integrity
Affects Versions: 1.6
Environment: Linux Red-Hat 4 Update 6 32bits
JDK 1.6.0_11
Maven 2.2.1
MKS Source 2009
Build: 8.10.0.5799
Service Pack: 005-01
Hotfixes: C04105-019, C04105-021
Copyright 2001 - 2010 MKS Software Inc.; in Canada copyright owned by MKS Inc.
All rights reserved.
Reporter: Jeremie BOUSQUET
Priority: Critical
I have a very light test project stored in Integrity.
SCM commands (like "scm:status") ran against this project under windows work
well.
If I check-out this same project under Linux environment (with an MKS client
2009 configured properly), I get the following error when running scm:status
(or any other command) :
[INFO] [scm:status {execution: default-cli}]
[INFO] MKS Integrity API Version: 4.10
[INFO] Attempting to connect with the MKS Integrity Server
[INFO] Using a common session. Connection information is obtained from client
preferences
java.lang.UnsatisfiedLinkError: Cannot load apiclientrunner
at
com.mks.connect.ClientCmdRunnerImpl.(ClientCmdRunnerImpl.java:53)
at
com.mks.connect.UserApplicationSessionImpl._createCmdRunner(UserApplicationSessionImpl.java:546)
at
com.mks.connect.CmdRunnerCreatorImpl.createCmdRunner(CmdRunnerCreatorImpl.java:90)
at
org.apache.maven.scm.provider.integrity.APISession.connect(APISession.java:115)
at
org.apache.maven.scm.provider.integrity.command.login.IntegrityLoginCommand.executeLoginCommand(IntegrityLoginCommand.java:66)
at
org.apache.maven.scm.command.login.AbstractLoginCommand.executeCommand(AbstractLoginCommand.java:45)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
at
org.apache.maven.scm.provider.integrity.IntegrityScmProvider.login(IntegrityScmProvider.java:182)
at
org.apache.maven.scm.provider.AbstractScmProvider.login(AbstractScmProvider.java:730)
at
org.apache.maven.scm.provider.AbstractScmProvider.status(AbstractScmProvider.java:772)
at
org.apache.maven.scm.manager.AbstractScmManager.status(AbstractScmManager.java:487)
at org.apache.maven.scm.plugin.StatusMojo.execute(StatusMojo.java:54)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[ERROR] MKS API Exception: Cannot load apiclientrunner
[INFO] exited with return code -1
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot run status command :
Embedded error: Can't login.
Exit Code: -1
Here no credentials were provided in the SCM connection url, but providing
credentials lead to the same error.
A command "si connect" issued under same environment with same parameters
(hostname, credentials...) connects successfully to MKS.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-653) '@' not supported in passwords in SCM urls
'@' not supported in passwords in SCM urls -- Key: SCM-653 URL: https://jira.codehaus.org/browse/SCM-653 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-integrity Affects Versions: 1.6 Environment: Java 1.6.0_11 Maven 2.2.1 MKS Source 2009 Build: 8.10.0.5799 Service Pack: 005-01 Hotfixes: C04105-019, C04105-021 Copyright 2001 - 2010 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved. Reporter: Jeremie BOUSQUET In SCM url format for integrity, credentials can be entered as "login/password@hostname:port" But if password contains '@' character (as 'toto@date'), then the integrity provider interprets it as a separator (and tries to use "date@hostname" as hostname). I tried "toto\@date" but the same behaviour occurs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-47) Subpath reindexing does not work
Subpath reindexing does not work Key: MINDEXER-47 URL: https://jira.codehaus.org/browse/MINDEXER-47 Project: Maven Indexer Issue Type: Bug Reporter: Tamás Cservenák Subpath reindexing does not work -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINDEXER-47) Subpath reindexing does not work
[ https://jira.codehaus.org/browse/MINDEXER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MINDEXER-47: Description: Subpath reindexing does not work. Reindexing one GAV (subpath of it) of a GA removes other existing GA versions from index. Expected: Previous versions to remain in index, the new GAV to be added to index. was:Subpath reindexing does not work > Subpath reindexing does not work > > > Key: MINDEXER-47 > URL: https://jira.codehaus.org/browse/MINDEXER-47 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák > > Subpath reindexing does not work. > Reindexing one GAV (subpath of it) of a GA removes other existing GA versions > from index. > Expected: Previous versions to remain in index, the new GAV to be added to > index. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=284933#comment-284933 ] Murtuza Akhtari commented on MPMD-134: -- +1 from me as well. I have been trying to use different rulesets, but somehow, mvn pmd:check only uses basic, unusedcode & imports even though I can see all the other rulesets in the pmd-jdk14 jar file. Its not using the logging-java even if I explicitly put it in the in pom.xml an update to pmd 4.3 & Java 5 would be good > 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 > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-804) Testcase fails with forkMode=always and useSystemClassLoader=false
[ https://jira.codehaus.org/browse/SUREFIRE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-804. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Kristian Rosenvold Fixed in r1210545. Enabled IT that wasnt being run due to incorrect name > Testcase fails with forkMode=always and useSystemClassLoader=false > -- > > Key: SUREFIRE-804 > URL: https://jira.codehaus.org/browse/SUREFIRE-804 > Project: Maven Surefire > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.12 > > > surefire-integration-tests/src/test/resources/environment-variables$ mvn > -Dsurefire.version=2.11 -DforkMode=always -DuseSystemClassLoader=false test > Requires forkMode=always *AND* useSystemClassLoader=false to reproduce, all > other combinations work. forkMode=once works too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-805) Regression: surefire 2.11 seems to break excludeGroups config with TestNG
[
https://jira.codehaus.org/browse/SUREFIRE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-805.
---
Resolution: Fixed
Fix Version/s: 2.12
Assignee: Kristian Rosenvold
Fixed in r1210583, IT added in r1210590
> Regression: surefire 2.11 seems to break excludeGroups config with TestNG
> -
>
> Key: SUREFIRE-805
> URL: https://jira.codehaus.org/browse/SUREFIRE-805
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Christoph Kutzinski
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
>
> I've a configuration to differentiate between unit and integration tests via
> TestNG groups.
> I cannot provide the full POM/project, but the relevant parts of the POMs
> like this:
> {noformat}
>
> ${skipTests}
> true
>
>
> maven-surefire-plugin
> 2.10
>
>
> true
>
>
>
> surefire-unit
> test
>
> test
>
>
> ${skipUnitTests}
> INTEGRATION
>
>
>
> surefire-it
> integration-test
>
> test
>
>
> ${skipIntegrationTests}
> UNIT
> once
>
>
>
>
>
>
> it-tests
>
> true
> false
>
>
>
> {noformat}
> With Surefire this works fine - i.e. integration tests are only disabled with
> the it-tests profile. With Surefire 2.11 the it tests are executed in the
> default profile!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284950#comment-284950 ] Kristian Rosenvold commented on SUREFIRE-803: - Can't you just use the maven -fae option ? > Multiple Surefire executions - FAILURE in an execution prevents successive > from running. > > > Key: SUREFIRE-803 > URL: https://jira.codehaus.org/browse/SUREFIRE-803 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.10 >Reporter: Ondrej Zizka >Priority: Critical > > Let's have multiple Surefire executions in a single module (different config > needed). > A failure of a test in one of these executions prevents running the > successive. > Surefire's testFailureIgnore is not an option because it makes a run with > failures succeed. > This behavior is undocumented. > Also, it is undesired - the module as a whole should fail, but all it's tests > should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSKINS-16) width and height not picked up for banner
width and height not picked up for banner
-
Key: MSKINS-16
URL: https://jira.codehaus.org/browse/MSKINS-16
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-1.0
Environment: Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
Reporter: Mirko Friedenhagen
Priority: Minor
Attachments: enable-width-and-height-for-banner.patch
When I declare {{width}} and {{height}} in {{bannerLeft}} or {{bannerRight}} I
would expect these values to be picked up.
I attach a patch against:
http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin revision
1210036 which includes these as attributes of the banner image tag.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MPMD-135) Update to use and require Java 5
[ https://jira.codehaus.org/browse/MPMD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MPMD-135 started by Dennis Lundberg. > Update to use and require Java 5 > > > Key: MPMD-135 > URL: https://jira.codehaus.org/browse/MPMD-135 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > > We are currently using a backported version of the pmd library for Java 1.4. > Starting with PMD 4.3 this is no longer available. We should update to use > the Java 5 version of PMD and also update the plugin to take advantage of > Java 5 features. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=284952#comment-284952 ] Dennis Lundberg commented on MPMD-134: -- Hi I'm having some trouble when trying to update to PMD 4.3 on the current trunk of this plugin. The tests for CPD doesn't seem to work. If anyone has any ideas of what might be wrong I'd appreciate it. Has there been any breaking changes to CPD in PMD 4.3? > 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 > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSKINS-16) width, height and border not picked up for banner
[
https://jira.codehaus.org/browse/MSKINS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MSKINS-16:
-
Summary: width, height and border not picked up for banner (was: width and
height not picked up for banner)
> width, height and border not picked up for banner
> -
>
> Key: MSKINS-16
> URL: https://jira.codehaus.org/browse/MSKINS-16
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.0
> Environment: Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: enable-width-and-height-for-banner.patch
>
>
> When I declare {{width}} and {{height}} in {{bannerLeft}} or {{bannerRight}}
> I would expect these values to be picked up.
> I attach a patch against:
> http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin revision
> 1210036 which includes these as attributes of the banner image tag.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSKINS-16) width, height and border not picked up for banner
[
https://jira.codehaus.org/browse/MSKINS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSKINS-16.
Resolution: Fixed
Fix Version/s: fluido-1.1
Fixed in [rev. 1210609|http://svn.apache.org/viewvc?rev=1210609&view=rev
]. I've also added border, which was missing too.
Thanks!
> width, height and border not picked up for banner
> -
>
> Key: MSKINS-16
> URL: https://jira.codehaus.org/browse/MSKINS-16
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.0
> Environment: Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: fluido-1.1
>
> Attachments: enable-width-and-height-for-banner.patch
>
>
> When I declare {{width}} and {{height}} in {{bannerLeft}} or {{bannerRight}}
> I would expect these values to be picked up.
> I attach a patch against:
> http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin revision
> 1210036 which includes these as attributes of the banner image tag.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSKINS-15) With sidebar and no topbar external links should be rendered as menu
[
https://jira.codehaus.org/browse/MSKINS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284955#comment-284955
]
Mirko Friedenhagen commented on MSKINS-15:
--
Hello Simone,
would you mind including this in version fluido-1.1?
Regards
Mirko
> With sidebar and no topbar external links should be rendered as menu
>
>
> Key: MSKINS-15
> URL: https://jira.codehaus.org/browse/MSKINS-15
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.0, fluido-1.1
> Environment: {code}
> mvn --version
> Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
> {code}
>Reporter: Mirko Friedenhagen
> Attachments: enable-external-links-for-sidebar-when-no-topbar.patch
>
>
> External links specified in {{//project/body/links}} of the {{site.xml}} are
> only rendered as dropdown menu when the topbar is enabled.
> When only the sidebar is enabled these links are missing completely. I have
> attached a patch against revision 1206640 of
> http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin, which
> will render these links as additional menu in the sidebar when
> {{topbarEnabled==false}} and {{sidebarEnabled==true}}.
> Example output might be found at http://mojo.codehaus.org/fluido-preview/ for
> the ckjm-maven-plugin.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-804) Testcase fails with forkMode=always and useSystemClassLoader=false
[ https://jira.codehaus.org/browse/SUREFIRE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284956#comment-284956 ] Marius Kruger commented on SUREFIRE-804: wow, that was fast. thanks. > Testcase fails with forkMode=always and useSystemClassLoader=false > -- > > Key: SUREFIRE-804 > URL: https://jira.codehaus.org/browse/SUREFIRE-804 > Project: Maven Surefire > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.12 > > > surefire-integration-tests/src/test/resources/environment-variables$ mvn > -Dsurefire.version=2.11 -DforkMode=always -DuseSystemClassLoader=false test > Requires forkMode=always *AND* useSystemClassLoader=false to reproduce, all > other combinations work. forkMode=once works too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-458) Make publish date configurable
Make publish date configurable -- Key: DOXIA-458 URL: https://jira.codehaus.org/browse/DOXIA-458 Project: Maven Doxia Issue Type: Improvement Components: Site Renderer Affects Versions: 1.2 Reporter: Robert Scholte Priority: Minor When reskinning a site, the content won't change. So the publish date shouldn't change either. A lot of people relate this date to the deployment-date. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MNG-5075:
--
Fix Version/s: 3.0.5
> MavenProject.getParent throws undocumented ISE
> --
>
> Key: MNG-5075
> URL: https://jira.codehaus.org/browse/MNG-5075
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
> Fix For: 3.0.5
>
> Attachments: MavenProject-getParent-ISE.diff
>
>
> http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
> shows a stack trace encountered when calling {{MavenProject.getParent}} on a
> project with some errors (probably POMs missing in the local repository).
> This method has no Javadoc comment, so it is hard to know exactly what it is
> permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
> return value, and there is no {{throws IllegalStateException}} clause. The
> attached patch brings the behavior in line with that signature. (I think I
> got the {{PlexusTestCase}} infrastructure working with all the required
> wiring but it may be possible to simplify the test case.)
> Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
> throw {{ProjectBuildingException}}, though this would be a
> source-incompatible change. (Only binary-incompatible for clients which are
> already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5205) Memory leak in StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MNG-5205:
--
Fix Version/s: 3.0.5
> Memory leak in StringSearchModelInterpolator
>
>
> Key: MNG-5205
> URL: https://jira.codehaus.org/browse/MNG-5205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 3.0.5
>
> Attachments: x.diff
>
>
> {{StringSearchModelInterpolator}} abuses {{WeakHashMap}}; the {{Field}}
> values of {{fieldsByClass}} hold hard references to the {{Class}} keys,
> making it useless. Thus if you passed any {{Class}} to it, that class and its
> {{ClassLoader}} and the transitive static graph therefrom would never be
> collectible.
> Anyway a cache is unnecessary, since {{Class}} does its own caching of fields!
> Also removing the ill-conceived {{fieldIsPrimitiveByClass}} - not a memory
> leak, but likely unnecessary complication.
> The class is deprecated anyway, but just in case it is used by someone it
> should be fixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5209) MavenProject.getTestClasspathElements can return null elements
[
https://jira.codehaus.org/browse/MNG-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MNG-5209:
--
Fix Version/s: 3.0.5
> MavenProject.getTestClasspathElements can return null elements
> --
>
> Key: MNG-5209
> URL: https://jira.codehaus.org/browse/MNG-5209
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 3.0.5
>
> Attachments: MNG.diff
>
>
> A broken {{MavenProject}} can return null values in certain lists, which
> seems incorrect (at least it is undocumented). Root cause of:
> http://netbeans.org/bugzilla/show_bug.cgi?id=205867
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284962#comment-284962 ] Olivier Lamy commented on SCM-649: -- very nice patch! As a huge peace of code, could you send a cla to ASF ? See http://www.apache.org/licenses/ section "Contributor License Agreements". Let me know when it's done. > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-git.patch, scm-richmodel-model.patch, > scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (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:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-793.
---
Resolution: Fixed
Fix Version/s: 2.12
Fixed in r1210641, added IT. Deployed updated 2.12-SNAPSHOT
> 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: Critical
> Fix For: 2.12, 2.11
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSKINS-17) Add custom property publishDate
Add custom property publishDate --- Key: MSKINS-17 URL: https://jira.codehaus.org/browse/MSKINS-17 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Affects Versions: fluido-1.0 Reporter: Robert Scholte Priority: Minor To be able to reskin existing sites with the fluido-skin we need to lock the publish date, since we're not changing content but just the skin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=284967#comment-284967
]
nkeywal commented on SUREFIRE-793:
--
The original issue is fixed, thank you!
The difference between the times reported I was mentioning in my latest comment
is still there. Do you want me to create another jira for this?
> 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: Critical
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSKINS-17) Add custom property publishDate
[ https://jira.codehaus.org/browse/MSKINS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-17. Resolution: Fixed Fix Version/s: fluido-1.1 Fixed in [rev. 1210668|http://svn.apache.org/viewvc?rev=1210668&view=rev ] > Add custom property publishDate > --- > > Key: MSKINS-17 > URL: https://jira.codehaus.org/browse/MSKINS-17 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: fluido-1.1 > > > To be able to reskin existing sites with the fluido-skin we need to lock the > publish date, since we're not changing content but just the skin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSKINS-17) Add custom property publishDate
[ https://jira.codehaus.org/browse/MSKINS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284969#comment-284969 ] Robert Scholte edited comment on MSKINS-17 at 12/5/11 4:25 PM: --- Fixed in [rev. 1210668|http://svn.apache.org/viewvc?rev=1210668&view=rev] was (Author: rfscholte): Fixed in [rev. 1210668|http://svn.apache.org/viewvc?rev=1210668&view=rev ] > Add custom property publishDate > --- > > Key: MSKINS-17 > URL: https://jira.codehaus.org/browse/MSKINS-17 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: fluido-1.1 > > > To be able to reskin existing sites with the fluido-skin we need to lock the > publish date, since we're not changing content but just the skin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-107) mvn deploy of SNAPSHOT failed with maven3 when invoker:run look for current build dependency
[
https://jira.codehaus.org/browse/MINVOKER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284972#comment-284972
]
Tony Chemit commented on MINVOKER-107:
--
Robert, Same for me, I can no more reproduce it on the webstart project. I will
try with other projects I know it fails
> mvn deploy of SNAPSHOT failed with maven3 when invoker:run look for current
> build dependency
>
>
> Key: MINVOKER-107
> URL: https://jira.codehaus.org/browse/MINVOKER-107
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_22
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.32-25-generic-pae" arch: "i386" Family: "unix"
>Reporter: ludovic
> Attachments: MINVOKER-107.diff
>
>
> When I build
> http://code.google.com/p/mycila/source/browse/mycila-testing/trunk?r=1448 on
> revision 1448, the build failed. r1449 is a workaround.
> the maven command is : mvn clean deploy
> the build failed when running plugin invoker:run with maven3 BUT succeed with
> maven2
> the failure is due of a missing artifact in the its local repository, the
> searched version is a SNAPSHOT, the present version is a timestamped SNAPSHOT
> the dependency com.mycila.testing:mycila-testing-api:jar:2.6-SNAPSHOT is not
> found because the invoker:install copy the SNAPSHOT with the timestamp during
> deploy. And then after during the test, the dependency could not be found.
> The reason is because maven3 always deploy using a timestamped version.
> @see
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments
> ! workaround
> remove
> ${project.build.directory}/local-repo
> from the invoker configuration
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-285) regression: duplicate files added to the assembly
[
https://jira.codehaus.org/browse/MASSEMBLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284982#comment-284982
]
Chad McHenry commented on MASSEMBLY-285:
This is still an issue in maven-assembly-plugin-2.2.2.
(i) The maven-shade-plugin (mentioned in
[jar-with-dependencies|http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies]
pre-defined descriptor) can create standalone (uber) jars and does not
duplicate files.
{code:xml}
org.apache.maven.plugins
maven-shade-plugin
1.5
package
shade
${mainClass}
true
standalone
{code}
> regression: duplicate files added to the assembly
> -
>
> Key: MASSEMBLY-285
> URL: https://jira.codehaus.org/browse/MASSEMBLY-285
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Brett Porter
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-3
>
>
> I found that it was possible to add a file twice to the assembly through
> different filesets (a zip file) so that when it extracted it prompted for
> overwrite.
> It should error out or collapse the entries (as 2.1 did).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-237) The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com
[ https://jira.codehaus.org/browse/MCHANGES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Stein updated MCHANGES-237: Attachment: fixed-MCHANGES237.patch > The goal jira-report always results in HTTP 400 error when accessing > https://*.jira.com > --- > > Key: MCHANGES-237 > URL: https://jira.codehaus.org/browse/MCHANGES-237 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.4 >Reporter: Gabriel Peter >Priority: Blocker > Attachments: fixed-MCHANGES237.patch > > > The http-client used by plugin, rejects one of the cookies from > https://company.jira.com and the missing cookie is the culprit of the 400 > error. Maven 2.2.1 used. See extract below: > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; studio.crowd.tokenkey=; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; > studio.crowd.tokenkey=M2peMiHnn4NggIbmyHpKEQ00; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:51 org.apache.commons.httpclient.HttpMethodBase getResponseBody > WARNING: Going to buffer response body of large or unknown size. Using > getResponseBodyAsStream instead is recommended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-237) The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com
[ https://jira.codehaus.org/browse/MCHANGES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284989#comment-284989 ] Leon Stein commented on MCHANGES-237: - The problem is that HttpClient is refusing to accept authentication cookie from Jira, as it's set on domain starting with dot (..atlassian.net). Adding BROWSER_COMPATIBILITY to http client fixes the problem (see attached patch). > The goal jira-report always results in HTTP 400 error when accessing > https://*.jira.com > --- > > Key: MCHANGES-237 > URL: https://jira.codehaus.org/browse/MCHANGES-237 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.4 >Reporter: Gabriel Peter >Priority: Blocker > Attachments: fixed-MCHANGES237.patch > > > The http-client used by plugin, rejects one of the cookies from > https://company.jira.com and the missing cookie is the culprit of the 400 > error. Maven 2.2.1 used. See extract below: > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; studio.crowd.tokenkey=; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; > studio.crowd.tokenkey=M2peMiHnn4NggIbmyHpKEQ00; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:51 org.apache.commons.httpclient.HttpMethodBase getResponseBody > WARNING: Going to buffer response body of large or unknown size. Using > getResponseBodyAsStream instead is recommended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHANGES-237) The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com
[ https://jira.codehaus.org/browse/MCHANGES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284989#comment-284989 ] Leon Stein edited comment on MCHANGES-237 at 12/6/11 12:06 AM: --- The problem is that HttpClient is refusing to accept authentication cookie from Jira, as it's set on domain starting with dot (..atlassian.net). Setting BROWSER_COMPATIBILITY cookie policy on HttpClient fixes the problem (see attached patch). was (Author: leons727): The problem is that HttpClient is refusing to accept authentication cookie from Jira, as it's set on domain starting with dot (..atlassian.net). Adding BROWSER_COMPATIBILITY to http client fixes the problem (see attached patch). > The goal jira-report always results in HTTP 400 error when accessing > https://*.jira.com > --- > > Key: MCHANGES-237 > URL: https://jira.codehaus.org/browse/MCHANGES-237 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.4 >Reporter: Gabriel Peter >Priority: Blocker > Attachments: fixed-MCHANGES237.patch > > > The http-client used by plugin, rejects one of the cookies from > https://company.jira.com and the missing cookie is the culprit of the 400 > error. Maven 2.2.1 used. See extract below: > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; studio.crowd.tokenkey=; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; > studio.crowd.tokenkey=M2peMiHnn4NggIbmyHpKEQ00; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:51 org.apache.commons.httpclient.HttpMethodBase getResponseBody > WARNING: Going to buffer response body of large or unknown size. Using > getResponseBodyAsStream instead is recommended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHANGES-237) The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com
[ https://jira.codehaus.org/browse/MCHANGES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284989#comment-284989 ] Leon Stein edited comment on MCHANGES-237 at 12/6/11 12:07 AM: --- In our case the problem was that HttpClient was refusing to accept authentication cookie from Jira, as it was set on a domain starting with dot (..atlassian.net). Setting BROWSER_COMPATIBILITY cookie policy on HttpClient fixes the problem (see attached patch). was (Author: leons727): The problem is that HttpClient is refusing to accept authentication cookie from Jira, as it's set on domain starting with dot (..atlassian.net). Setting BROWSER_COMPATIBILITY cookie policy on HttpClient fixes the problem (see attached patch). > The goal jira-report always results in HTTP 400 error when accessing > https://*.jira.com > --- > > Key: MCHANGES-237 > URL: https://jira.codehaus.org/browse/MCHANGES-237 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.4 >Reporter: Gabriel Peter >Priority: Blocker > Attachments: fixed-MCHANGES237.patch > > > The http-client used by plugin, rejects one of the cookies from > https://company.jira.com and the missing cookie is the culprit of the 400 > error. Maven 2.2.1 used. See extract below: > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; studio.crowd.tokenkey=; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:50 org.apache.commons.httpclient.HttpMethodBase > processResponseHeaders > WARNING: Cookie rejected: "$Version=0; > studio.crowd.tokenkey=M2peMiHnn4NggIbmyHpKEQ00; $Path=/; > $Domain=.davinci.jira.com". Illegal domain attribute ".davinci.jira.com". > Domain of origin: "davinci.jira.com" > 27.4.2011 9:52:51 org.apache.commons.httpclient.HttpMethodBase getResponseBody > WARNING: Going to buffer response body of large or unknown size. Using > getResponseBodyAsStream instead is recommended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (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:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-793:
Comment: was deleted
(was: I'll take another look)
> 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: Critical
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=284995#comment-284995
]
Kristian Rosenvold commented on SUREFIRE-793:
-
I'll take another look
> 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: Critical
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=284996#comment-284996
]
Kristian Rosenvold commented on SUREFIRE-793:
-
I'll take another look
> 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: Critical
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
