[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841740#comment-16841740 ] Hudson commented on MNG-6573: - Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » master #11 See https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/master/11/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-818) Issue management URL in maven-artifact-transfer returns 404
[ https://issues.apache.org/jira/browse/MSHARED-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841741#comment-16841741 ] Hudson commented on MSHARED-818: Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » master #11 See https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/master/11/ > Issue management URL in maven-artifact-transfer returns 404 > --- > > Key: MSHARED-818 > URL: https://issues.apache.org/jira/browse/MSHARED-818 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-artifact-transfer >Reporter: Gabriel Belingueres >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-artifact-transfer-0.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Issue management URL in pom.xml gives 404: > https://issues.apache.org/jira/browse/MSHARED/component/12327114 > > Replace it with this one? > https://issues.apache.org/jira/issues/?jql=project+%3D+MSHARED+AND+component+%3D+maven-artifact-transfer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-818) Issue management URL in maven-artifact-transfer returns 404
[ https://issues.apache.org/jira/browse/MSHARED-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-818: - Fix Version/s: maven-artifact-transfer-0.12.0 > Issue management URL in maven-artifact-transfer returns 404 > --- > > Key: MSHARED-818 > URL: https://issues.apache.org/jira/browse/MSHARED-818 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-artifact-transfer >Reporter: Gabriel Belingueres >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-artifact-transfer-0.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Issue management URL in pom.xml gives 404: > https://issues.apache.org/jira/browse/MSHARED/component/12327114 > > Replace it with this one? > https://issues.apache.org/jira/issues/?jql=project+%3D+MSHARED+AND+component+%3D+maven-artifact-transfer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-818) Issue management URL in maven-artifact-transfer returns 404
[ https://issues.apache.org/jira/browse/MSHARED-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MSHARED-818. Resolution: Fixed > Issue management URL in maven-artifact-transfer returns 404 > --- > > Key: MSHARED-818 > URL: https://issues.apache.org/jira/browse/MSHARED-818 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-artifact-transfer >Reporter: Gabriel Belingueres >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-artifact-transfer-0.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Issue management URL in pom.xml gives 404: > https://issues.apache.org/jira/browse/MSHARED/component/12327114 > > Replace it with this one? > https://issues.apache.org/jira/issues/?jql=project+%3D+MSHARED+AND+component+%3D+maven-artifact-transfer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MSHARED-818) Issue management URL in maven-artifact-transfer returns 404
[ https://issues.apache.org/jira/browse/MSHARED-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-818: Assignee: Sylwester Lachiewicz > Issue management URL in maven-artifact-transfer returns 404 > --- > > Key: MSHARED-818 > URL: https://issues.apache.org/jira/browse/MSHARED-818 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-artifact-transfer >Reporter: Gabriel Belingueres >Assignee: Sylwester Lachiewicz >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Issue management URL in pom.xml gives 404: > https://issues.apache.org/jira/browse/MSHARED/component/12327114 > > Replace it with this one? > https://issues.apache.org/jira/issues/?jql=project+%3D+MSHARED+AND+component+%3D+maven-artifact-transfer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-792) Maven Dependency Analyzer ignores Java 8 type annotations on local variables
[ https://issues.apache.org/jira/browse/MSHARED-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-792: - Fix Version/s: (was: maven-dependency-analyzer-3.0.0) > Maven Dependency Analyzer ignores Java 8 type annotations on local variables > > > Key: MSHARED-792 > URL: https://issues.apache.org/jira/browse/MSHARED-792 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Andreas Hubold >Assignee: Sylwester Lachiewicz >Priority: Major > Attachments: example.tgz > > Time Spent: 20m > Remaining Estimate: 0h > > The Maven Dependency Analyzer's DefaultMethodVisitor does not overwrite > org.objectweb.asm.MethodVisitor#visitLocalVariableAnnotation. Because of > this, type annotations on local variables are not detected. > Attached example Maven project to reproduce the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-810) Support Java 12
[ https://issues.apache.org/jira/browse/MSHARED-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841709#comment-16841709 ] Sylwester Lachiewicz commented on MSHARED-810: -- now in master we have 1.11.2-SNAPSHOT - I think 1.12 would be great. > Support Java 12 > --- > > Key: MSHARED-810 > URL: https://issues.apache.org/jira/browse/MSHARED-810 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Rune Flobakk >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: Java12 > Time Spent: 10m > Remaining Estimate: 0h > > ASM 7.1 supports Java 12 (and supposedly Java 13): > [https://asm.ow2.io/versions.html] > I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on > a Java 12 project, and it works fine with only the dependency update. > [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] > I am happy to make a pull request for it! > (or if you prefer to just make the simple change yourself, that's would of > course also be great. Just wanted to let you know of the simple change to > make it compatible with Java 12) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-810) Support Java 12
[ https://issues.apache.org/jira/browse/MSHARED-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-810: - Fix Version/s: (was: maven-dependency-analyzer-3.0.0) > Support Java 12 > --- > > Key: MSHARED-810 > URL: https://issues.apache.org/jira/browse/MSHARED-810 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Rune Flobakk >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: Java12 > Time Spent: 10m > Remaining Estimate: 0h > > ASM 7.1 supports Java 12 (and supposedly Java 13): > [https://asm.ow2.io/versions.html] > I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on > a Java 12 project, and it works fine with only the dependency update. > [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] > I am happy to make a pull request for it! > (or if you prefer to just make the simple change yourself, that's would of > course also be great. Just wanted to let you know of the simple change to > make it compatible with Java 12) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEPLOY-257) SSH Permission denied
[
https://issues.apache.org/jira/browse/MDEPLOY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Santos updated MDEPLOY-257:
-
Description:
When running maven goal `deploy`, the plugin fails with error
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project dragonfly-raspberyclient: Failed to retrieve remote metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml: Could
not transfer metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml from/to
ssh-repository (scpexe://192.168.1.3/~): Exit code: 1 - pi@192.168.1.3:
Permission denied (publickey,password). -> [Help 1]
{code}
The host is not the problem as I am able to access it through the terminal.
This only happens with the plugin. The password has been set in my settings.xml
file.
This is my pom file:
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.dragonfly
dragonfly-raspberyclient
1.0-SNAPSHOT
~/Dragonfly
192.168.1.3
pi
raspberry
ssh-repository
scpexe://192.168.1.3/~
org.apache.maven.wagon
wagon-ssh-external
1.0-beta-6
org.apache.maven.plugins
maven-jar-plugin
2.6
true
lib/
Main
org.apache.maven.plugins
maven-shade-plugin
3.2.1
org.apache.maven.plugins
maven-deploy-plugin
3.0.0-M1
maven-plugin
com.pi4j
pi4j-core
0.0.5
{code}
And my settings.xml file:
{noformat}
http://maven.apache.org/SETTINGS/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>
ssh-repository
pi
raspberry
{noformat}
was:
When running maven goal `deploy`, the plugin fails with error
{code:java}
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project dragonfly-raspberyclient: Failed to retrieve remote
metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml: Could
not transfer metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml from/to
ssh-repository (scpexe://192.168.1.4/~): Exit code: 1 - ssh: connect to host
192.168.1.4 port 22: Connection refused -> [Help 1]
{code}
The host is not the problem as I am able to access it through the terminal.
This only happens with the plugin. The password has been set in my settings.xml
file.
This is my pom file:
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.dragonfly
dragonfly-raspberyclient
1.0-SNAPSHOT
~/Dragonfly
192.168.1.3
pi
raspberry
ssh-repository
scpexe://192.168.1.4/~
org.apache.maven.wagon
wagon-ssh-external
1.0-beta-6
org.apache.maven.plugins
maven-jar-plugin
2.6
true
lib/
Main
org.apache.maven.plugins
maven-shade-plugin
3.2.1
org.apache.maven.plugins
maven-deploy-plugin
3.0.0-M1
maven-plugin
com.pi4j
pi4j-core
0.0.5
{code}
And my settings.xml file:
{noformat}
http://maven.apache.org/SETTINGS/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>
ssh-repository
pi
raspberry
{noformat}
Summary: SSH Permission denied (was: SSH Connection Refused)
> SSH Permission denied
> -
>
> Key: MDEPLOY-257
> URL: https://issues.apache.org/jira/browse/MDEPLOY-257
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> Environment: OS: Windows 10 Pro
> IDE: IntelliJ IDEA 2018.1.16 Community
>Reporter: Andre Santos
>Priority: Major
>
> When running maven goal `deploy`, the plugin fails with error
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project dragonfly-raspberyclient: Failed to retrieve remote metadata
> com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml: Could
> not transfer metadata
> com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml
> from/to ssh-repository (scpexe://192.168.1.3/~): Exit code: 1 -
> pi@192.168.1.3: Permission denied (publickey,password). -> [Help 1]
> {code}
>
> The host is not the problem as I am able to access it through the terminal.
> This only happens with the plugin. The password has been set in my
> settings.xml file.
> This is my pom file:
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://w
[jira] [Updated] (MDEPLOY-257) SSH Connection Refused
[
https://issues.apache.org/jira/browse/MDEPLOY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Santos updated MDEPLOY-257:
-
Summary: SSH Connection Refused (was: SSH Connection Closed)
> SSH Connection Refused
> --
>
> Key: MDEPLOY-257
> URL: https://issues.apache.org/jira/browse/MDEPLOY-257
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> Environment: OS: Windows 10 Pro
> IDE: IntelliJ IDEA 2018.1.16 Community
>Reporter: Andre Santos
>Priority: Major
>
> When running maven goal `deploy`, the plugin fails with error
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project dragonfly-raspberyclient: Failed to retrieve remote metadata
> com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml: Could
> not transfer metadata
> com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml
> from/to ssh-repository (scpexe://192.168.1.4/~): Exit code: 1 - ssh: connect
> to host 192.168.1.4 port 22: Connection refused -> [Help 1]
> {code}
> The host is not the problem as I am able to access it through the terminal.
> This only happens with the plugin. The password has been set in my
> settings.xml file.
> This is my pom file:
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.dragonfly
> dragonfly-raspberyclient
> 1.0-SNAPSHOT
>
> ~/Dragonfly
> 192.168.1.3
> pi
> raspberry
>
>
>
> ssh-repository
> scpexe://192.168.1.4/~
>
>
>
>
>
>
> org.apache.maven.wagon
> wagon-ssh-external
> 1.0-beta-6
>
>
>
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.6
>
>
>
> true
> lib/
> Main
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.2.1
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 3.0.0-M1
> maven-plugin
>
>
>
> com.pi4j
> pi4j-core
> 0.0.5
>
>
> {code}
>
>
> And my settings.xml file:
> {noformat}
>
> http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>
>
> ssh-repository
> pi
> raspberry
>
>
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEPLOY-257) SSH Connection Closed
Andre Santos created MDEPLOY-257:
Summary: SSH Connection Closed
Key: MDEPLOY-257
URL: https://issues.apache.org/jira/browse/MDEPLOY-257
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 3.0.0-M1
Environment: OS: Windows 10 Pro
IDE: IntelliJ IDEA 2018.1.16 Community
Reporter: Andre Santos
When running maven goal `deploy`, the plugin fails with error
{code:java}
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project dragonfly-raspberyclient: Failed to retrieve remote
metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml: Could
not transfer metadata
com.dragonfly:dragonfly-raspberyclient:1.0-SNAPSHOT/maven-metadata.xml from/to
ssh-repository (scpexe://192.168.1.4/~): Exit code: 1 - ssh: connect to host
192.168.1.4 port 22: Connection refused -> [Help 1]
{code}
The host is not the problem as I am able to access it through the terminal.
This only happens with the plugin. The password has been set in my settings.xml
file.
This is my pom file:
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.dragonfly
dragonfly-raspberyclient
1.0-SNAPSHOT
~/Dragonfly
192.168.1.3
pi
raspberry
ssh-repository
scpexe://192.168.1.4/~
org.apache.maven.wagon
wagon-ssh-external
1.0-beta-6
org.apache.maven.plugins
maven-jar-plugin
2.6
true
lib/
Main
org.apache.maven.plugins
maven-shade-plugin
3.2.1
org.apache.maven.plugins
maven-deploy-plugin
3.0.0-M1
maven-plugin
com.pi4j
pi4j-core
0.0.5
{code}
And my settings.xml file:
{noformat}
http://maven.apache.org/SETTINGS/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>
ssh-repository
pi
raspberry
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-shade-plugin] slachiewicz commented on issue #7: Use java 7 features
slachiewicz commented on issue #7: Use java 7 features URL: https://github.com/apache/maven-shade-plugin/pull/7#issuecomment-493170747 Done in 0562c51e9929911c75a11c4dfb1f4a1a84d5716c and 0562c51e9929911c75a11c4dfb1f4a1a84d5716c This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-pmd-plugin] adangel commented on a change in pull request #11: MPMD-288 Fixed NullPointerException
adangel commented on a change in pull request #11: MPMD-288 Fixed
NullPointerException
URL: https://github.com/apache/maven-pmd-plugin/pull/11#discussion_r284819272
##
File path: src/main/java/org/apache/maven/plugins/pmd/PmdReport.java
##
@@ -769,7 +769,9 @@ private void configureTypeResolution( PMDConfiguration
configuration ) throws Ma
for ( String path : projectCompileClasspath )
{
File pathFile = new File( path );
-if ( !pathFile.exists() || pathFile.list().length
== 0 )
+String[] children = pathFile.list();
+
+if ( !pathFile.exists() || children == null ||
children.length == 0 )
Review comment:
@wcarmon I think, the logic should actually be
```suggestion
if ( !pathFile.exists() || ( children != null &&
children.length == 0 ) )
```
However, I'm wondering how a jar file can end up in this place. I expected
here something like the paths "project-a/target/classes" or
"project-a/target/generated-classes" or so.
You've mentioned, you get the null pointer when path is
`~/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.1/log4j-api-2.11.1.jar`.
Do you use log4j-api as a normal dependency or is there something special in
your project?
I've for now squashed and pushed your change to a new branch, let's see what
Jenkins says:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-pmd-plugin/job/MPMD-288/
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (MPMD-288) NullPointerException when File.list() returns null
[
https://issues.apache.org/jira/browse/MPMD-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-288:
Fix Version/s: 3.13.0
> NullPointerException when File.list() returns null
> --
>
> Key: MPMD-288
> URL: https://issues.apache.org/jira/browse/MPMD-288
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.12.0
>Reporter: Wil Carmon
>Priority: Minor
> Fix For: 3.13.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In
> [src/main/java/org/apache/maven/plugins/pmd/PmdReport.java|https://github.com/apache/maven-pmd-plugin/pull/11/files/6f7c735bc174d0f90bdb61f4f022de82c9ebcce6#diff-66e7aabcb9492d054a73cb75de5b728b]
>
> line 772 throws NullPointerException when {{File.list()}} returns {{null}}
> [See related
> javadoc|https://docs.oracle.com/javase/8/docs/api/java/io/File.html#list--]
> For me this occurs on jar files like
> {{~/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.1/log4j-api-2.11.1.jar}}
>
>
> See my proposed fix here: [https://github.com/apache/maven-pmd-plugin/pull/11]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841362#comment-16841362 ] Jonathan Bell commented on SUREFIRE-1584: - Thanks - that sounds good. I would be happy to discuss more - maybe my student and I can help with the changes for communication between Maven and the Surefire booker too. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Priority: Major > Labels: junit5 > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1667) Crash with JPMS "requires static"
Simone Bordet created SUREFIRE-1667:
---
Summary: Crash with JPMS "requires static"
Key: SUREFIRE-1667
URL: https://issues.apache.org/jira/browse/SUREFIRE-1667
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.0.0-M3
Reporter: Simone Bordet
Attachments: surefire-jpms-issue.tgz
The attached project has JPMS modules where:
{{moduleA}} requires {{moduleB}}
{{moduleB}} requires static {{moduleC}}.
Furthermore, {{moduleA}} tests require {{moduleC}}.
Running the attached project ends up with the following test failure:
{code}
[ERROR] test(org.cometd.a.ATest) Time elapsed: 0.01 s <<< ERROR!
java.lang.NoClassDefFoundError: org/cometd/c/C
at moduleA@1.0.0-SNAPSHOT/org.cometd.a.ATest.test(ATest.java:15)
{code}
The reason is that {{plexus-java}} creates a wrong module-path and class-path
because it does not take into account the {{static}} modified in the JPMS
directive {{requires static }}.
For the attached project, running {{moduleA}} tests generates this (simplified):
{code}
--module-path
moduleA/target/classes:
moduleB-1.0.0-SNAPSHOT.jar:
moduleC-1.0.0-SNAPSHOT.jar
--class-path
surefire-booter-3.0.0-M3.jar:
surefire-api-3.0.0-M3.jar:
surefire-logger-api-3.0.0-M3.jar:
junit-4.12.jar:
hamcrest-core-1.3.jar:
surefire-junit4-3.0.0-M3.jar:
common-java5-3.0.0-M3.jar:
common-junit3-3.0.0-M3.jar:
common-junit4-3.0.0-M3.jar"
--patch-module
moduleA=moduleA/target/test-classes
--add-exports
moduleA/org.cometd.a=ALL-UNNAMED
--add-modules
moduleA
--add-reads
moduleA=ALL-UNNAMED
{code}
However, {{moduleC}} should be in the class-path, not in the module-path, as it
is only required for testing.
It is in the module-path because it is pulled in as a transitive dependency
from {{moduleB}}, without taking into account that it is a {{requires static}}.
Correct behavior should be IMHO that {{moduleC}} is not in the module-path but
rather in the class-path, respecting the semantic of JPMS {{requires static}}.
The workaround is to configure the Maven Surefire Plugin with {{--add-module
moduleC}}, but that is incorrect.
The relevant {{plexus-languages/plexus-java}} code that builds the module-path
and the class-path is in {{LocationManager.resolvePaths()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841353#comment-16841353 ] Tibor Digana commented on SUREFIRE-1584: [~jonbell] One option would be to support us. You can become our contributor and later a committer in Maven ASF. I can explain our plan to you in the email and you will see where you can find your place. I think this is serious because we both want to have the same software result. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Priority: Major > Labels: junit5 > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841345#comment-16841345
]
Tibor Digana edited comment on SUREFIRE-1584 at 5/16/19 1:36 PM:
-
[~jonbell]
The development must go step by step.
Currently this is not possible what you want because this requires interprocess
communication on the level of sending commands. We are in a good progress. The
communication between Maven and Surefire booter process has two directions. One
was reworked and the second direction was not started to rework. I am afraid
that the {{StatelesXmlReporter}} is too stupid to safely support this feature
and should be reworked as well.
What can be done is to add rerun mechanism in the provider as we kow it today.
The version 3.0.0-M4 is promissing and I hope it will be included in Maven
3.7.0.
This version should rework internal code so that the features would be useful
for users again, but without this change it won't be possible.
was (Author: tibor17):
[~jonbell]
The development must go step by step.
Currently this is not possible what you want because this requires interprocess
communication on the level of sending commands. We are in a good progress. The
communication between Maven and Surefire booter process has two directions. One
was reworked and the second direction was not started to rework. I am afraid
that the {{StatelesXmlReporter}} is too stupid to safely support this feature
and should be reworked as well.
What can be done is to add rerun mechanism in the provider as we kow today.
The version 3.0.0-M4 is promissing and I hope it will be included in Maven
3.7.0.
This version should rework internal code so that the features would be useful
for users again, but without this change it won't be possible.
> Rerun Failing Tests with JUnit 5
>
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Priority: Major
> Labels: junit5
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
> is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841345#comment-16841345
]
Tibor Digana edited comment on SUREFIRE-1584 at 5/16/19 1:33 PM:
-
[~jonbell]
The development must go step by step.
Currently this is not possible what you want because this requires interprocess
communication on the level of sending commands. We are in a good progress. The
communication between Maven and Surefire booter process has two directions. One
was reworked and the second direction was not started to rework. I am afraid
that the {{StatelesXmlReporter}} is too stupid to safely support this feature
and should be reworked as well.
What can be done is to add rerun mechanism in the provider as we kow today.
The version 3.0.0-M4 is promissing and I hope it will be included in Maven
3.7.0.
This version should rework internal code so that the features would be useful
for users again, but without this change it won't be possible.
was (Author: tibor17):
[~jonbell]
The development must go step by step.
Currently this is not possible what you want because this requires interprocess
communication on the level of sending commands. We are in a good progress. The
communication between Maven and Surefire booter process has two directions. One
was reworks and the second direction was not started to rework. I am afraid
that the {{StatelesXmlReporter}} is too stupid to safely support this feature
and should be reworked as well.
What can be done is to add rerun mechanism in the provider as we kow today.
The version 3.0.0-M4 is promissing and I hope it will be included in Maven
3.7.0.
This version should rework internal code so that the features would be useful
for users again, but without this change it won't be possible.
> Rerun Failing Tests with JUnit 5
>
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Priority: Major
> Labels: junit5
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
> is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841345#comment-16841345
]
Tibor Digana commented on SUREFIRE-1584:
[~jonbell]
The development must go step by step.
Currently this is not possible what you want because this requires interprocess
communication on the level of sending commands. We are in a good progress. The
communication between Maven and Surefire booter process has two directions. One
was reworks and the second direction was not started to rework. I am afraid
that the {{StatelesXmlReporter}} is too stupid to safely support this feature
and should be reworked as well.
What can be done is to add rerun mechanism in the provider as we kow today.
The version 3.0.0-M4 is promissing and I hope it will be included in Maven
3.7.0.
This version should rework internal code so that the features would be useful
for users again, but without this change it won't be possible.
> Rerun Failing Tests with JUnit 5
>
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Priority: Major
> Labels: junit5
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
> is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841327#comment-16841327 ] Jonathan Bell commented on SUREFIRE-1584: - We are quite familiar with the existing rerun option (which reruns failing test methods in the same JVM that they had failed in). We have already implemented the rerun version that I've described above (where failing test methods are rerun in a _new_ JVM), and found it to be much more effective than the way that Surefire reruns tests right now ([details and graph here|https://www.deflaker.org/case-studies/]. Here is a graph showing the number of tests that originally failed, but eventually passed when rerun, comparing between Surefire's current rerun mechanism (rerunning failed tests in the same JVM) and our approach (rerunning failed tests in a new JVM). !FlakyReruns.png! We would like to standardize the rerun options to behave the same between all of the JUnit providers (so that users don't get confused by features that behave differently for JUnit4/JUnit47/Junit5). So, we would like to implement either a single rerun failing tests feature that reruns tests in a new JVM (modifying the existing feature from Qingzhou and Andreas), or add a new option (to all of the JUnit providers) to rerun failing tests in a new JVM. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Priority: Major > Labels: junit5 > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Bell updated SUREFIRE-1584: Attachment: FlakyReruns.png > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Priority: Major > Labels: junit5 > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841315#comment-16841315
]
Tibor Digana commented on SUREFIRE-1584:
[~jonbell]
Do you want to rerun each test class or entire testset?
IMO the {{JUnitPlatformProvider}} can make rerun of testset (this means at the
end of particular JVM).
Rerun already exists. It has its own configuration:
https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html
It was committed by qingzhouluo and Andreas Gudian in 2014.
Introducing a duplicate rerun configuration would be a big chaos for all users.
It cannot be two rerun counts and both valid. Can you imaging what
misunderstanding would be in user's world. Which one is valid and when.
> Rerun Failing Tests with JUnit 5
>
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Priority: Major
> Labels: junit5
>
> The very useful feature for integration tests ¨[Rerun Failing
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
> is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841270#comment-16841270 ] Jonathan Bell commented on SUREFIRE-1584: - Great! If it's OK with you, we would like to make a single PR (with tests) that: # Adds reruns for JUnit5 # Standardizes reruns for all of the JUnit runners so that the reruns occur in a new JVM at the end of test execution (as Lamyaa proposed in [PR 102|https://github.com/apache/maven-surefire/pull/102]). We did a case study and found that the existing rerun mechanism in Surefire (which reruns tests in the same JVM that they failed in) only found about 25% of the flaky tests that were found by instead rerunning tests in a new JVM - [details on that evaluation are here|https://www.deflaker.org/case-studies/]. # Adds timing information for reruns to the XML reports (also as Lamyaa proposed in [PR 96|https://github.com/apache/maven-surefire/pull/96]) Or, if you would prefer, we can do each of these changes as separate PRs (reviving the existing PR's 102 and 96; I can discuss and coordinate with Lamyaa also - we have worked together in the past). If you have any other suggestions for easy features to implement to simplify/standardize the rerun mechanism in Surefire, please let us know, we would be happy to contribute more. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Priority: Major > Labels: junit5 > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841156#comment-16841156 ] Hudson commented on MNG-6573: - Build unstable in Jenkins: Maven TLP » maven-shade-plugin » MSHADE-306 #5 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/MSHADE-306/5/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-810) Support Java 12
[ https://issues.apache.org/jira/browse/MSHARED-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841074#comment-16841074 ] Karl Heinz Marbaise commented on MSHARED-810: - [~slachiewicz] Created a new release maven-dependency-analyzer-3.0.1 ? > Support Java 12 > --- > > Key: MSHARED-810 > URL: https://issues.apache.org/jira/browse/MSHARED-810 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Rune Flobakk >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: Java12 > Fix For: maven-dependency-analyzer-3.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > ASM 7.1 supports Java 12 (and supposedly Java 13): > [https://asm.ow2.io/versions.html] > I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on > a Java 12 project, and it works fine with only the dependency update. > [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] > I am happy to make a pull request for it! > (or if you prefer to just make the simple change yourself, that's would of > course also be great. Just wanted to let you know of the simple change to > make it compatible with Java 12) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
