[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16283179#comment-16283179
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@mpkorstanje
@ckurban
@sworisbreathing
I could not merge and release this PR because the class
`FailingMethodFilter.java` in [1] was deleted.
We have to have it back and find root cause and good cure.
I may have spare time during the weekend but this troubleshooting may take
several days to understand the cure.
[1]:
https://github.com/apache/maven-surefire/pull/150/commits/780e878a3c2d15547bc0157ebef67de793b06862
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...
Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/150 @sworisbreathing Let me go through these changes again. ---
[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...
Github user sworisbreathing commented on the issue: https://github.com/apache/maven-surefire/pull/150 @Tibor17 have there been any updates for this? I'm pretty keen to start using the new version if it fixes support for Cucumber tests with `rerunFailingTestCount` in surefire/failsafe. ---
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16283078#comment-16283078
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@sworisbreathing
Let me go through these changes again.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-317) Plugin generates wrong modulepath (dependencies listed in wrong order)
[
https://issues.apache.org/jira/browse/MCOMPILER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282467#comment-16282467
]
Robert Scholte commented on MCOMPILER-317:
--
You can try plexus-java-0.9.6-SNAPSHOT from
https://oss.sonatype.org/content/repositories/plexus-snapshots/
But it looks like there's more going on. Running with debug you'll see the
classpath parameter (untouched) and it's order is already different to what I
expect. There might be a deeper problem here and all plugins using the
classpath will have this issue.
> Plugin generates wrong modulepath (dependencies listed in wrong order)
> --
>
> Key: MCOMPILER-317
> URL: https://issues.apache.org/jira/browse/MCOMPILER-317
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T03:58:13-04:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gili
>
> Testcase: https://github.com/cowwoc/maven-java9-class-shadowing
> If a project contains dependencies with the same module name (which is valid
> according to https://stackoverflow.com/a/46573805/14731) then
> maven-compile-plugin invokes {{javac}} with a modulepath containing
> dependencies in an (apparently) arbitrary order. If I place the project in
> one directory, I get one order. If I place the project in another directory,
> I get another order. This is 100% reproducible across multiple runs, across
> different computers.
> I suspect that somewhere deep inside the code someone is using {{HashMap}}
> which is leading to undefined iteration order depending on the path being
> used.
> Expected behavior: dependencies should be listed in the same order as
> declared in pom.xml (see https://stackoverflow.com/a/793193/14731)
> Actual behavior: regardless of whether I list {{ExtensionPresent}} before or
> after {{MyLibrary}}, the wrong order gets passed to {{javac}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282820#comment-16282820
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user sworisbreathing commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@Tibor17 have there been any updates for this? I'm pretty keen to start
using the new version if it fixes support for Cucumber tests with
`rerunFailingTestCount` in surefire/failsafe.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MSHARED-665) ASMDependencyAnalyzer.analyze(...) returns non-classes
[
https://issues.apache.org/jira/browse/MSHARED-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282509#comment-16282509
]
Andreas Sewe commented on MSHARED-665:
--
While the {{maven-dependency-analyzer}} project has unit tests, it only has a
{{DefaultProjectDependencyAnalyzerTest}}, but lacks an
{{ASMDependencyAnalyzerTest}}. Hence, this bugs goes unnoticed.
> ASMDependencyAnalyzer.analyze(...) returns non-classes
> --
>
> Key: MSHARED-665
> URL: https://issues.apache.org/jira/browse/MSHARED-665
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.7
>Reporter: Andreas Sewe
> Attachments: example.zip
>
>
> The {{ASMDependencyAnalyzer}} returns far to many bogus entries, which are
> not class names at all.
> The following is taken when the attached example project analyzes itself
> ({{java -jar target/dependency-analyzer-test-0.0.1-SNAPSHOT.jar
> file:target/dependency-analyzer-test-0.0.1-SNAPSHOT.jar}}):
> {noformat}
> Error retrieving checksum file for
> charset=([.[^; ]]*)
> java.lang.reflect.Array
> Unable to resolve context key:
> RuntimeInvisibleAnnotations
> javax.swing.tree.TreeModel
> Repetition count must be > 0
> project information for
> empty
> {noformat}
> Note that this is not a problem in the classic {{dependency:analyze}} use
> case: The goal simply computes the set of class dependencies (which contain
> the aforementioned bogus class names) of the current project and compares
> them with the set of classes of its dependencies (this set is fine).
> If one wants to use the {{ASMDependencyAnalyzer}} as a standalone component,
> however, these bogus class name make it pretty much *useless*.
> Also, even in the {{dependency:analyze}} case, operating with sets that are a
> lot larger than necessary (there are typically way more strings than class
> names) may impact performance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1451) Surefire Booter compatibility with NetBSD ps(1) output
[ https://issues.apache.org/jira/browse/SUREFIRE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1451: --- Fix Version/s: 2.21.0.Jigsaw > Surefire Booter compatibility with NetBSD ps(1) output > -- > > Key: SUREFIRE-1451 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1451 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.20.1 > Environment: NetBSD >Reporter: Tobias Nygren >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.21.0.Jigsaw > > > On NetBSD The /bin/ps command reports time as 0:01 rather than 00:01 for > intervals shorter than 10 minutes. > The pattern as used [here in SureFire > Booter|https://github.com/apache/maven-surefire/commit/c343cc412b986fd9da839696c709542d03679d68#diff-33826e7c2cc48fb008e88914fd841d10R71] > to parse ps(1) output does not take this into account. > printf(3) logic for ps(1) can be found in the [ps > source|https://github.com/NetBSD/src/blob/9160f3e067c6f959b9ecb4296771d8a6ae9b3ee6/bin/ps/print.c#L832]. > The following patterns are possible and need to be accounted for: > * m:ss > * mm:ss > * h:mm:ss > * hh:mm:ss > * d-hh:mm:ss > * dd-hh:mm:ss -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-317) Plugin generates wrong modulepath (dependencies listed in wrong order)
[
https://issues.apache.org/jira/browse/MCOMPILER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282437#comment-16282437
]
Gili commented on MCOMPILER-317:
[~rfscholte] I noticed that you fixed
https://github.com/codehaus-plexus/plexus-languages/issues/4
Let me know once you have a SNAPSHOT release of MCOMPILER and I'll verify the
fix on my end.
Also, I'd like to know how you wish to proceed with
https://github.com/mojohaus/exec-maven-plugin/issues/91. Can you use the
testcase I posted to investigate the cause there?
Thank you.
> Plugin generates wrong modulepath (dependencies listed in wrong order)
> --
>
> Key: MCOMPILER-317
> URL: https://issues.apache.org/jira/browse/MCOMPILER-317
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T03:58:13-04:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gili
>
> Testcase: https://github.com/cowwoc/maven-java9-class-shadowing
> If a project contains dependencies with the same module name (which is valid
> according to https://stackoverflow.com/a/46573805/14731) then
> maven-compile-plugin invokes {{javac}} with a modulepath containing
> dependencies in an (apparently) arbitrary order. If I place the project in
> one directory, I get one order. If I place the project in another directory,
> I get another order. This is 100% reproducible across multiple runs, across
> different computers.
> I suspect that somewhere deep inside the code someone is using {{HashMap}}
> which is leading to undefined iteration order depending on the path being
> used.
> Expected behavior: dependencies should be listed in the same order as
> declared in pom.xml (see https://stackoverflow.com/a/793193/14731)
> Actual behavior: regardless of whether I list {{ExtensionPresent}} before or
> after {{MyLibrary}}, the wrong order gets passed to {{javac}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1444) /usr/bin/ps and /bin/ps not found. Forked JVM fails.
[ https://issues.apache.org/jira/browse/SUREFIRE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1444: --- Summary: /usr/bin/ps and /bin/ps not found. Forked JVM fails. (was: org.apache.maven.surefire.booter.SurefireBooterForkException) > /usr/bin/ps and /bin/ps not found. Forked JVM fails. > > > Key: SUREFIRE-1444 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1444 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.20.1 > Environment: Windows 7 Pro 64 bits > Maven 3.5.2 , jdk 1.8.0_152 >Reporter: rfs >Assignee: Tibor Digana > Fix For: 2.21.0.Jigsaw > > Attachments: dump.txt, mavenlog.txt > > > mvn test is failed with maven 3.5.2, jdk 1.8.0_x, maven surefire 2.20.1 > maven repository is deleted before but same result. > mvn test is successfull with maven 3.5.2, jdk 1.8.0_x, maven surefire 2.19.1 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 9.490 s > [INFO] Finished at: 2017-11-16T08:58:19+01:00 > [INFO] Final Memory: 35M/290M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on > project project-name: There are test fa > ilures. > [ERROR] > [ERROR] Please refer to R:\src\project-name\target\surefire-reports for the > individual test results. > [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, > [date].dumpstream and [date]-jvmRun[N].dumpstream. > [ERROR] The forked VM terminated without properly saying goodbye. VM crash or > System.exit called? > [ERROR] Command was cmd.exe /X /C "R:\tools\jdk1.8.0_152\jre\bin\java -jar > d:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195\sur > efirebooter7359328160006854832.jar > D:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195 > 2017-11-16T08-58-14_352-jvmRun1 surefire80634 > 62497440390334tmp surefire_0627218662296028436tmp" > [ERROR] Error occurred in starting fork, check output in log > [ERROR] Process Exit Code: 1 > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The > forked VM terminated without properly saying goodbye. VM crash or System.exi > t called? > [ERROR] Command was cmd.exe /X /C "R:\tools\jdk1.8.0_152\jre\bin\java -jar > d:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195\sur > efirebooter7359328160006854832.jar > D:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195 > 2017-11-16T08-58-14_352-jvmRun1 surefire80634 > 62497440390334tmp surefire_0627218662296028436tmp" > [ERROR] Error occurred in starting fork, check output in log > [ERROR] Process Exit Code: 1 > [ERROR] at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686) > [ERROR] at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535) > [ERROR] at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280) > [ERROR] at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832) > [ERROR] at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) > [ERROR] at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > [ERROR] at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > [ERROR] at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > [ERROR] at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > [ERROR] at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) > [ERROR] at >
[jira] [Commented] (MNG-6300) Multi module release creates empty directories in war file instead of jars
[
https://issues.apache.org/jira/browse/MNG-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282438#comment-16282438
]
Robert Scholte commented on MNG-6300:
-
Confirmed. It is enough to run {{mvn verify site}} to reproduce and to have a
look at {{mm-war/target/mm-war-1.0.0-SNAPSHOT/WEB-INF/lib}}
> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Priority: Critical
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug
> with multi module builds.
> If one of the modules is a war module and depends on another module, the
> dependency module will not be included as a jar file in WEB-INF/lib of the
> war file, but as an empty directory instead. Non module dependencies will be
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> - element is present, so that release goals
> are "deploy site-deploy"
> - element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war
> file is ok, while "mvn release:perform" creates corrupt files as described.
> Also, if javadoc-maven-plugin is not present in block, the war
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or
> even javadoc-plugin related, so I file it here. I prepared a minimal self
> contained example and attach it as mm.zip. To run the example, the following
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJAVADOC-503) link from package-info.java to classes do no longer work
Ernst Reissner created MJAVADOC-503:
---
Summary: link from package-info.java to classes do no longer work
Key: MJAVADOC-503
URL: https://issues.apache.org/jira/browse/MJAVADOC-503
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.0
Environment: linux
Reporter: Ernst Reissner
This bug has been introduced in version 3.0.0, definitively not present in
3.0;0.-M1:
{@link ClassName} within package-info.java no longer works for ClassName in the
same package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MRESOURCES-162) Fail build if resource not fully filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282018#comment-16282018 ] Deepak Abraham commented on MRESOURCES-162: --- Very much required to have a configurable flag as a safety net, so that build fails in these cases > Fail build if resource not fully filtered > -- > > Key: MRESOURCES-162 > URL: https://issues.apache.org/jira/browse/MRESOURCES-162 > Project: Maven Resources Plugin > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexey Markevich >Priority: Minor > Fix For: backlog > > > Scenario: project with some kind resource affected to the project properties. > If some property renamed then resource will contains placeholder instead of > actual value. It will be great to have configuration option like 'Fails if > property missing'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1330) JUnit 5 surefire-provider code donation
[ https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281941#comment-16281941 ] Aurélien Pupier edited comment on SUREFIRE-1330 at 12/7/17 2:47 PM: Can someone summarize what is the current status? I can see several PRs which has been rejected in favor of a "junit5" branch but I don't know to which issue the junit5 branch was created and where the status of this specific branch can be followed. was (Author: apupier): an someone summarize what is the current status? I can see several PRs which has been rejected in favor of a "junit5" branch but I don't know to which issue the junit5 branch was created and where the status of this specific branch can be followed. > JUnit 5 surefire-provider code donation > --- > > Key: SUREFIRE-1330 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1330 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Benedikt Ritter >Assignee: Tibor Digana > Labels: junit5 > Fix For: 3.0-RC1 > > Attachments: junit-platform-surefire-provider.zip > > > The JUnit team wishes to contribute their surefire provider implementation > for JUnit 5 to the Maven team. > The code is currently located at GitHub: > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > They have recently relicensed the code under terms of Apache License 2.0: > https://github.com/junit-team/junit5/issues/541 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1330) JUnit 5 surefire-provider code donation
[ https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281941#comment-16281941 ] Aurélien Pupier commented on SUREFIRE-1330: --- an someone summarize what is the current status? I can see several PRs which has been rejected in favor of a "junit5" branch but I don't know to which issue the junit5 branch was created and where the status of this specific branch can be followed. > JUnit 5 surefire-provider code donation > --- > > Key: SUREFIRE-1330 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1330 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Benedikt Ritter >Assignee: Tibor Digana > Labels: junit5 > Fix For: 3.0-RC1 > > Attachments: junit-platform-surefire-provider.zip > > > The JUnit team wishes to contribute their surefire provider implementation > for JUnit 5 to the Maven team. > The code is currently located at GitHub: > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > They have recently relicensed the code under terms of Apache License 2.0: > https://github.com/junit-team/junit5/issues/541 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6300) Multi module release creates empty directories in war file instead of jars
[
https://issues.apache.org/jira/browse/MNG-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kurth updated MNG-6300:
---
Attachment: mm.zip
maven-javadoc-plugin:3.0.0
Problem still exists.
> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Priority: Critical
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug
> with multi module builds.
> If one of the modules is a war module and depends on another module, the
> dependency module will not be included as a jar file in WEB-INF/lib of the
> war file, but as an empty directory instead. Non module dependencies will be
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> - element is present, so that release goals
> are "deploy site-deploy"
> - element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war
> file is ok, while "mvn release:perform" creates corrupt files as described.
> Also, if javadoc-maven-plugin is not present in block, the war
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or
> even javadoc-plugin related, so I file it here. I prepared a minimal self
> contained example and attach it as mm.zip. To run the example, the following
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6300) Multi module release creates empty directories in war file instead of jars
[
https://issues.apache.org/jira/browse/MNG-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kurth updated MNG-6300:
---
Attachment: (was: mm.zip)
> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Priority: Critical
> Attachments: build.log
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug
> with multi module builds.
> If one of the modules is a war module and depends on another module, the
> dependency module will not be included as a jar file in WEB-INF/lib of the
> war file, but as an empty directory instead. Non module dependencies will be
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> - element is present, so that release goals
> are "deploy site-deploy"
> - element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war
> file is ok, while "mvn release:perform" creates corrupt files as described.
> Also, if javadoc-maven-plugin is not present in block, the war
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or
> even javadoc-plugin related, so I file it here. I prepared a minimal self
> contained example and attach it as mm.zip. To run the example, the following
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
