[jira] Updated: (SCM-613) Heterogeneous case in blame operation on Wondows OS
[ http://jira.codehaus.org/browse/SCM-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremie Lagarde updated SCM-613: Attachment: SCM-613.patch > Heterogeneous case in blame operation on Wondows OS > --- > > Key: SCM-613 > URL: http://jira.codehaus.org/browse/SCM-613 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.4 > Environment: Windows >Reporter: Jeremie Lagarde >Priority: Minor > Attachments: SCM-613.patch > > > ClearCase commands on Windows uses the user name as it was entered at the > logon prompt, and these operations are case-sensitive. > Windows logon user names are not case-sensitive but are case-preserving. The > same account with various of capitalization can be use but gives a result > which is not homogeneous in the blame operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-691) Skip reports and menu link generation when it does not make sense (i.e: test results are missing)
[ http://jira.codehaus.org/browse/SUREFIRE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259186#action_259186 ] Kristian Rosenvold edited comment on SUREFIRE-691 at 3/7/11 3:06 PM: - I'm not entirely sure I understand these patches still. The first patch contains a NoReportIT.java, while the second patch does not. And the test in the second patch seems to be referencing a diferctory "test-reports"; where is this ? And please add license headers to the new files. was (Author: krosenvold): I'm not entirely sure I understand these patches still. The first patch contains a NoReportIT.java, while the second patch does not. And the test in the second patch seems to be referencing a diferctory "test-reports"; where is this ? > Skip reports and menu link generation when it does not make sense (i.e: test > results are missing) > - > > Key: SUREFIRE-691 > URL: http://jira.codehaus.org/browse/SUREFIRE-691 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.8 >Reporter: Marcin Kuthan >Priority: Minor > Attachments: screenshot.png, SUREFIRE-691.patch, SUREFIRE-691.patch > > > Surefire report page and link in the menu are generated even if there is no > tests. It also happens for submodules when -Daggregate=true is given. > Another plugins which supports report aggregation (m-pmd-p, m-javadoc-p, > m-jxr-p) don't generate link in the menu and empty report page when report > does not make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-691) Skip reports and menu link generation when it does not make sense (i.e: test results are missing)
[ http://jira.codehaus.org/browse/SUREFIRE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259186#action_259186 ] Kristian Rosenvold commented on SUREFIRE-691: - I'm not entirely sure I understand these patches still. The first patch contains a NoReportIT.java, while the second patch does not. And the test in the second patch seems to be referencing a diferctory "test-reports"; where is this ? > Skip reports and menu link generation when it does not make sense (i.e: test > results are missing) > - > > Key: SUREFIRE-691 > URL: http://jira.codehaus.org/browse/SUREFIRE-691 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.8 >Reporter: Marcin Kuthan >Priority: Minor > Attachments: screenshot.png, SUREFIRE-691.patch, SUREFIRE-691.patch > > > Surefire report page and link in the menu are generated even if there is no > tests. It also happens for submodules when -Daggregate=true is given. > Another plugins which supports report aggregation (m-pmd-p, m-javadoc-p, > m-jxr-p) don't generate link in the menu and empty report page when report > does not make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-468) When tests timeout, report files on disk are incorrect
[ http://jira.codehaus.org/browse/SUREFIRE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-468: Fix Version/s: (was: 2.7.2) > When tests timeout, report files on disk are incorrect > -- > > Key: SUREFIRE-468 > URL: http://jira.codehaus.org/browse/SUREFIRE-468 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, process forking >Affects Versions: 2.4.2 >Reporter: A >Assignee: Kristian Rosenvold > > When forkmode is always/prtest (probably that could be true for the last test > and forkmode once) when one test hangs and timeout occurs, est suite > execution stops and report file for the offending test not generated. That > could mislead somebody to think all tests passed if all tests before the > offending one passed. > AFAICT that should be synchronized between one of these: > 1. CommandLineUtils.executeCommandLine() > 2. SurefireBooter.fork() > 3. SurefireBooter.run() > 4. SurefirePlugin.execute() > Probably fork must detect a timeout. Then the timeout be gracefully handled > by generating a report file for the test. Then continue execution of > remaining tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-697) When the exception message is long or contains linefeeds, the summary display is not nice
[
http://jira.codehaus.org/browse/SUREFIRE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-697.
---
Resolution: Fixed
Fix Version/s: 2.8
Assignee: Kristian Rosenvold
Fixed with test in r1078913
> When the exception message is long or contains linefeeds, the summary display
> is not nice
> -
>
> Key: SUREFIRE-697
> URL: http://jira.codehaus.org/browse/SUREFIRE-697
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.7.2
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.8
>
>
> When the "message" of the exception is long (like Spring framework can do and
> some backend systems) or contains some kind of multi-line text, the summary
> display ("Failed tests"/"Tests with error") looks totally off. The message
> shown in the display should probably be truncated to show only the first line
> of the message text. I am not sure if it also should be truncated if it's
> very long single-line, which should be considered when fixing this issue.
> This problem was introduced with SUREFIRE-645 in 2.7.2
> This is the display in question, but this testcase does not demonstrate the
> long messages
> Results :
> Failed tests:
> testiWithFail2(surefire613.Test2): We excpect this
> testiWithFail4(surefire613.Test2): We excpect this
> testiWithFail1(surefire613.Test2): We excpect this
> testiWithFail3(surefire613.Test2): We excpect this
> Tests in error:
> testWithException8(surefire613.Test2): We expect this
> testWithException7(surefire613.Test2): We expect this
> testWithException6(surefire613.Test2): We expect this
> testWithException5(surefire613.Test2): We expect this
> testWithException4(surefire613.Test2): We expect this
> testWithException3(surefire613.Test2): We expect this
> testWithException2(surefire613.Test2): We expect this
> testWithException1(surefire613.Test2): We expect this
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-656) JUnit 4.8 @Category support
[
http://jira.codehaus.org/browse/SUREFIRE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-656:
Fix Version/s: (was: 2.8)
> JUnit 4.8 @Category support
> ---
>
> Key: SUREFIRE-656
> URL: http://jira.codehaus.org/browse/SUREFIRE-656
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.7
> Environment: any
>Reporter: KP
>
> I am interested in adding JUnit's {{@Category}} support. TestNG already has
> group support in Surefire, so this would be a nice addition.
> I'm wondering if someone could point me in the right direction.
> Unfortunately, I'm not familiar with the Surefire source code.
> 1. Do I need to add another provider or something?
> 1. Should I just subclass {{SurefireTestSuite}} in the same manner as
> {{JUnitCoreDirectoryTestSuite}}?
> 1. Should I model
> Any help would be greatly appreciated. I have some free time and I'd love to
> submit a patch this week.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds
[ http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-690: Fix Version/s: (was: 2.8) > testSetCompleted called before testSetStarting when using m3 parallel builds > > > Key: SUREFIRE-690 > URL: http://jira.codehaus.org/browse/SUREFIRE-690 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.7.1 >Reporter: Gin-Ting Chen >Assignee: Kristian Rosenvold > > This is running m3 with -T 1C (8 core build machine). > [17:52:38]: [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on > project hornet-stinger: Error while executing forked tests.; nested exception > is java.lang.IllegalStateException: testSetCompleted called before > testSetStarting -> [Help 1] > Seems like it doesn't happen as frequently as previously -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-537) Rason for the Ignored/Skipped testcases is not reported
[
http://jira.codehaus.org/browse/SUREFIRE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-537:
Fix Version/s: (was: 2.8)
> Rason for the Ignored/Skipped testcases is not reported
> ---
>
> Key: SUREFIRE-537
> URL: http://jira.codehaus.org/browse/SUREFIRE-537
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, Maven Surefire Report Plugin, xml
> generation
>Affects Versions: 2.4.3
> Environment: Windows XP, junit 4.4
>Reporter: Rakesh Arora
>Assignee: Kristian Rosenvold
>
> Tests that are skipped with a @Ignore("Test doesn't work") annotation only
> appear in the report as an increment in the "Skipped" column. Name of the
> skipped testcases is also reported. However, the reason (i.e. "Test doesn't
> work") is not reported.
> Quick look at the source code, it seems that it is not implemented:
> In class: org.apache.maven.plugins.surefire.report.TestSuiteXmlParser
> else if ( "skipped".equals( qName ) )
> {
> testCase.addFailure( "skipped", "skipped" ); // TODO extract
> real reasons
> currentSuite.setNumberOfSkipped( 1 +
> currentSuite.getNumberOfSkipped() );
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259178#action_259178 ] Julien Nicoulaud commented on MPH-82: - Settings.getProfiles() is returning an empty list. Opened Maven bug MNG-5036. > all-profiles does not show inactive profiles from settings file > --- > > Key: MPH-82 > URL: http://jira.codehaus.org/browse/MPH-82 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Julien Nicoulaud > > The all-profiles goal does not lists the inactive profile from settings.xml. > Only the active ones are included in the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5036) Settings.getProfiles() returning an empty list
Settings.getProfiles() returning an empty list -- Key: MNG-5036 URL: http://jira.codehaus.org/browse/MNG-5036 Project: Maven 2 & 3 Issue Type: Bug Components: Profiles, Settings Affects Versions: 3.0.3, 3.0.2, 3.0.1, 3.0 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/maven/apache-maven-3.0.3 Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: "linux", version: "2.6.35-27-generic", arch: "amd64", family: "unix" Reporter: Julien Nicoulaud This is related to MPH-82: in the "help:all-profiles" goal, [Settings.getProfiles()|http://maven.apache.org/plugins/maven-help-plugin/xref/org/apache/maven/plugins/help/AllProfilesMojo.html#317] returns an empty list since Maven 3.0. Strangely, it works fine when run with mvnDebug (without breakpoint). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-547) Links to child modules do not work when using flat structure
[ http://jira.codehaus.org/browse/MSITE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-547. --- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Lukas Theussl This seems fixed in 3.0-beta-4-SNAPSHOT, please test. > Links to child modules do not work when using flat structure > - > > Key: MSITE-547 > URL: http://jira.codehaus.org/browse/MSITE-547 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3, multi module, relative links, site:deploy >Affects Versions: 3.0-beta-3 > Environment: Maven 3.0.1, Windows XP SP3 >Reporter: Martin Ackermann >Assignee: Lukas Theussl > Fix For: 3.0-beta-4 > > Attachments: trial-maven-with-urls-and-sitexml.zip, trial-maven.zip > > > trial-maven-child-module has trial-maven-product as parent. When they are > both in the same directory (flat structure), "mvn site-deploy" does not > generate working links for the site. See attached example project. > If trial-maven-child-module is a sub-directory of trial-maven-product (deep > structure), "mvn site-deploy" generates working links. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-547) Links to child modules do not work when using flat structure
[ http://jira.codehaus.org/browse/MSITE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-547: Component/s: relative links multi module Maven 3 > Links to child modules do not work when using flat structure > - > > Key: MSITE-547 > URL: http://jira.codehaus.org/browse/MSITE-547 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3, multi module, relative links, site:deploy >Affects Versions: 3.0-beta-3 > Environment: Maven 3.0.1, Windows XP SP3 >Reporter: Martin Ackermann > Attachments: trial-maven-with-urls-and-sitexml.zip, trial-maven.zip > > > trial-maven-child-module has trial-maven-product as parent. When they are > both in the same directory (flat structure), "mvn site-deploy" does not > generate working links for the site. See attached example project. > If trial-maven-child-module is a sub-directory of trial-maven-product (deep > structure), "mvn site-deploy" generates working links. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259158#action_259158 ] Julien Nicoulaud commented on MPH-82: - It only behaves this on Maven 3. Everything works fine on Maven 2.2.1. > all-profiles does not show inactive profiles from settings file > --- > > Key: MPH-82 > URL: http://jira.codehaus.org/browse/MPH-82 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Julien Nicoulaud > > The all-profiles goal does not lists the inactive profile from settings.xml. > Only the active ones are included in the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259158#action_259158 ] Julien Nicoulaud edited comment on MPH-82 at 3/7/11 1:10 PM: - It only behaves this way on Maven 3. Everything works fine on Maven 2.2.1. was (Author: nicoulaj): It only behaves this on Maven 3. Everything works fine on Maven 2.2.1. > all-profiles does not show inactive profiles from settings file > --- > > Key: MPH-82 > URL: http://jira.codehaus.org/browse/MPH-82 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Julien Nicoulaud > > The all-profiles goal does not lists the inactive profile from settings.xml. > Only the active ones are included in the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5035) \ -> / on Unix for java.io.File-typed mojo param
[
http://jira.codehaus.org/browse/MNG-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259154#action_259154
]
Jesse Glick commented on MNG-5035:
--
Right, this is in direct conflict with MNG-4464. Versionable files ought to be
using forward slashes (as in URLs) for all relative paths but some presumably
are not.
I found Ant's behavior to be documented, though just barely. Is Maven's
behavior documented anywhere?
http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Simple_Objects
does not talk about File-valued properties except to give a single example. I
would expect to see separators discussed. I would also expect to see what Maven
does with relative paths - {{FileConvertor.fromString}} would imply they are
resolved against CWD, whereas experimentation seems to say they are resolved
against basedir (as in Ant).
> \ -> / on Unix for java.io.File-typed mojo param
>
>
> Key: MNG-5035
> URL: http://jira.codehaus.org/browse/MNG-5035
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.3
> Environment: Ubuntu 10.04, JDK 6
>Reporter: Jesse Glick
>Assignee: Benjamin Bentmann
>
> I created a file {{/tmp/a\b/c}} (note backslash). I created a quickstart app
> with
> {noformat}
> public static void main( String[] args )
> {
> System.out.println( System.getProperty("user.dir") );
> System.out.println(Arrays.toString(new File("").listFiles()));
> }
> {noformat}
> and then run it with
> {noformat}
> mvn -Dexec.workingdir=/tmp/a\\b "-Dexec.args=-classpath %classpath App"
> -Dexec.executable=.../java process-classes
> org.codehaus.mojo:exec-maven-plugin:1.2:exec -X
> {noformat}
> I see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a/b
> [DEBUG] Making working directory '/tmp/a/b'.
> /tmp/a/b
> null
> {noformat}
> where I expected to see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a\b
> /tmp/a\b
> [/tmp/a\b/c]
> {noformat}
> I believe the guilty code is in
> {{org.codehaus.plexus.component.configurator.converters.basic.FileConverter}}:
> {noformat}
> new File( str.replace( '\\', File.separatorChar ).replace( '/',
> File.separatorChar ) )
> {noformat}
> should probably replace only / with \ and only on Windows. Not sure what
> compatibility regressions there might be, if some POM written by a Windows
> developer uses \ as the separator character for relative paths.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MGPG-34) Allow to define an alternative pomFile when sign (gpg:sign) the project artifact
Allow to define an alternative pomFile when sign (gpg:sign) the project artifact Key: MGPG-34 URL: http://jira.codehaus.org/browse/MGPG-34 Project: Maven 2.x GPG Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Laszlo Hordos Attachments: maven-gpg-plugin.patch This small modification allow to specify an alternative pomFile to sign instead of the default project file. It's very useful when a custom pom file has been generated during the build process. I'm using a complex build configuration for a framework where I need to create custom pom files. I'm able create a release from my CI and publish it to the central repository the gpg:sign signs the wrong pom file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5035) \ -> / on Unix for java.io.File-typed mojo param
[
http://jira.codehaus.org/browse/MNG-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5035.
--
Resolution: Not A Bug
For a little more conistency across the platforms, both forms of slashes are
treated as directory separators in our smallish Java app and I have yet to hear
a very good reason that demands the use of backslashes as ordinary filenames
(I'm sorry but "Unix supports it" is not a good reason). Jesse no offense but I
will repeat myself, Maven works as intended (btw, your proposed patch doesn't
help as it yields the very platform-specific behavior mentioned in MNG-4464
that is to be avoided).
Let me close with this example from another not uncommon build tool:
{code:xml}
{code}
{noformat}
bentmann@ubuntu:~/shared/ant$ ant -Ddir.name=foo\\baz
Buildfile: /home/bentmann/shared/ant/build.xml
test:
[mkdir] Created dir: /home/bentmann/shared/ant/foo/baz
BUILD SUCCESSFUL
Total time: 0 seconds
{noformat}
> \ -> / on Unix for java.io.File-typed mojo param
>
>
> Key: MNG-5035
> URL: http://jira.codehaus.org/browse/MNG-5035
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.3
> Environment: Ubuntu 10.04, JDK 6
>Reporter: Jesse Glick
>Assignee: Benjamin Bentmann
>
> I created a file {{/tmp/a\b/c}} (note backslash). I created a quickstart app
> with
> {noformat}
> public static void main( String[] args )
> {
> System.out.println( System.getProperty("user.dir") );
> System.out.println(Arrays.toString(new File("").listFiles()));
> }
> {noformat}
> and then run it with
> {noformat}
> mvn -Dexec.workingdir=/tmp/a\\b "-Dexec.args=-classpath %classpath App"
> -Dexec.executable=.../java process-classes
> org.codehaus.mojo:exec-maven-plugin:1.2:exec -X
> {noformat}
> I see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a/b
> [DEBUG] Making working directory '/tmp/a/b'.
> /tmp/a/b
> null
> {noformat}
> where I expected to see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a\b
> /tmp/a\b
> [/tmp/a\b/c]
> {noformat}
> I believe the guilty code is in
> {{org.codehaus.plexus.component.configurator.converters.basic.FileConverter}}:
> {noformat}
> new File( str.replace( '\\', File.separatorChar ).replace( '/',
> File.separatorChar ) )
> {noformat}
> should probably replace only / with \ and only on Windows. Not sure what
> compatibility regressions there might be, if some POM written by a Windows
> developer uses \ as the separator character for relative paths.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test Could not create log file
mvn test fails for a project managed by source control. It runs well if it is a project off my local workstation. Following is the whole stack trace. Any input would be appreciated. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 6.083s [INFO] Finished at: Mon Mar 07 09:51:51 MST 2011 [INFO] Final Memory: 4M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on project eRepDroolsDemo: There are test failures. [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.612 sec <<< FAILURE! testGreetUserForHello(com.sample.TestDroolsSample) Time elapsed: 3.534 sec <<< ERROR! java.lang.RuntimeException: Could not create the log file. Please make sure that directory that the log file should be placed in does exist. at org.drools.audit.WorkingMemoryFileLogger.initializeLog(WorkingMemoryFileLogger.java:150) at org.drools.audit.WorkingMemoryFileLogger.writeToDisk(WorkingMemoryFileLogger.java:115) at org.drools.audit.KnowledgeRuntimeLoggerProviderImpl$KnowledgeRuntimeFileLoggerWrapper.close(KnowledgeRuntimeLoggerProviderImpl.java:56) at com.sample.DroolsSample.greetUser(DroolsSample.java:41) at com.sample.TestDroolsSample.testGreetUserForHello(TestDroolsSample.java:17) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) 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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at $Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) -- View this message in context: http://maven.40175.n5.nabble.com/Failed-to-execute-goal-org-apache-maven-plugins-maven-surefire-plugin-2-7-1-test-Could-not-create-loe-tp3412739p3412739.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Reopened: (MNG-5035) \ -> / on Unix for java.io.File-typed mojo param
[
http://jira.codehaus.org/browse/MNG-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick reopened MNG-5035:
--
Naturally such paths not portable. The point is that in this case the directory
name is passed as a command-line option (i.e. not as part of the POM) and thus
does not need to be portable. Same would be if it were specified in
{{settings.xml}} and so only applicable to the current machine. Unix permits
file names to contain backslashes, and the correct path including shell escapes
is being passed to Maven, but it mangles it.
Simplest patch would be to use only:
{noformat}
new File( str.replace( '/', File.separatorChar ) )
{noformat}
which would work as now on Windows and return str unmodified on other systems.
> \ -> / on Unix for java.io.File-typed mojo param
>
>
> Key: MNG-5035
> URL: http://jira.codehaus.org/browse/MNG-5035
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.3
> Environment: Ubuntu 10.04, JDK 6
>Reporter: Jesse Glick
>Assignee: Benjamin Bentmann
>
> I created a file {{/tmp/a\b/c}} (note backslash). I created a quickstart app
> with
> {noformat}
> public static void main( String[] args )
> {
> System.out.println( System.getProperty("user.dir") );
> System.out.println(Arrays.toString(new File("").listFiles()));
> }
> {noformat}
> and then run it with
> {noformat}
> mvn -Dexec.workingdir=/tmp/a\\b "-Dexec.args=-classpath %classpath App"
> -Dexec.executable=.../java process-classes
> org.codehaus.mojo:exec-maven-plugin:1.2:exec -X
> {noformat}
> I see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a/b
> [DEBUG] Making working directory '/tmp/a/b'.
> /tmp/a/b
> null
> {noformat}
> where I expected to see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a\b
> /tmp/a\b
> [/tmp/a\b/c]
> {noformat}
> I believe the guilty code is in
> {{org.codehaus.plexus.component.configurator.converters.basic.FileConverter}}:
> {noformat}
> new File( str.replace( '\\', File.separatorChar ).replace( '/',
> File.separatorChar ) )
> {noformat}
> should probably replace only / with \ and only on Windows. Not sure what
> compatibility regressions there might be, if some POM written by a Windows
> developer uses \ as the separator character for relative paths.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds
[ http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259139#action_259139 ] Gin-Ting Chen commented on SUREFIRE-690: Sounds good to me :) > testSetCompleted called before testSetStarting when using m3 parallel builds > > > Key: SUREFIRE-690 > URL: http://jira.codehaus.org/browse/SUREFIRE-690 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.7.1 >Reporter: Gin-Ting Chen >Assignee: Kristian Rosenvold > Fix For: 2.8 > > > This is running m3 with -T 1C (8 core build machine). > [17:52:38]: [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on > project hornet-stinger: Error while executing forked tests.; nested exception > is java.lang.IllegalStateException: testSetCompleted called before > testSetStarting -> [Help 1] > Seems like it doesn't happen as frequently as previously -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds
[ http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259136#action_259136 ] Kristian Rosenvold commented on SUREFIRE-690: - 2.7.2 (released) with the addition of plexus-utils 2.0.7 (released) should be identical to 2.8-.SNAPSHOT wrt this error. I will be releasing 2.8 within the next 48 hours, so I think we can just defer this until 2.8 is released and re-test then. > testSetCompleted called before testSetStarting when using m3 parallel builds > > > Key: SUREFIRE-690 > URL: http://jira.codehaus.org/browse/SUREFIRE-690 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.7.1 >Reporter: Gin-Ting Chen >Assignee: Kristian Rosenvold > Fix For: 2.8 > > > This is running m3 with -T 1C (8 core build machine). > [17:52:38]: [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on > project hornet-stinger: Error while executing forked tests.; nested exception > is java.lang.IllegalStateException: testSetCompleted called before > testSetStarting -> [Help 1] > Seems like it doesn't happen as frequently as previously -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5035) \ -> / on Unix for java.io.File-typed mojo param
[
http://jira.codehaus.org/browse/MNG-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5035.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
Backslashes as ordinary filename characters are not portable and not supported.
> \ -> / on Unix for java.io.File-typed mojo param
>
>
> Key: MNG-5035
> URL: http://jira.codehaus.org/browse/MNG-5035
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.3
> Environment: Ubuntu 10.04, JDK 6
>Reporter: Jesse Glick
>Assignee: Benjamin Bentmann
>
> I created a file {{/tmp/a\b/c}} (note backslash). I created a quickstart app
> with
> {noformat}
> public static void main( String[] args )
> {
> System.out.println( System.getProperty("user.dir") );
> System.out.println(Arrays.toString(new File("").listFiles()));
> }
> {noformat}
> and then run it with
> {noformat}
> mvn -Dexec.workingdir=/tmp/a\\b "-Dexec.args=-classpath %classpath App"
> -Dexec.executable=.../java process-classes
> org.codehaus.mojo:exec-maven-plugin:1.2:exec -X
> {noformat}
> I see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a/b
> [DEBUG] Making working directory '/tmp/a/b'.
> /tmp/a/b
> null
> {noformat}
> where I expected to see
> {noformat}
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
> basic configurator -->
> [DEBUG] (f) workingDirectory = /tmp/a\b
> /tmp/a\b
> [/tmp/a\b/c]
> {noformat}
> I believe the guilty code is in
> {{org.codehaus.plexus.component.configurator.converters.basic.FileConverter}}:
> {noformat}
> new File( str.replace( '\\', File.separatorChar ).replace( '/',
> File.separatorChar ) )
> {noformat}
> should probably replace only / with \ and only on Windows. Not sure what
> compatibility regressions there might be, if some POM written by a Windows
> developer uses \ as the separator character for relative paths.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds
[ http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259132#action_259132 ] Gin-Ting Chen commented on SUREFIRE-690: Hey Kristian, Sry I think I misunderstood you earlier. I added the plexus-utils to surefire 2.7.1 not 2.7.2 and got this error again today. Did you mean that this also needed 2.7.2 to work correctly? Unfortunately I can't switch to 2.8-SNAPSHOT just yet as I am locked to using release only versions ATM. > testSetCompleted called before testSetStarting when using m3 parallel builds > > > Key: SUREFIRE-690 > URL: http://jira.codehaus.org/browse/SUREFIRE-690 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.7.1 >Reporter: Gin-Ting Chen >Assignee: Kristian Rosenvold > Fix For: 2.8 > > > This is running m3 with -T 1C (8 core build machine). > [17:52:38]: [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on > project hornet-stinger: Error while executing forked tests.; nested exception > is java.lang.IllegalStateException: testSetCompleted called before > testSetStarting -> [Help 1] > Seems like it doesn't happen as frequently as previously -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5035) \ -> / on Unix for java.io.File-typed mojo param
\ -> / on Unix for java.io.File-typed mojo param
Key: MNG-5035
URL: http://jira.codehaus.org/browse/MNG-5035
Project: Maven 2 & 3
Issue Type: Bug
Components: Plugin API
Affects Versions: 3.0.3
Environment: Ubuntu 10.04, JDK 6
Reporter: Jesse Glick
I created a file {{/tmp/a\b/c}} (note backslash). I created a quickstart app
with
{noformat}
public static void main( String[] args )
{
System.out.println( System.getProperty("user.dir") );
System.out.println(Arrays.toString(new File("").listFiles()));
}
{noformat}
and then run it with
{noformat}
mvn -Dexec.workingdir=/tmp/a\\b "-Dexec.args=-classpath %classpath App"
-Dexec.executable=.../java process-classes
org.codehaus.mojo:exec-maven-plugin:1.2:exec -X
{noformat}
I see
{noformat}
[DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
basic configurator -->
[DEBUG] (f) workingDirectory = /tmp/a/b
[DEBUG] Making working directory '/tmp/a/b'.
/tmp/a/b
null
{noformat}
where I expected to see
{noformat}
[DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2:exec' with
basic configurator -->
[DEBUG] (f) workingDirectory = /tmp/a\b
/tmp/a\b
[/tmp/a\b/c]
{noformat}
I believe the guilty code is in
{{org.codehaus.plexus.component.configurator.converters.basic.FileConverter}}:
{noformat}
new File( str.replace( '\\', File.separatorChar ).replace( '/',
File.separatorChar ) )
{noformat}
should probably replace only / with \ and only on Windows. Not sure what
compatibility regressions there might be, if some POM written by a Windows
developer uses \ as the separator character for relative paths.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-137) Support for JEE Application Clients
Support for JEE Application Clients --- Key: MEAR-137 URL: http://jira.codehaus.org/browse/MEAR-137 Project: Maven 2.x Ear Plugin Issue Type: New Feature Environment: any Reporter: Pablo Rodriguez Attachments: maven-ear-plugin Currently the maven ear plugin only supports JEE application clients by defining them as jarmodules with true. This is a bit to hacky as Applicaiton client modules are first class EAR citizens as ejb, war and rar modules. The patch provided here is half of my attempt to upgrade this application client modules to be maven ear first citizens. I have created a maven-car-plugin defining a packaging type 'car' (in same manner as war, ejb or rar). http://code.google.com/p/maven-car-plugin/ The patch provided here, adds support to maven-ear-plugin to recognize the 'car' packaging type, include the artifact in the root of the ear and adds the corresponding entry to application.xml Note that i would like this to be temporary and would prefer to see the car packaging type, the maven-car-plugin be core maven plugins with gorupid org.maven.plugins as there is no reason for application clients not having same support as war, ejb or rar modules. I feel this extra module, packaging type and plugin are needed as confusion has been arising around application clients http://jira.codehaus.org/browse/MEAR-46 http://jira.codehaus.org/browse/MEAR-40 Pablo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-700: Fix Version/s: (was: 2.8) 2.8.1 > Surefire is not isolated from itself > > > Key: SUREFIRE-700 > URL: http://jira.codehaus.org/browse/SUREFIRE-700 > Project: Maven Surefire > Issue Type: Improvement > Components: classloading >Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.8.1 > > Attachments: stage2.patch > > > The current classloader structure in surefire does not isolate surefire from > changes to surefire in itself. This means an interface change in *most* > private interfaces and classes can break the build of surefire itself. > This is due to the classloader structure > systemclassloader<-testclassloader<-providerclassloader, where a modified > surefire immediately becomes effective by being loaded in testclassloader. > This issue will be fixed by making the following structure: > systemclassloader<-testframeworkclassloader<-testclassloader > systemclassloader<-testframeworkclassloader<-surefireclassloader > Pardon the ascii graphics but it seems like jira does not allow me to draw > systemclassloader<-testframeworkclassloader as one common root ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5034) Wrong evaluation of {project.artifactId} variable in child POMs if included in element
[
http://jira.codehaus.org/browse/MNG-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259100#action_259100
]
Ivan Mrva commented on MNG-5034:
In our company, we would like to specify a project URL and distribution
management section for site server only at one place - in our organization POM
from which all projects inherit. This solution removes the burden from our
developers, who don't need to know anything about site deployment and also
should not be responsible for defining a project URLs. Currently, this can be
acomplished, but only at the cost of having ugly and unpredictable project URLs.
> Wrong evaluation of {project.artifactId} variable in child POMs if included
> in element
> -
>
> Key: MNG-5034
> URL: http://jira.codehaus.org/browse/MNG-5034
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.3
> Environment: os: 2.6.37-gentoo; jdk "1.6.0_24"
>Reporter: Ivan Mrva
>Assignee: Benjamin Bentmann
>
> Suppose you have the following snippet in your parent POM:
> {code}
> ...
> parent
> ...
> https://intranet.xy.sk/javaweb/${project.artifactId}
>
>
> site-server
> Site Server
> https://intranet.xy.sk/javaweb/${project.artifactId}
>
>
> ...
> {code}
> Then 'mvn help:effective-pom' command for this project will produce correct
> URL values:
> - https://intranet.xy.sk/javaweb/parent
> - dav:https://intranet.xy.sk/javaweb/parent
> But, if you create a child project that declares above defined POM as a
> parent (and does not explicitly specify its own or
> sections, i.e. it should inherit these sections from
> parent), the output from 'mvn help:effective-pom' command will contain wrong
> values:
> * e.g. for the child POM with artifactId = 'child', the output is:
> ** https://intranet.xy.sk/javaweb/child/child
> ** and dav:https://intranet.xy.sk/javaweb/child/child in
> 'distributionManagement' section.
> *** I think correct output should end only with one 'child' at the end of the
> url as follows: https://intranet.xy.sk/javaweb/child
> * and if you have a sub-module 'grandchild' of this child project, which also
> defines this 'child' artifact as its parent, the output is:
> ** https://intranet.xy.sk/javaweb/grandchild/child/grandchild
> ** dav:https://intranet.xy.sk/javaweb/grandchild/child/grandchild
> *** The correct output should be:
> https://intranet.xy.sk/javaweb/child/grandchild
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (SUREFIRE-537) Rason for the Ignored/Skipped testcases is not reported
[
http://jira.codehaus.org/browse/SUREFIRE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SUREFIRE-537 stopped by Kristian Rosenvold.
> Rason for the Ignored/Skipped testcases is not reported
> ---
>
> Key: SUREFIRE-537
> URL: http://jira.codehaus.org/browse/SUREFIRE-537
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, Maven Surefire Report Plugin, xml
> generation
>Affects Versions: 2.4.3
> Environment: Windows XP, junit 4.4
>Reporter: Rakesh Arora
>Assignee: Kristian Rosenvold
> Fix For: 2.8
>
>
> Tests that are skipped with a @Ignore("Test doesn't work") annotation only
> appear in the report as an increment in the "Skipped" column. Name of the
> skipped testcases is also reported. However, the reason (i.e. "Test doesn't
> work") is not reported.
> Quick look at the source code, it seems that it is not implemented:
> In class: org.apache.maven.plugins.surefire.report.TestSuiteXmlParser
> else if ( "skipped".equals( qName ) )
> {
> testCase.addFailure( "skipped", "skipped" ); // TODO extract
> real reasons
> currentSuite.setNumberOfSkipped( 1 +
> currentSuite.getNumberOfSkipped() );
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5034) Wrong evaluation of {project.artifactId} variable in child POMs if included in element
[
http://jira.codehaus.org/browse/MNG-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5034.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
> Wrong evaluation of {project.artifactId} variable in child POMs if included
> in element
> -
>
> Key: MNG-5034
> URL: http://jira.codehaus.org/browse/MNG-5034
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.3
> Environment: os: 2.6.37-gentoo; jdk "1.6.0_24"
>Reporter: Ivan Mrva
>Assignee: Benjamin Bentmann
>
> Suppose you have the following snippet in your parent POM:
> {code}
> ...
> parent
> ...
> https://intranet.xy.sk/javaweb/${project.artifactId}
>
>
> site-server
> Site Server
> https://intranet.xy.sk/javaweb/${project.artifactId}
>
>
> ...
> {code}
> Then 'mvn help:effective-pom' command for this project will produce correct
> URL values:
> - https://intranet.xy.sk/javaweb/parent
> - dav:https://intranet.xy.sk/javaweb/parent
> But, if you create a child project that declares above defined POM as a
> parent (and does not explicitly specify its own or
> sections, i.e. it should inherit these sections from
> parent), the output from 'mvn help:effective-pom' command will contain wrong
> values:
> * e.g. for the child POM with artifactId = 'child', the output is:
> ** https://intranet.xy.sk/javaweb/child/child
> ** and dav:https://intranet.xy.sk/javaweb/child/child in
> 'distributionManagement' section.
> *** I think correct output should end only with one 'child' at the end of the
> url as follows: https://intranet.xy.sk/javaweb/child
> * and if you have a sub-module 'grandchild' of this child project, which also
> defines this 'child' artifact as its parent, the output is:
> ** https://intranet.xy.sk/javaweb/grandchild/child/grandchild
> ** dav:https://intranet.xy.sk/javaweb/grandchild/child/grandchild
> *** The correct output should be:
> https://intranet.xy.sk/javaweb/child/grandchild
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5034) Wrong evaluation of {project.artifactId} variable in child POMs if included in element
Wrong evaluation of {project.artifactId} variable in child POMs if included in
element
-
Key: MNG-5034
URL: http://jira.codehaus.org/browse/MNG-5034
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.3
Environment: os: 2.6.37-gentoo; jdk "1.6.0_24"
Reporter: Ivan Mrva
Suppose you have the following snippet in your parent POM:
{code}
...
parent
...
https://intranet.xy.sk/javaweb/${project.artifactId}
site-server
Site Server
https://intranet.xy.sk/javaweb/${project.artifactId}
...
{code}
Then 'mvn help:effective-pom' command for this project will produce correct URL
values:
- https://intranet.xy.sk/javaweb/parent
- dav:https://intranet.xy.sk/javaweb/parent
But, if you create a child project that declares above defined POM as a parent
(and does not explicitly specify its own or
sections, i.e. it should inherit these sections from parent), the output from
'mvn help:effective-pom' command will contain wrong values:
* e.g. for the child POM with artifactId = 'child', the output is:
** https://intranet.xy.sk/javaweb/child/child
** and dav:https://intranet.xy.sk/javaweb/child/child in
'distributionManagement' section.
*** I think correct output should end only with one 'child' at the end of the
url as follows: https://intranet.xy.sk/javaweb/child
* and if you have a sub-module 'grandchild' of this child project, which also
defines this 'child' artifact as its parent, the output is:
** https://intranet.xy.sk/javaweb/grandchild/child/grandchild
** dav:https://intranet.xy.sk/javaweb/grandchild/child/grandchild
*** The correct output should be:
https://intranet.xy.sk/javaweb/child/grandchild
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-700: Component/s: classloading > Surefire is not isolated from itself > > > Key: SUREFIRE-700 > URL: http://jira.codehaus.org/browse/SUREFIRE-700 > Project: Maven Surefire > Issue Type: Improvement > Components: classloading >Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.8 > > Attachments: stage2.patch > > > The current classloader structure in surefire does not isolate surefire from > changes to surefire in itself. This means an interface change in *most* > private interfaces and classes can break the build of surefire itself. > This is due to the classloader structure > systemclassloader<-testclassloader<-providerclassloader, where a modified > surefire immediately becomes effective by being loaded in testclassloader. > This issue will be fixed by making the following structure: > systemclassloader<-testframeworkclassloader<-testclassloader > systemclassloader<-testframeworkclassloader<-surefireclassloader > Pardon the ascii graphics but it seems like jira does not allow me to draw > systemclassloader<-testframeworkclassloader as one common root ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-531) Extend -Dtest to let test *methods* to be specified, rather than just test classes.
[ http://jira.codehaus.org/browse/SUREFIRE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-531. --- Resolution: Duplicate The duplicate is fixed so I'm closing this > Extend -Dtest to let test *methods* to be specified, rather than just test > classes. > --- > > Key: SUREFIRE-531 > URL: http://jira.codehaus.org/browse/SUREFIRE-531 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Haikal Saadh >Priority: Minor > > It would be nice if -Dtest could be used to run a certain test method. For > example, > mvn surefire:surefire -Dtest=TestFoo/testMyFailingTest -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259090#action_259090 ] Maarten Billemont edited comment on MDEP-208 at 3/7/11 4:09 AM: So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is and regardless of whether the artifacts are in the reactor or not. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. was (Author: lhunath): So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Billemont reopened MDEP-208: Given the above comment, this issue needs to be re-evaluated. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259090#action_259090 ] Maarten Billemont commented on MDEP-208: So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-306) 2.2 unpack does not handle space in includes
2.2 unpack does not handle space in includes Key: MDEP-306 URL: http://jira.codehaus.org/browse/MDEP-306 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.2 Environment: Windows XP, Java 6 Reporter: Anthony Whitford Assignee: Brian Fox Priority: Critical Upgrading to 2.2 broke my build and I traced the root cause to the fact that I am calling unpack against a zip file and my includes specifies a filename pattern with a space in the directory name. This works fine if I roll back to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching the includes spec). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
