[jira] [Closed] (SUREFIRE-1721) fixed typo in JavaDoc for Failsafe: mvn test -Dsurefire.enableProcessChecker=all

2019-11-17 Thread Tibor Digana (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1721.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=f673d2422105d4f2f3b60ae70e107c56c022ceff

> fixed typo in JavaDoc for Failsafe: mvn test 
> -Dsurefire.enableProcessChecker=all
> 
>
> Key: SUREFIRE-1721
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1721
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.0.0-M4
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
>
> should be {{mvn test -Dfailsafe.enableProcessChecker=all}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SUREFIRE-1721) fixed typo in JavaDoc for Failsafe: mvn test -Dsurefire.enableProcessChecker=all

2019-11-17 Thread Tibor Digana (Jira)
Tibor Digana created SUREFIRE-1721:
--

 Summary: fixed typo in JavaDoc for Failsafe: mvn test 
-Dsurefire.enableProcessChecker=all
 Key: SUREFIRE-1721
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1721
 Project: Maven Surefire
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.0.0-M4
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M5


should be {{mvn test -Dfailsafe.enableProcessChecker=all}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SUREFIRE-1720) JUnit 5 @Nested classes are not excluded when name ends in Tests

2019-11-17 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976198#comment-16976198
 ] 

Tibor Digana commented on SUREFIRE-1720:


Unfortunately you was not faster. Reporting it 10 days ago would make the fix 
released.
This has nothing to do with JUnit5. It is generic approach to filter physical 
files (*.class) but the nested classes are different.
We already have default exclusions and we have to find out why this does not 
have any effect in your cases:

{code:java}
private String getDefaultExcludes()
{
return "**/*$*";
}
{code}


> JUnit 5 @Nested classes are not excluded when name ends in Tests
> 
>
> Key: SUREFIRE-1720
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1720
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Dmitry Timofeev
>Priority: Minor
>
> {color:#808080}`` {color}over source file names does not exclude the 
> {color:#808080}`@Nested` {color}test classes, defined inside the matching 
> source files, if they end with {color:#808080}`Tests`{color}.
> h3. Minimal reproducing project
> [https://github.com/dmitry-timofeev/surefire-bug] (contains the instrutctions 
> to run)
> See AppIntegrationTest.
> h3. Surefire Configuration
> {code:java}
> 
>   maven-surefire-plugin
>   ${surefire.version}
>   
> 
>   
>   **/*IntegrationTest.java
> 
> 
> 
>   
> 
> {code}
> h3. {color:#9876aa}Expected Behaviour{color}
> When a pattern over source file names is used 
> ({color:#808080}`*Pattern.java`{color}),
>  it must apply to all classes inside that file (including @Nested with any 
> name).
> h3. {color:#9876aa}Actual Behaviour{color}
> The exclusion does not apply to some @Nested classes inside the matching 
> source file (e.g, ending with {color:#808080}`Tests`{color}).
> h3. Workaround
> Also add a pattern, operating on _classes:_ 
> {{%regex[.*IntegrationTest\$.*]}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976188#comment-16976188
 ] 

Hudson commented on MNG-6759:
-

Build succeeded in Jenkins: Maven TLP » maven » master #306

See https://builds.apache.org/job/maven-box/job/maven/job/master/306/

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-11-17 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976182#comment-16976182
 ] 

Tibor Digana commented on SUREFIRE-1546:


Yesterday (November 17, 2019) we released the version 
[3.0.0-M4|https://maven.apache.org/surefire/index.html] of Surefire and 
Failsafe. The [displayname have to be 
selected|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#Surefire_Extensions_and_Reports_Configuration_for_.40DisplayName]
 and the default behavior is backwards compatible.
We support display name.
We support re-run of normal and parameterized tests as well.
See [the 
matrix|https://maven.apache.org/surefire/maven-surefire-plugin/featurematrix.html]
 of supported or not supported features.
Currently, we do not support reports with parallel tests due to the reporters, 
e.g. {{StatelessXmlReporter}}, whcih are not fully event based. These event 
based reporters will be reworked in future versions. This will open the door to 
support even more features than listed in the above matrix.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Jira


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976177#comment-16976177
 ] 

Stig Rohde Døssing commented on MNG-6759:
-

Thanks

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Robert Scholte (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976176#comment-16976176
 ] 

Robert Scholte commented on MNG-6759:
-

Seems like I should have merged my local branch instead of github. Should now 
be fixed.

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Jira


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976172#comment-16976172
 ] 

Stig Rohde Døssing commented on MNG-6759:
-

[~rfscholte] I made a mistake, had a oneliner change that wasn't committed. The 
module name at 
https://github.com/apache/maven-integration-testing/blob/9e98d89a8ad1a00fd17b176216e5c65a35bca8f8/core-it-support/core-it-plugins/pom.xml#L86
 is wrong, it should be "mng6759-resolves-project-dependencies-plugin", not 
"mng-6759-resolves-project-dependencies-plugin".

Could you apply the fix, or should I open a new PR?

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
>     URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976162#comment-16976162
 ] 

Hudson commented on MNG-6759:
-

Build failed in Jenkins: Maven TLP » maven » master #305

See https://builds.apache.org/job/maven-box/job/maven/job/master/305/

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-11-17 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MNG-6759.
---
Resolution: Fixed

Fixed in 
[c82409a2d843427ceceb9a42b0a4dc46cc4637bd|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=c82409a2d843427ceceb9a42b0a4dc46cc4637bd]
 and 
[9e98d89a8ad1a00fd17b176216e5c65a35bca8f8|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=9e98d89a8ad1a00fd17b176216e5c65a35bca8f8]
Thanks for the patch!

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (MDEP-663) Analyze failed: Unsupported class file major version 57 (Java 13)

2019-11-17 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MDEP-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte reassigned MDEP-663:
---

Assignee: Robert Scholte

> Analyze failed: Unsupported class file major version 57 (Java 13)
> -
>
> Key: MDEP-663
> URL: https://issues.apache.org/jira/browse/MDEP-663
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Reporter: Sudhesh RAJAN SHARMA
>Assignee: Robert Scholte
>Priority: Major
> Attachments: StackTrace.txt
>
>
> Class file of major version 57 (Java 13) is not yet supported by Maven 
> Dependency Plugin.
> {{While executing goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:analyze-only}} on 
> classes created by Java 13 build failed. Refer to the attached log 
> ([^StackTrace.txt]).
>  
> Java: OpenJDK 13 
> asm version: 7.2



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-648) list-repositories should point to the file that repository is specified in

2019-11-17 Thread Pim Moerenhout (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976132#comment-16976132
 ] 

Pim Moerenhout commented on MDEP-648:
-

Created issue https://issues.apache.org/jira/browse/MSHARED-843 to implement a 
dependency visitor, to collect the repositories and artifacts.

> list-repositories should point to the file that repository is specified in
> --
>
> Key: MDEP-648
> URL: https://issues.apache.org/jira/browse/MDEP-648
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>  Components: resolve
>Affects Versions: 3.1.1
>Reporter: Evgeny Bovykin
>Priority: Major
>
> When I run mvn dependency:list-repositories I'd like to see in which file 
> each repository is specified.
> My use case: I'd like to change all repositories from using http to using 
> https for security reasons. When repository is specified in my pom.xml it's 
> pretty easy to find and fix. But if it's specified in some plugin I'm using I 
> have to go on full adventure trying to find it.
> It would be much easier if list-repositories just printed "Repository 
> [http://...|http://.../] at plugin maven-some-plugin" or "Repository 
> [http://...|http://.../] at some/pom.xml"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MSHARED-843) Provide artifacts in CollectorResult when collectDependencies

2019-11-17 Thread Pim Moerenhout (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976131#comment-16976131
 ] 

Pim Moerenhout commented on MSHARED-843:


I did some refactoring after reading your comments.

> Provide artifacts in CollectorResult when collectDependencies 
> --
>
> Key: MSHARED-843
> URL: https://issues.apache.org/jira/browse/MSHARED-843
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-artifact-transfer
>Reporter: Pim Moerenhout
>Priority: Minor
>
> To resolve MDEP-648, to list all repositories and the POM's where these 
> repositories are defined, the collectDependencies in DependencyCollector 
> should also return the found artifact without resolving them.
> The CollectorResult could define the interface:
> List getArtifacts()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976116#comment-16976116
 ] 

Enrico Olivelli commented on MNG-6771:
--

Thank you [~hboutemy]

 

I have pushed the change about ASM and squashed all of the commits.

I have cited you as co-author (not sure about the best way to do it)

 

I feel we are on our way and we can merge the patch if you second it

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-345) Upgrade maven-resolver to 1.4.1

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976108#comment-16976108
 ] 

Hudson commented on MENFORCER-345:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #98

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/98/

> Upgrade maven-resolver to 1.4.1
> ---
>
> Key: MENFORCER-345
> URL: https://issues.apache.org/jira/browse/MENFORCER-345
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-345) Upgrade maven-resolver to 1.4.1

2019-11-17 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976101#comment-16976101
 ] 

Karl Heinz Marbaise commented on MENFORCER-345:
---

Done in 
[75d30f55a176eacb4d4336d2c62ecf2b9960bd36|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=75d30f55a176eacb4d4336d2c62ecf2b9960bd36]

> Upgrade maven-resolver to 1.4.1
> ---
>
> Key: MENFORCER-345
> URL: https://issues.apache.org/jira/browse/MENFORCER-345
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-345) Upgrade maven-resolver to 1.4.1

2019-11-17 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-345.
-
Resolution: Done

> Upgrade maven-resolver to 1.4.1
> ---
>
> Key: MENFORCER-345
> URL: https://issues.apache.org/jira/browse/MENFORCER-345
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Herve Boutemy (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976096#comment-16976096
 ] 

Herve Boutemy commented on MNG-6771:


sisu.injact is mentioning ASM: look at about.html in the jar and you'll see
it's just not in META-INF/NOTICE but in a location that seems adapted to 
Eclipse plugins

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976092#comment-16976092
 ] 

Enrico Olivelli commented on MNG-6771:
--

[~hboutemy]

I have pushed the NOTICE.vm file, please take a look.
*Regarding ASM, I am not sure we should mention it.*
*It comes from a third party jar that is not mentioning it.*
*It is not our fault, we can notify upstream to Eclipse*

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976060#comment-16976060
 ] 

Enrico Olivelli commented on MNG-6771:
--

[~hboutemy] this is the final content we have to attach as a NOTICE file for 
the binary distribution:
{noformat}
Apache Maven Distribution
Copyright 2001-2019 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
 
This software bundles the following NOTICE file from third party library 
providers:
META-INF/NOTICE in archive lib/guice-4.2.1-no_aop.jar
Google Guice - Core Library
Copyright 2006-2018 Google, Inc.
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
META-INF/NOTICE in archive  lib/plexus-utils-3.2.1.jar
This product includes software developed by the Indiana University 
 Extreme! Lab (http://www.extreme.indiana.edu/).
This product includes software developed by 
The Apache Software Foundation (http://www.apache.org/).
This product includes software developed by 
ThoughtWorks (http://www.thoughtworks.com).
This product includes software developed by 
javolution (http://javolution.org/).
This product includes software developed by 
Rome (https://rome.dev.java.net/). {noformat}
 

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976059#comment-16976059
 ] 

Enrico Olivelli commented on MNG-6771:
--

Using this command line it happens that we have some important stuff to copy to 
our NOTICE file from the jars in "lib"

 
{code:java}
for i in lib/*.jar boot/*.jar; do unzip -c $i META-INF/NOTICE; done{code}
{noformat}
 Archive:  lib/cdi-api-1.0.jar
Archive:  lib/commons-cli-1.4.jar
Archive:  lib/commons-io-2.5.jar
Archive:  lib/commons-lang3-3.8.1.jar
Archive:  lib/guava-25.1-android.jar
Archive:  lib/guice-4.2.1-no_aop.jar
  inflating: META-INF/NOTICE Google Guice - Core Library
Copyright 2006-2018 Google, Inc.This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/jansi-1.17.1.jar
Archive:  lib/javax.inject-1.jar
Archive:  lib/jcl-over-slf4j-1.7.29.jar
Archive:  lib/jsoup-1.12.1.jar
Archive:  lib/jsr250-api-1.0.jar
Archive:  lib/maven-artifact-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Artifact
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-builder-support-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Builder Support
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-compat-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Compat
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-core-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Core
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-embedder-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Embedder
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-model-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Model
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-model-builder-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Model Builder
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-plugin-api-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Plugin API
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-repository-metadata-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Repository Metadata Model
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-api-1.4.1.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver API
Copyright 2010-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-connector-basic-1.4.1.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver Connector Basic
Copyright 2010-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-impl-1.4.1.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver Implementation
Copyright 2010-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-provider-3.6.3-SNAPSHOT.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver Provider
Copyright 2001-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-spi-1.4.1.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver SPI
Copyright 2010-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  
lib/maven-resolver-transport-wagon-1.4.1.jar
  inflating: META-INF/NOTICE Maven Artifact Resolver Transport Wagon
Copyright 2010-2019 The Apache Software FoundationThis product includes 
software developed at
The Apache Software Foundation (http://www.apache.org/).Archive:  

[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976058#comment-16976058
 ] 

Enrico Olivelli commented on MNG-6771:
--

* Jsoup is ok now: [https://github.com/jhy/jsoup/blob/master/LICENSE 
|https://github.com/jhy/jsoup/blob/master/LICENSE]as we are copying the license 
file
 * JSR250API seems ok ( and quite dead)  it is CCDL 
[https://repo1.maven.org/maven2/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.pom]
 * SLF4j is okay [https://github.com/qos-ch/slf4j/blob/master/LICENSE.txt] as 
we are copying the license file
 * Eclipse SiSU and Eclipse Plexus are OK, they are EPL and do not require 
entries in NOTICE, we are budling the license files in lib

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-17 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976050#comment-16976050
 ] 

Enrico Olivelli commented on MNG-6771:
--

We just have to write the NOTICE file, I am working on it right now, I hope to 
be done this evening(can't work continuously...sorry)

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-344) Upgrade commons-lang3 to 3.8.1

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976034#comment-16976034
 ] 

Hudson commented on MENFORCER-344:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #97

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/97/

> Upgrade commons-lang3 to 3.8.1
> --
>
> Key: MENFORCER-344
> URL: https://issues.apache.org/jira/browse/MENFORCER-344
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-344) Upgrade commons-lang3 to 3.8.1

2019-11-17 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976029#comment-16976029
 ] 

Karl Heinz Marbaise commented on MENFORCER-344:
---

Done in 
[fc825f2f5b26806302f50b22a6752ef9fc310285|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=fc825f2f5b26806302f50b22a6752ef9fc310285]

> Upgrade commons-lang3 to 3.8.1
> --
>
> Key: MENFORCER-344
> URL: https://issues.apache.org/jira/browse/MENFORCER-344
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-344) Upgrade commons-lang3 to 3.8.1

2019-11-17 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-344.
-
Resolution: Done

> Upgrade commons-lang3 to 3.8.1
> --
>
> Key: MENFORCER-344
> URL: https://issues.apache.org/jira/browse/MENFORCER-344
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-343) Upgrade maven-commons-artifact-filters to 3.1.0

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976028#comment-16976028
 ] 

Hudson commented on MENFORCER-343:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #96

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/96/

> Upgrade maven-commons-artifact-filters to 3.1.0
> ---
>
> Key: MENFORCER-343
> URL: https://issues.apache.org/jira/browse/MENFORCER-343
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-343) Upgrade maven-commons-artifact-filters to 3.1.0

2019-11-17 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976024#comment-16976024
 ] 

Karl Heinz Marbaise commented on MENFORCER-343:
---

Done in 
[49c6a4191240a888d50706e7598327741279fe35|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=49c6a4191240a888d50706e7598327741279fe35]

> Upgrade maven-commons-artifact-filters to 3.1.0
> ---
>
> Key: MENFORCER-343
> URL: https://issues.apache.org/jira/browse/MENFORCER-343
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-343) Upgrade maven-commons-artifact-filters to 3.1.0

2019-11-17 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-343.
-
Resolution: Done

> Upgrade maven-commons-artifact-filters to 3.1.0
> ---
>
> Key: MENFORCER-343
> URL: https://issues.apache.org/jira/browse/MENFORCER-343
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-342) Upgrade commons-codec to 1.12

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975976#comment-16975976
 ] 

Hudson commented on MENFORCER-342:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #95

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/95/

> Upgrade commons-codec to 1.12
> -
>
> Key: MENFORCER-342
> URL: https://issues.apache.org/jira/browse/MENFORCER-342
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-342) Upgrade commons-codec to 1.12

2019-11-17 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-342.
-
Resolution: Done

> Upgrade commons-codec to 1.12
> -
>
> Key: MENFORCER-342
> URL: https://issues.apache.org/jira/browse/MENFORCER-342
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-342) Upgrade commons-codec to 1.12

2019-11-17 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975974#comment-16975974
 ] 

Karl Heinz Marbaise commented on MENFORCER-342:
---

Done in 
[36840e2081eabe774351b33c2cb6141b5ed2c22c|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=36840e2081eabe774351b33c2cb6141b5ed2c22c]

> Upgrade commons-codec to 1.12
> -
>
> Key: MENFORCER-342
> URL: https://issues.apache.org/jira/browse/MENFORCER-342
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-341) Upgrade mockito-corre to 2.28.2

2019-11-17 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975956#comment-16975956
 ] 

Hudson commented on MENFORCER-341:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #94

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/94/

> Upgrade mockito-corre to 2.28.2
> ---
>
> Key: MENFORCER-341
> URL: https://issues.apache.org/jira/browse/MENFORCER-341
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-341) Upgrade mockito-corre to 2.28.2

2019-11-17 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975954#comment-16975954
 ] 

Karl Heinz Marbaise commented on MENFORCER-341:
---

Done in 
[f2cf2ce4cf99348b62c20524a185c60e4aff34de|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=f2cf2ce4cf99348b62c20524a185c60e4aff34de]

> Upgrade mockito-corre to 2.28.2
> ---
>
> Key: MENFORCER-341
> URL: https://issues.apache.org/jira/browse/MENFORCER-341
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-341) Upgrade mockito-corre to 2.28.2

2019-11-17 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-341.
-
Resolution: Done

> Upgrade mockito-corre to 2.28.2
> ---
>
> Key: MENFORCER-341
> URL: https://issues.apache.org/jira/browse/MENFORCER-341
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-16 Thread Herve Boutemy (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975833#comment-16975833
 ] 

Herve Boutemy commented on MNG-6771:


[~eolivelli]I just continued our work on MNG-6771 branch, and rewrote history a 
little bit
it seems to me we have now a consistent state that could be ok to fix our 
issues: WDYT?

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-568) dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx

2019-11-16 Thread Christopher Smith (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975824#comment-16975824
 ] 

Christopher Smith commented on MDEP-568:


+1 for this overt, plugin-breaking bug that's been open for more than 2.5 years.

> dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts 
> in the excluded group 
> --
>
> Key: MDEP-568
> URL: https://issues.apache.org/jira/browse/MDEP-568
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline, resolve
>Affects Versions: 2.3, 3.0.0
> Environment: windows / cygwin xp64 bit / bash / maven 3.0.3
>Reporter: Archimedes Trajano
>Priority: Major
> Attachments: MDEP-568-maven-dependency-plugin.patch, 
> go-offline_copy-dependencies_patch_sample.zip, test.tgz
>
>
> see thread: 
> http://mail-archives.apache.org/mod_mbox/maven-users/201109.mbox/%3c0B02C46601D44673A4A2DF4C4F907E9E@black%3e
> in attached sample pom structure:
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:go-offline 
> -DexcludeGroupIds=us.pdinc.foo.maven.test
> fails



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975822#comment-16975822
 ] 

Hudson commented on MNG-6771:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #8

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/8/

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975819#comment-16975819
 ] 

Hudson commented on MNG-6584:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #7

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/7/

> Maven version 3.6.0 does not show ReasonPhrase anymore
> --
>
> Key: MNG-6584
> URL: https://issues.apache.org/jira/browse/MNG-6584
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Lucas Ludueño
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.3
>
>
> Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for 
> example when you run mvn deploy to a custom Maven service).
> With version 3.5.0 the ReasonPhrase is shown in a message like:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
> project mule-module-tooling-service: Failed to deploy artifacts: Could not 
> transfer artifact 
> 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3
>  from/to exchange-repository 
> (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to 
> transfer file: 
> http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar.
>  Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1]
> I am not completely sure if the ReasonPhrase has been removed intentionally. 
> If the answer is no, can you fix it? If the answer is yes, how can I simulate 
> the behavior to indicate to someone what was happening?
>  
> Thanks!!
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975818#comment-16975818
 ] 

Hudson commented on MNG-6771:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #7

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/7/

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-340) Upgrade plexus-utils 3.3.0

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975767#comment-16975767
 ] 

Hudson commented on MENFORCER-340:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #93

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/93/

> Upgrade plexus-utils 3.3.0
> --
>
> Key: MENFORCER-340
> URL: https://issues.apache.org/jira/browse/MENFORCER-340
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-340) Upgrade plexus-utils 3.3.0

2019-11-16 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-340.
-
Resolution: Done

> Upgrade plexus-utils 3.3.0
> --
>
> Key: MENFORCER-340
> URL: https://issues.apache.org/jira/browse/MENFORCER-340
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-340) Upgrade plexus-utils 3.3.0

2019-11-16 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975765#comment-16975765
 ] 

Karl Heinz Marbaise commented on MENFORCER-340:
---

Done in 
[3cd158a1dfa00efe49535189b7f94c9233de61f7|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=3cd158a1dfa00efe49535189b7f94c9233de61f7]

> Upgrade plexus-utils 3.3.0
> --
>
> Key: MENFORCER-340
> URL: https://issues.apache.org/jira/browse/MENFORCER-340
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-345) Upgrade maven-resolver to 1.4.1

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-345:
-

 Summary: Upgrade maven-resolver to 1.4.1
 Key: MENFORCER-345
 URL: https://issues.apache.org/jira/browse/MENFORCER-345
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-339) Upgrade extra-enforcer-rules to 1.2.

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975763#comment-16975763
 ] 

Hudson commented on MENFORCER-339:
--

Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #92

See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/92/

> Upgrade extra-enforcer-rules to 1.2.
> 
>
> Key: MENFORCER-339
> URL: https://issues.apache.org/jira/browse/MENFORCER-339
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-344) Upgrade commons-lang3 to 3.8.1

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-344:
-

 Summary: Upgrade commons-lang3 to 3.8.1
 Key: MENFORCER-344
 URL: https://issues.apache.org/jira/browse/MENFORCER-344
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-343) Upgrade maven-commons-artifact-filters to 3.1.0

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-343:
-

 Summary: Upgrade maven-commons-artifact-filters to 3.1.0
 Key: MENFORCER-343
 URL: https://issues.apache.org/jira/browse/MENFORCER-343
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-342) Upgrade commons-codec to 1.12

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-342:
-

 Summary: Upgrade commons-codec to 1.12
 Key: MENFORCER-342
 URL: https://issues.apache.org/jira/browse/MENFORCER-342
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MENFORCER-339) Upgrade extra-enforcer-rules to 1.2.

2019-11-16 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MENFORCER-339.
-
Resolution: Done

> Upgrade extra-enforcer-rules to 1.2.
> 
>
> Key: MENFORCER-339
> URL: https://issues.apache.org/jira/browse/MENFORCER-339
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MENFORCER-339) Upgrade extra-enforcer-rules to 1.2.

2019-11-16 Thread Karl Heinz Marbaise (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975760#comment-16975760
 ] 

Karl Heinz Marbaise commented on MENFORCER-339:
---

Done in 
[a70cb57613823a41c2269a6c8ba4641c9fbb47b9|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=a70cb57613823a41c2269a6c8ba4641c9fbb47b9]

> Upgrade extra-enforcer-rules to 1.2.
> 
>
> Key: MENFORCER-339
> URL: https://issues.apache.org/jira/browse/MENFORCER-339
> Project: Maven Enforcer Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-341) Upgrade mockito-corre to 2.28.2

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-341:
-

 Summary: Upgrade mockito-corre to 2.28.2
 Key: MENFORCER-341
 URL: https://issues.apache.org/jira/browse/MENFORCER-341
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-340) Upgrade plexus-utils 3.3.0

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-340:
-

 Summary: Upgrade plexus-utils 3.3.0
 Key: MENFORCER-340
 URL: https://issues.apache.org/jira/browse/MENFORCER-340
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MENFORCER-339) Upgrade extra-enforcer-rules to 1.2.

2019-11-16 Thread Karl Heinz Marbaise (Jira)
Karl Heinz Marbaise created MENFORCER-339:
-

 Summary: Upgrade extra-enforcer-rules to 1.2.
 Key: MENFORCER-339
 URL: https://issues.apache.org/jira/browse/MENFORCER-339
 Project: Maven Enforcer Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0-M2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MEAR-277) Upgrade maven-invoker-plugin to 3.2.1

2019-11-16 Thread Karl Heinz Marbaise (Jira)


 [ 
https://issues.apache.org/jira/browse/MEAR-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MEAR-277:
-
Issue Type: Dependency upgrade  (was: Bug)

> Upgrade maven-invoker-plugin to 3.2.1
> -
>
> Key: MEAR-277
> URL: https://issues.apache.org/jira/browse/MEAR-277
> Project: Maven Ear Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEPLOY-262) Fail on HTTP-Statuscode 409 on Upload instead of warn

2019-11-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975736#comment-16975736
 ] 

Michael Osipov commented on MDEPLOY-262:


Can you provide more log? Debug log. Please also enable wire log on Apache 
HttpClient.

Why does Artifactory give you a conflict?

> Fail on HTTP-Statuscode 409 on Upload instead of warn
> -
>
> Key: MDEPLOY-262
> URL: https://issues.apache.org/jira/browse/MDEPLOY-262
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> Environment: Debian 10
> Maven 3.6.1
> Artifactory 6.13.1
>Reporter: Andreas Wirooks
>Priority: Major
>
> We have the situation that an upload fails with HTTP-Statuscode 409. Here the 
> maven-deploy-plugin should stop with an error. But it only warns and 
> continues. This results in missing files or in case of overwriting different 
> contents when overwriting did not succeed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MWAR-352) web.xml not being replaced by plugin configuration

2019-11-16 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MWAR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975710#comment-16975710
 ] 

Hudson commented on MWAR-352:
-

Build succeeded in Jenkins: Maven TLP » maven-war-plugin » master #86

See https://builds.apache.org/job/maven-box/job/maven-war-plugin/job/master/86/

> web.xml not being replaced by plugin configuration
> --
>
> Key: MWAR-352
> URL: https://issues.apache.org/jira/browse/MWAR-352
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 x64, Eclipse Luna, JSF 2 project
>Reporter: Alex Sebastiao Constancio
>Assignee: Robert Scholte
>Priority: Major
>  Labels: build
>
> My pom.xml file has the following in it:
> {code:xml}
>   
>   
>   
>   org.apache.maven.plugins
>   maven-war-plugin
>   2.6
>   
>   
> src/main/webconfig/release/web.xml
>   
>   
>   
>   
> {code}
> As you can see, the web.xml to be used by war plugin when running Maven 
> install is located outside of the webapp folder. This work perfectly if there 
> ins't a web.xml in webapp/WEB-INF folder, but the pluging refuses to use the 
> web.xml from webconfig/release if there is already a file with the same name 
> in webapp/WEB-INF.
> The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be 
> able publish the application to my local application server for debug. This 
> file has particular settings for a local environment.
> However, when I want to produce a war to publish in the production server, it 
> has to be another web.xml, the one located in webconfig/release folder. 
> Problem is that the war plugin does not replaces one file by the other when 
> generating the war file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MWAR-352) web.xml not being replaced by plugin configuration

2019-11-16 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MWAR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MWAR-352.
---
  Assignee: Robert Scholte
Resolution: Cannot Reproduce

Added an integration test at 
[ce5d96eecc5bd41015a0401b1cefc8a5ce261bf7|https://gitbox.apache.org/repos/asf?p=maven-war-plugin.git;a=commit;h=ce5d96eecc5bd41015a0401b1cefc8a5ce261bf7]
 to show that it does replace the web.xml

> web.xml not being replaced by plugin configuration
> --
>
> Key: MWAR-352
> URL: https://issues.apache.org/jira/browse/MWAR-352
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 x64, Eclipse Luna, JSF 2 project
>Reporter: Alex Sebastiao Constancio
>Assignee: Robert Scholte
>Priority: Major
>  Labels: build
>
> My pom.xml file has the following in it:
> {code:xml}
>   
>   
>   
>   org.apache.maven.plugins
>   maven-war-plugin
>   2.6
>   
>   
> src/main/webconfig/release/web.xml
>   
>   
>   
>   
> {code}
> As you can see, the web.xml to be used by war plugin when running Maven 
> install is located outside of the webapp folder. This work perfectly if there 
> ins't a web.xml in webapp/WEB-INF folder, but the pluging refuses to use the 
> web.xml from webconfig/release if there is already a file with the same name 
> in webapp/WEB-INF.
> The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be 
> able publish the application to my local application server for debug. This 
> file has particular settings for a local environment.
> However, when I want to produce a war to publish in the production server, it 
> has to be another web.xml, the one located in webconfig/release folder. 
> Problem is that the war plugin does not replaces one file by the other when 
> generating the war file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MWAR-352) web.xml not being replaced by plugin configuration

2019-11-16 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MWAR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MWAR-352:

Fix Version/s: (was: 2.6)

> web.xml not being replaced by plugin configuration
> --
>
> Key: MWAR-352
> URL: https://issues.apache.org/jira/browse/MWAR-352
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 x64, Eclipse Luna, JSF 2 project
>Reporter: Alex Sebastiao Constancio
>Priority: Major
>  Labels: build
>
> My pom.xml file has the following in it:
> {code:xml}
>   
>   
>   
>   org.apache.maven.plugins
>   maven-war-plugin
>   2.6
>   
>   
> src/main/webconfig/release/web.xml
>   
>   
>   
>   
> {code}
> As you can see, the web.xml to be used by war plugin when running Maven 
> install is located outside of the webapp folder. This work perfectly if there 
> ins't a web.xml in webapp/WEB-INF folder, but the pluging refuses to use the 
> web.xml from webconfig/release if there is already a file with the same name 
> in webapp/WEB-INF.
> The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be 
> able publish the application to my local application server for debug. This 
> file has particular settings for a local environment.
> However, when I want to produce a war to publish in the production server, it 
> has to be another web.xml, the one located in webconfig/release folder. 
> Problem is that the war plugin does not replaces one file by the other when 
> generating the war file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975676#comment-16975676
 ] 

Tibor Digana edited comment on SUREFIRE-1719 at 11/16/19 11:21 AM:
---

[~paulmillar]
Pls configure your CI system so that you will be able to handle build files 
from the file system in CI and observe the dump files located in 
{{target/surefire-reports}}. These streams use to be corrupted by native logs 
printed by JVM GC in the std/out and std/in. Try to make the GC quiet for to 
confirm this hypothesis. My suspicion is that GC corrupted the std/out stream 
and the BYE event was lost. This has happenedat the end after all tests 
completed and GC printed the messages at the time when the forked JVM sent BYE 
and the fork was waiting for next 30 seconds for the acknowledgement and killed 
itself if not arived.
We will introduce TCP connector instead of process pipes in 3.0.0-M5, see 
SUREFIRE-1658. Meanwhile i would like you to confirm this problem with 
corrupted stream which can be seen in the dump file produced by Surefire.


was (Author: tibor17):
[~paulmillar]
Pls configure your CI system so that you will be able to handle build files 
from the file system in CI and observe the dump files located in 
{{target/surefire-reports}}. These streams use to be corrupted by native logs 
printed by JVM GC in the std/out and std/in. Try to make the GC quite for to 
confirm this hypothesis. My suspicion is that GC corrupted the std/out stream 
and the BYE event was lost. This has happenedat the end after all tests 
completed and GC printed the messages at the time when the forked JVM sent BYE 
and the fork was waiting for next 30 seconds for the acknowledgement and killed 
itself if not arived.
We will introduce TCP connector instead of process pipes in 3.0.0-M5, see 
SUREFIRE-1658. Meanwhile i would like you to confirm this problem with 
corrupted stream which can be seen in the dump file produced by Surefire.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduc

[jira] [Comment Edited] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975676#comment-16975676
 ] 

Tibor Digana edited comment on SUREFIRE-1719 at 11/16/19 11:18 AM:
---

[~paulmillar]
Pls configure your CI system so that you will be able to handle build files 
from the file system in CI and observe the dump files located in 
{{target/surefire-reports}}. These streams use to be corrupted by native logs 
printed by JVM GC in the std/out and std/in. Try to make the GC quite for to 
confirm this hypothesis. My suspicion is that GC corrupted the std/out stream 
and the BYE event was lost. This has happenedat the end after all tests 
completed and GC printed the messages at the time when the forked JVM sent BYE 
and the fork was waiting for next 30 seconds for the acknowledgement and killed 
itself if not arived.
We will introduce TCP connector instead of process pipes in 3.0.0-M5, see 
SUREFIRE-1658. Meanwhile i would like you to confirm this problem with 
corrupted stream which can be seen in the dump file produced by Surefire.


was (Author: tibor17):
[~paulmillar]
Pls configure your CI system so that you will be able to handle build files 
from the file system in CI and observe the dump files located in 
{{target/surefire-reports}}. These streams use to be corrupted by native logs 
printed by JVM GC in the std/out and std/in. Try to make the GC quite for a 
try. My suspicion is that GC corrupted the std/out stream and the BYE event was 
lost. This has happenedat the end after all tests completed and GC printed the 
messages at the time when the forked JVM sent BYE and the fork was waiting for 
next 30 seconds for the acknowledgement and killed itself if not arived.
We will introduce TCP connector instead of process pipes in 3.0.0-M5. Meanwhile 
i would like you to confirm this problem with corrupted stream which can be 
seen in the dump file produced by Surefire.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> wi

[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975676#comment-16975676
 ] 

Tibor Digana commented on SUREFIRE-1719:


[~paulmillar]
Pls configure your CI system so that you will be able to handle build files 
from the file system in CI and observe the dump files located in 
{{target/surefire-reports}}. These streams use to be corrupted by native logs 
printed by JVM GC in the std/out and std/in. Try to make the GC quite for a 
try. My suspicion is that GC corrupted the std/out stream and the BYE event was 
lost. This has happenedat the end after all tests completed and GC printed the 
messages at the time when the forked JVM sent BYE and the fork was waiting for 
next 30 seconds for the acknowledgement and killed itself if not arived.
We will introduce TCP connector instead of process pipes in 3.0.0-M5. Meanwhile 
i would like you to confirm this problem with corrupted stream which can be 
seen in the dump file produced by Surefire.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> with surefire v2.19.1, the above mvn command is always successful on our 
> build machine.  Building with surefire v2.20 results in intermittent failures 
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10 
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342 
> Acknowledge normal exit of JVM and drain shared memory between processes" is 
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it 
> introduces is somehow racy (for example, reading or updating a field-member 
> outside of a monitor) and problems are triggered if there are a large number 
> of JVMs exiting concurrently.  So, with increased number of concurrent JVMs 
> there is an increased risk of a thread loosing the race, and so triggering 
> this error.
> Such a problem would be consistent with observed behaviour.  However, I don't 
> have any strong evidence that this is what is happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (MINSTALL-160) generatePom=true with 3.0.0-M1 does not generate minimal POM but copies existing one

2019-11-16 Thread Jira


[ 
https://issues.apache.org/jira/browse/MINSTALL-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975663#comment-16975663
 ] 

Václav Haisman edited comment on MINSTALL-160 at 11/16/19 10:39 AM:


I think it is the changes by Guillaume Boué in revision 
e6712f449b01d2ee979297853bb3ae7c0e3b08a9 ("MINSTALL-110 install-file should 
also install bundled pom.xml from artifact.") that broke it.


was (Author: wilx):
I think it is the changes by [~guilllomm] in revision 
e6712f449b01d2ee979297853bb3ae7c0e3b08a9 ("[MINSTALL-110] install-file should 
also install bundled pom.xml from artifact.") that broke it.

> generatePom=true with 3.0.0-M1 does not generate minimal POM but copies 
> existing one
> 
>
> Key: MINSTALL-160
>     URL: https://issues.apache.org/jira/browse/MINSTALL-160
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install-file
>Affects Versions: 3.0.0-M1
>Reporter: Václav Haisman
>Priority: Major
>
> I am using install:install-file with generatePom=true to install JAR with 
> minimal POM file. This has stopped working with 3.0.0-M1. With 3.0.0-M1, it 
> copeis existing project pom.xml instead of generating a minimal one.
>  
> This is easily reproducible with minimal project:
> {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
>   maven.install.plugin.issue
>   maven.install.plugin.issue
>   1.0-SNAPSHOT
>   jar
>   maven.install.plugin.issue
>   
> 1.6
> 1.6
>   
>   
> 
>   
> 
>   maven-install-plugin
>   
>   3.0.0-M1
>   
> 
>   
> 
> 
>   
> maven-install-plugin
> 
>   
> default-install
> none
> install
>   
>   
> custom-install
> install
> 
>   install-file
> 
> 
>   
> ${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
>   true
> 
>   
> 
>   
> 
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MINSTALL-160) generatePom=true with 3.0.0-M1 does not generate minimal POM but copies existing one

2019-11-16 Thread Jira


[ 
https://issues.apache.org/jira/browse/MINSTALL-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975663#comment-16975663
 ] 

Václav Haisman commented on MINSTALL-160:
-

I think it is the changes by [~guilllomm] in revision 
e6712f449b01d2ee979297853bb3ae7c0e3b08a9 ("[MINSTALL-110] install-file should 
also install bundled pom.xml from artifact.") that broke it.

> generatePom=true with 3.0.0-M1 does not generate minimal POM but copies 
> existing one
> 
>
> Key: MINSTALL-160
> URL: https://issues.apache.org/jira/browse/MINSTALL-160
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install-file
>Affects Versions: 3.0.0-M1
>Reporter: Václav Haisman
>Priority: Major
>
> I am using install:install-file with generatePom=true to install JAR with 
> minimal POM file. This has stopped working with 3.0.0-M1. With 3.0.0-M1, it 
> copeis existing project pom.xml instead of generating a minimal one.
>  
> This is easily reproducible with minimal project:
> {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
>   maven.install.plugin.issue
>   maven.install.plugin.issue
>   1.0-SNAPSHOT
>   jar
>   maven.install.plugin.issue
>   
> 1.6
> 1.6
>   
>   
> 
>   
> 
>   maven-install-plugin
>   
>   3.0.0-M1
>   
> 
>   
> 
> 
>   
> maven-install-plugin
> 
>   
> default-install
> none
> install
>   
>   
> custom-install
> install
> 
>   install-file
> 
> 
>   
> ${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
>   true
> 
>   
> 
>   
> 
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MSHARED-843) Provide artifacts in CollectorResult when collectDependencies

2019-11-16 Thread Pim Moerenhout (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975660#comment-16975660
 ] 

Pim Moerenhout commented on MSHARED-843:


Implemented the visit in the collector, which can handle the Maven 3.0 and 3.1 
aether implementations:
[https://github.com/pmoerenhout/maven-artifact-transfer/tree/MSHARED-843-TEST]

The dependency node in the visitor provides the artifact, children, 
repositories, optional and scope. Any more needed?

To see the action, use the 
[https://github.com/pmoerenhout/maven-dependency-plugin/tree/MDEP-648-TEST] 
branch with the goal list-repositories-2

> Provide artifacts in CollectorResult when collectDependencies 
> --
>
> Key: MSHARED-843
> URL: https://issues.apache.org/jira/browse/MSHARED-843
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-artifact-transfer
>Reporter: Pim Moerenhout
>Priority: Minor
>
> To resolve MDEP-648, to list all repositories and the POM's where these 
> repositories are defined, the collectDependencies in DependencyCollector 
> should also return the found artifact without resolving them.
> The CollectorResult could define the interface:
> List getArtifacts()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975659#comment-16975659
 ] 

Tibor Digana commented on SUREFIRE-1497:


[~scolebou...@joda.org]
Not sure if the users know that your requirement to switch on/off the modular 
classpath exists since of the version 3.0.0-M2.
See the configuraion parameter {{useModulePath}} in documentation. The default 
value for this parameter is {{true}}.
Pls se it to {{false}} if it has to solve your problem.

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>  Labels: jigsaw
> Attachments: maven-issue4.zip
>
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975652#comment-16975652
 ] 

Tibor Digana edited comment on SUREFIRE-1719 at 11/16/19 9:50 AM:
--

Thx for having a look into this issue.
I want to ask you to follow the test instruction from [current release 
vote|https://lists.apache.org/thread.html/6b9987be2fbd4d82daf8aaabbd1d58dfa2a533598770e0423d0b5ee0@%3Cdev.maven.apache.org%3E]
 and repeat the tests with the version 3.0.0-M4. Code changes have been made in 
those parts you described, {{ForkedBooter}} and {{CommandReader}}.
Regarding the fields, i checked the instance fields used by 
{{acknowledgedExit()}} in the {{ForkedBooter}}. I remember that i fixed a race 
in old version of the plugin one or two years ago, so i did not expect a new 
similar issue happening again. Pls see our code on 
[GitHub|https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java#L354]
 and feel free to come with some findings. We will definitely have a look.


was (Author: tibor17):
Thx for have a look into this issue.
I want to ask you to follow the test instruction from [current release 
vote|https://lists.apache.org/thread.html/6b9987be2fbd4d82daf8aaabbd1d58dfa2a533598770e0423d0b5ee0@%3Cdev.maven.apache.org%3E]
 and repeat the tests with the version 3.0.0-M4. Code changes have been made in 
those parts you described, ForkedBooter and CommandReader.
Regarding the fields, i checked the instance fields used by 
{{acknowledgedExit()}} in the {{ForkedBooter}}. I remember that i fixed a race 
in old version of the plugin one or two years ago, so i did not expect a new 
similar issue happening again. Pls see our code on GitHub and feel free to come 
with some findings. We will definitely have a look.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> with surefire v2.19.1, the above mvn command is always successful on our 
> build machine

[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

2019-11-16 Thread Tibor Digana (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975652#comment-16975652
 ] 

Tibor Digana commented on SUREFIRE-1719:


Thx for have a look into this issue.
I want to ask you to follow the test instruction from [current release 
vote|https://lists.apache.org/thread.html/6b9987be2fbd4d82daf8aaabbd1d58dfa2a533598770e0423d0b5ee0@%3Cdev.maven.apache.org%3E]
 and repeat the tests with the version 3.0.0-M4. Code changes have been made in 
those parts you described, ForkedBooter and CommandReader.
Regarding the fields, i checked the instance fields used by 
{{acknowledgedExit()}} in the {{ForkedBooter}}. I remember that i fixed a race 
in old version of the plugin one or two years ago, so i did not expect a new 
similar issue happening again. Pls see our code on GitHub and feel free to come 
with some findings. We will definitely have a look.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> with surefire v2.19.1, the above mvn command is always successful on our 
> build machine.  Building with surefire v2.20 results in intermittent failures 
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10 
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342 
> Acknowledge normal exit of JVM and drain shared memory between processes" is 
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it 
> introduces is somehow racy (for example, reading or updating a field-member 
> outside of a monitor) and problems are triggered if there are a large number 
> of JVMs exiting concurrently.  So, with increased number of concurrent JVMs 
> there is an increased risk of a thread loosing the race, and so triggering 
> this error.
> Such a problem would be consistent with observed behaviour.  However, I don't 
> have any strong evidence that this is what is happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MWAR-428) Clean required when dependencies are updated

2019-11-16 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MWAR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MWAR-428.
---
  Assignee: Robert Scholte
Resolution: Duplicate

> Clean required when dependencies are updated
> 
>
> Key: MWAR-428
> URL: https://issues.apache.org/jira/browse/MWAR-428
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Alex lewis
>Assignee: Robert Scholte
>Priority: Major
>
> A {{mvn clean}} is required when a dependency version is updated in a war 
> project pom file; otherwise, both the old and new version of the dependency 
> will appear in the lib directory of the war.
> Steps to recreate:
>  # Create simple war project with 1 or more dependencies.
>  # {{mvn clean package}}
>  # List library jar files in {{target//lib}}.
>  # Update a dependency version in pom.xml
>  # {{mvn package}} (note: no {{clean}}).
>  # List library jar files in {{target//lib}}.
>  ** At this point the lib folder will contain both versions of the dependency.
> Expected:
> A {{clean}} should not required when dependency versions are updated; {{mvn 
> package}} should be sufficient. This expectation is somewhat driven by a 
> discussion with [~rfscholte] on twitter.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MWAR-428) Clean required when dependencies are updated

2019-11-16 Thread Alex lewis (Jira)


[ 
https://issues.apache.org/jira/browse/MWAR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975629#comment-16975629
 ] 

Alex lewis commented on MWAR-428:
-

This is a duplicate of MWAR-427

> Clean required when dependencies are updated
> 
>
> Key: MWAR-428
> URL: https://issues.apache.org/jira/browse/MWAR-428
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Alex lewis
>Priority: Major
>
> A {{mvn clean}} is required when a dependency version is updated in a war 
> project pom file; otherwise, both the old and new version of the dependency 
> will appear in the lib directory of the war.
> Steps to recreate:
>  # Create simple war project with 1 or more dependencies.
>  # {{mvn clean package}}
>  # List library jar files in {{target//lib}}.
>  # Update a dependency version in pom.xml
>  # {{mvn package}} (note: no {{clean}}).
>  # List library jar files in {{target//lib}}.
>  ** At this point the lib folder will contain both versions of the dependency.
> Expected:
> A {{clean}} should not required when dependency versions are updated; {{mvn 
> package}} should be sufficient. This expectation is somewhat driven by a 
> discussion with [~rfscholte] on twitter.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (MPIR-374) Unknown packaging: bundle when creating report

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MPIR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975490#comment-16975490
 ] 

Bernhard Mähr edited comment on MPIR-374 at 11/16/19 12:32 AM:
---

[~michael-o] My fault, the fix should be already in 3.0.1 but 3.0.1 is released 
but not available in the maven repository and not listed as latest version on 
the plugin homepage.
 Could you start this publish process?

[~hboutemy] perhaps?


was (Author: bmaehr):
[~michael-o] My fault, the fix should be already in 3.0.1 but 3.0.1 is released 
but not available in the maven repository and not listed as latest version on 
the plugin homepage.
Could you start this publish process?

> Unknown packaging: bundle when creating report
> --
>
> Key: MPIR-374
> URL: https://issues.apache.org/jira/browse/MPIR-374
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-management
>Affects Versions: 3.0.0
> Environment: Java 10
>Reporter: Peter Lamby
>Priority: Minor
>
> After I upgraded the plugin to 3.0.0 I get the following errors:
> {noformat}
> [INFO] Generating "Dependency Management" report --- 
> maven-project-info-reports-plugin:3.0.0:dependency-management
> [WARNING] Unable to create Maven project for 
> com.fasterxml.jackson.module:jackson-module-scala_2.10:jar:2.9.5 from 
> repository.
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [ERROR] Unknown packaging: bundle @ line 6, column 16
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:192)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:327)
>   at 
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:125)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:253)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:202)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:151)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:144)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:130)
>   at 
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:80)
>   at 
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:107)
>   at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:251)
>   at 
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:230)
>   at 
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:198)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:147)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute

[jira] [Commented] (MPIR-374) Unknown packaging: bundle when creating report

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MPIR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975490#comment-16975490
 ] 

Bernhard Mähr commented on MPIR-374:


[~michael-o] My fault, the fix should be already in 3.0.1 but 3.0.1 is released 
but not available in the maven repository and not listed as latest version on 
the plugin homepage.
Could you start this publish process?

> Unknown packaging: bundle when creating report
> --
>
> Key: MPIR-374
> URL: https://issues.apache.org/jira/browse/MPIR-374
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-management
>Affects Versions: 3.0.0
> Environment: Java 10
>Reporter: Peter Lamby
>Priority: Minor
>
> After I upgraded the plugin to 3.0.0 I get the following errors:
> {noformat}
> [INFO] Generating "Dependency Management" report --- 
> maven-project-info-reports-plugin:3.0.0:dependency-management
> [WARNING] Unable to create Maven project for 
> com.fasterxml.jackson.module:jackson-module-scala_2.10:jar:2.9.5 from 
> repository.
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [ERROR] Unknown packaging: bundle @ line 6, column 16
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:192)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:327)
>   at 
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:125)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:253)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:202)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:151)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:144)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:130)
>   at 
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:80)
>   at 
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:107)
>   at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:251)
>   at 
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:230)
>   at 
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:198)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:147)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.Native

[jira] [Updated] (MWAR-428) Clean required when dependencies are updated

2019-11-15 Thread Alex lewis (Jira)


 [ 
https://issues.apache.org/jira/browse/MWAR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex lewis updated MWAR-428:

Description: 
A {{mvn clean}} is required when a dependency version is updated in a war 
project pom file; otherwise, both the old and new version of the dependency 
will appear in the lib directory of the war.

Steps to recreate:
 # Create simple war project with 1 or more dependencies.
 # {{mvn clean package}}
 # List library jar files in {{target//lib}}.
 # Update a dependency version in pom.xml
 # {{mvn package}} (note: no {{clean}}).
 # List library jar files in {{target//lib}}.
 ** At this point the lib folder will contain both versions of the dependency.

Expected:

A {{clean}} should not required when dependency versions are updated; {{mvn 
package}} should be sufficient. This expectation is somewhat driven by a 
discussion with [~rfscholte] on twitter.

 

  was:
A {{mvn clean}} is required when a dependency version is updated in a war 
project pom file; otherwise, both the old and new version of the dependency 
will appear in the lib directory of the war.

Steps to recreate:
 # Create simple war project with 1 or more dependencies.
 # {{mvn clean package}}
 # List library jar files in {{target//lib}}.
 # Update a dependency version in pom.xml
 # {{mvn package}} (note: no {{clean}}).
 # List library jar files in {{target//lib}}.
 ** At this point the lib folder will contain both versions of the dependency.

Expected:

A {{clean}} should not required when dependency versions are updated; {{mvn 
package}} should be sufficient. This expectation is somewhat driven by recent 
comments [~rfscholte] has made more recently regarding the unnecessary use of 
"clean".

 


> Clean required when dependencies are updated
> 
>
> Key: MWAR-428
> URL: https://issues.apache.org/jira/browse/MWAR-428
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Alex lewis
>Priority: Major
>
> A {{mvn clean}} is required when a dependency version is updated in a war 
> project pom file; otherwise, both the old and new version of the dependency 
> will appear in the lib directory of the war.
> Steps to recreate:
>  # Create simple war project with 1 or more dependencies.
>  # {{mvn clean package}}
>  # List library jar files in {{target//lib}}.
>  # Update a dependency version in pom.xml
>  # {{mvn package}} (note: no {{clean}}).
>  # List library jar files in {{target//lib}}.
>  ** At this point the lib folder will contain both versions of the dependency.
> Expected:
> A {{clean}} should not required when dependency versions are updated; {{mvn 
> package}} should be sufficient. This expectation is somewhat driven by a 
> discussion with [~rfscholte] on twitter.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MWAR-428) Clean required when dependencies are updated

2019-11-15 Thread Alex lewis (Jira)
Alex lewis created MWAR-428:
---

 Summary: Clean required when dependencies are updated
 Key: MWAR-428
 URL: https://issues.apache.org/jira/browse/MWAR-428
 Project: Maven WAR Plugin
  Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Alex lewis


A {{mvn clean}} is required when a dependency version is updated in a war 
project pom file; otherwise, both the old and new version of the dependency 
will appear in the lib directory of the war.

Steps to recreate:
 # Create simple war project with 1 or more dependencies.
 # {{mvn clean package}}
 # List library jar files in {{target//lib}}.
 # Update a dependency version in pom.xml
 # {{mvn package}} (note: no {{clean}}).
 # List library jar files in {{target//lib}}.
 ** At this point the lib folder will contain both versions of the dependency.

Expected:

A {{clean}} should not required when dependency versions are updated; {{mvn 
package}} should be sufficient. This expectation is somewhat driven by recent 
comments [~rfscholte] has made more recently regarding the unnecessary use of 
"clean".

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar

2019-11-15 Thread Robert Scholte (Jira)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975317#comment-16975317
 ] 

Robert Scholte commented on MCOMPILER-372:
--

Can you create a pullrequest at https://github.com/apache/maven-compiler-plugin 
? It will also ask you to provide an integration test to confirm the fix and to 
prevent regression in the future. Advice is to pick another IT from {{src/it}} 
as base.

> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch, 
> univocity-all.zip
>
>
> I'm refactoring 
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into 
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit 
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean 
> install".
>  
> All projects generate test-jars, but for some reason class 
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside 
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests 
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>  
> Interestingly, the issue doesn't seem to be consistent as I got 
> "univocity-csv" and "univocity-tsv" building without errors a few times. 
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile 
> (default-testCompile) on project univocity-csv: Compilation failure: 
> Compilation failure: }}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: package com.univocity.parsers.core.routine}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[124,68]
>  package ResultSetWritingRoutine does not exist}}
>  
> I was also getting errors saying that the "Example" class was not found, or 
> that the "printAndValidate" method was not found (that one comes from the 
> univocity-output-tester dependency)..
>  
> There's something very weird going on and it's 

[jira] [Updated] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Václav Haisman updated MASSEMBLY-923:
-
Description: 
I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for easy 
reproduction. Just run mvn clean install. It appears to be caused by the POM 
format of the axis-ant as it is installed in Maven Central. This was tested 
with Maven 3.6.2.

 
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default 
of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.m

[jira] [Commented] (SUREFIRE-1347) Kafka 0.10.2.0 maven sure fire plugin crash

2019-11-15 Thread Enrico Olivelli (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975207#comment-16975207
 ] 

Enrico Olivelli commented on SUREFIRE-1347:
---

[~karthikus] do you remember how you solved your problem ? 

I am hitting the same in ZooKeeper

> Kafka 0.10.2.0 maven sure fire plugin crash
> ---
>
> Key: SUREFIRE-1347
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1347
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.10
>Reporter: Karthik
>Priority: Major
>  Labels: build
>
> I am trying to create mock kafka server using the following code :
> public MockKafkaServer() throws IOException, InterruptedException {
> int zkPort = this.mockZooKeeper.start();
> this.port = this.getAvailablePort();
> File logDirectory = Files.createTempDir();
> Properties properties = new Properties();
> properties.put("zookeeper.connect", "127.0.0.1:" + zkPort);
> properties.put("num.partitions", "1");
> properties.put("host.name", "localhost");
> properties.put("port", String.valueOf(this.port));
> properties.put("log.dir", logDirectory.getAbsolutePath());
> properties.put("auto.create.topics.enable", "true");
> this.broker = new KafkaServerStartable(new KafkaConfig(properties));
> }
> public void start() throws IOException, InterruptedException {
> this.broker.startup();
> }
> But when I start the server and use it run unit test cases, I get the 
> following error:
> log4j:WARN No appenders could be found for logger (kafka.server.KafkaServer).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 37.087 s
> [INFO] Finished at: 2017-03-24T23:24:25-07:00
> [INFO] Final Memory: 59M/970M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.2-SNAPSHOT:test 
> (default-test) on project restj: There are test failures.
> [ERROR]
> [ERROR] Please refer to 
> /Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj/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] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd 
> /Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/bin/java 
> -server -Xss128m -Xms64m -Xmx256m -XX:+UseCompressedOops -XX:+UseG1GC 
> -XX:G1HeapWastePercent=50 -XX:+CMSClassUnloadingEnabled 
> -XX:MaxGCPauseMillis=10 -XX:+CMSScavengeBeforeRemark 
> '-javaagent:/Users/testuser/.m2/repository/org/jacoco/org.jacoco.agent/0.7.7.201606060606/org.jacoco.agent-0.7.7.201606060606-runtime.jar=destfile=/Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj/target/jacoco.exec,excludes=**/com/company/project/restj/services/MockActiveStreamsService*'
>  -jar 
> /Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj/target/surefire/surefirebooter6808271075445909902.jar
>  /Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj/target/surefire 
> 2017-03-24T11-23-55_783-jvmRun2 surefire8078542159586310233tmp 
> surefire_18213721157775376322tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] Crashed tests:
> [ERROR] com.company.project.restj.RestControllerTest
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: 
> ExecutionException The forked VM terminated without properly saying goodbye. 
> VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd 
> /Users/testuser/Desktop/TVE5/Src-Repo/CBR/maven/restj && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/bin/java 
> -server -Xss128m -Xms64m -Xmx256m -XX:+UseCompressedOops -XX:+UseG1GC 
> -XX:G1HeapWastePercent=50 -XX:+CMSClassUnloadingEnabled 
> -XX:MaxGCPauseMillis=10 -XX:+CMSScavengeBeforeRemark 
> '-javaagent:/Users/testuser/.m2/repository/org/

[jira] [Updated] (SUREFIRE-1720) JUnit 5 @Nested classes are not excluded when name ends in Tests

2019-11-15 Thread Dmitry Timofeev (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Timofeev updated SUREFIRE-1720:
--
Description: 
{color:#808080}`` {color}over source file names does not exclude the 
{color:#808080}`@Nested` {color}test classes, defined inside the matching 
source files, if they end with {color:#808080}`Tests`{color}.
h3. Minimal reproducing project

[https://github.com/dmitry-timofeev/surefire-bug] (contains the instrutctions 
to run)

See AppIntegrationTest.
h3. Surefire Configuration
{code:java}

  maven-surefire-plugin
  ${surefire.version}
  

  
  **/*IntegrationTest.java



  

{code}
h3. {color:#9876aa}Expected Behaviour{color}

When a pattern over source file names is used 
({color:#808080}`*Pattern.java`{color}),
 it must apply to all classes inside that file (including @Nested with any 
name).
h3. {color:#9876aa}Actual Behaviour{color}

The exclusion does not apply to some @Nested classes inside the matching source 
file (e.g, ending with {color:#808080}`Tests`{color}).
h3. Workaround

Also add a pattern, operating on _classes:_ 
{{%regex[.*IntegrationTest\$.*]}}

  was:
{color:#808080}`` {color}over source file names does not exclude the 
{color:#808080}`@Nested` {color}test classes, defined inside the matching 
source files, if they end with {color:#808080}`Tests`{color}.
h3. Minimal reproducing project

[https://github.com/dmitry-timofeev/surefire-bug] (contains the instrutctions 
to run)

See AppIntegrationTest.
h3. Surefire Configuration
{code:java}

  maven-surefire-plugin
  ${surefire.version}
  

  
  **/*IntegrationTest.java



  

{code}
h3. {color:#9876aa}Expected Behaviour{color}

When a pattern over source file names is used 
({color:#808080}`*Pattern.java`{color}),
it must apply to all classes inside that file (including @Nested with any name).
h3. {color:#9876aa}Actual Behaviour{color}

The exclusion does not apply to some @Nested classes inside the matching source 
file (e.g, ending with {color:#808080}`Tests`{color}).


> JUnit 5 @Nested classes are not excluded when name ends in Tests
> 
>
> Key: SUREFIRE-1720
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1720
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.2, 3.0.0-M3
>Reporter: Dmitry Timofeev
>Priority: Minor
>
> {color:#808080}`` {color}over source file names does not exclude the 
> {color:#808080}`@Nested` {color}test classes, defined inside the matching 
> source files, if they end with {color:#808080}`Tests`{color}.
> h3. Minimal reproducing project
> [https://github.com/dmitry-timofeev/surefire-bug] (contains the instrutctions 
> to run)
> See AppIntegrationTest.
> h3. Surefire Configuration
> {code:java}
> 
>   maven-surefire-plugin
>   ${surefire.version}
>   
> 
>   
>   **/*IntegrationTest.java
> 
> 
> 
>   
> 
> {code}
> h3. {color:#9876aa}Expected Behaviour{color}
> When a pattern over source file names is used 
> ({color:#808080}`*Pattern.java`{color}),
>  it must apply to all classes inside that file (including @Nested with any 
> name).
> h3. {color:#9876aa}Actual Behaviour{color}
> The exclusion does not apply to some @Nested classes inside the matching 
> source file (e.g, ending with {color:#808080}`Tests`{color}).
> h3. Workaround
> Also add a pattern, operating on _classes:_ 
> {{%regex[.*IntegrationTest\$.*]}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SUREFIRE-1720) JUnit 5 @Nested classes are not excluded when name ends in Tests

2019-11-15 Thread Dmitry Timofeev (Jira)
Dmitry Timofeev created SUREFIRE-1720:
-

 Summary: JUnit 5 @Nested classes are not excluded when name ends 
in Tests
 Key: SUREFIRE-1720
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1720
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 3.0.0-M3, 2.22.2
Reporter: Dmitry Timofeev


{color:#808080}`` {color}over source file names does not exclude the 
{color:#808080}`@Nested` {color}test classes, defined inside the matching 
source files, if they end with {color:#808080}`Tests`{color}.
h3. Minimal reproducing project

[https://github.com/dmitry-timofeev/surefire-bug] (contains the instrutctions 
to run)

See AppIntegrationTest.
h3. Surefire Configuration
{code:java}

  maven-surefire-plugin
  ${surefire.version}
  

  
  **/*IntegrationTest.java



  

{code}
h3. {color:#9876aa}Expected Behaviour{color}

When a pattern over source file names is used 
({color:#808080}`*Pattern.java`{color}),
it must apply to all classes inside that file (including @Nested with any name).
h3. {color:#9876aa}Actual Behaviour{color}

The exclusion does not apply to some @Nested classes inside the matching source 
file (e.g, ending with {color:#808080}`Tests`{color}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975192#comment-16975192
 ] 

Václav Haisman edited comment on MASSEMBLY-923 at 11/15/19 3:49 PM:


Further debugging reveals that {{dependencyArtifacts = 
project.getDependencyArtifacts();}} already returns the artifact with the null 
file. But I can see that {{project.resolvedArtifacts}} does contain the 
artifact but with the correct path to the file.

This is as far as I can analyze this. This is for someone who actually know 
Maven to debug.


was (Author: wilx):
Further debugging reveals that {{dependencyArtifacts = 
project.getDependencyArtifacts();}} already returns the artifact with the null 
file. But I can see that {{project.resolvedArtifacts}} does contain the 
artifact but with the correct path to the file.


> NPE when axis:axis-ant:1.4 is part of dependencySet
> ---
>
> Key: MASSEMBLY-923
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-923
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Václav Haisman
>Priority: Critical
>
> I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
> GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for 
> easy reproduction. Just run mvn clean install. It appears to be caused by the 
> POM format of the axis-ant as it is installed in Maven Central.
>  
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single 
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at

[jira] [Commented] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975192#comment-16975192
 ] 

Václav Haisman commented on MASSEMBLY-923:
--

Further debugging reveals that {{dependencyArtifacts = 
project.getDependencyArtifacts();}} already returns the artifact with the null 
file. But I can see that {{project.resolvedArtifacts}} does contain the 
artifact but with the correct path to the file.


> NPE when axis:axis-ant:1.4 is part of dependencySet
> ---
>
> Key: MASSEMBLY-923
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-923
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Václav Haisman
>Priority: Critical
>
> I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
> GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for 
> easy reproduction. Just run mvn clean install. It appears to be caused by the 
> POM format of the axis-ant as it is installed in Maven Central.
>  
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single 
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStar

[jira] [Commented] (MDEP-664) Get goal misses unit tests

2019-11-15 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975190#comment-16975190
 ] 

Hudson commented on MDEP-664:
-

Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #41

See 
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/41/

> Get goal misses unit tests
> --
>
> Key: MDEP-664
> URL: https://issues.apache.org/jira/browse/MDEP-664
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>  Components: get
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Somehow the {{get}} goal was missing unit tests. They had been there, but all 
> test methods have been renamed so they didn't get executed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975181#comment-16975181
 ] 

François Loison commented on MCOMPILER-372:
---

I may have found a patch.

Plugin compileTest goal is looking for module-info class in non-test output 
folder.

As a consequence, dependentProject-tests.jar is not added in test compilation 
classpath.

I modified plugin to seach in test output folder.

module-info class is not found, dependentProject-tests.jar is *added* in test 
compilation classpath and test compilation succeeds.

Patch attached : [^maven-compiler-plugin.MCOMPILER-372.patch]

> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch, 
> univocity-all.zip
>
>
> I'm refactoring 
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into 
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit 
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean 
> install".
>  
> All projects generate test-jars, but for some reason class 
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside 
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests 
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>  
> Interestingly, the issue doesn't seem to be consistent as I got 
> "univocity-csv" and "univocity-tsv" building without errors a few times. 
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile 
> (default-testCompile) on project univocity-csv: Compilation failure: 
> Compilation failure: }}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: package com.univocity.parsers.core.routine}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[124,68]
>  package ResultSetWritingRoutine does not exist}}
>  
> I was also getting errors saying that the

[jira] [Updated] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar

2019-11-15 Thread Jira


 [ 
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

François Loison updated MCOMPILER-372:
--
Attachment: maven-compiler-plugin.MCOMPILER-372.patch

> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch, 
> univocity-all.zip
>
>
> I'm refactoring 
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into 
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit 
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean 
> install".
>  
> All projects generate test-jars, but for some reason class 
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside 
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests 
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>  
> Interestingly, the issue doesn't seem to be consistent as I got 
> "univocity-csv" and "univocity-tsv" building without errors a few times. 
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile 
> (default-testCompile) on project univocity-csv: Compilation failure: 
> Compilation failure: }}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: package com.univocity.parsers.core.routine}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetTest}}
> {{[ERROR]   location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,52]
>  cannot find symbol}}
> {{[ERROR]   symbol:   class ResultSetWritingRoutine}}
> {{[ERROR]   location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR] 
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[124,68]
>  package ResultSetWritingRoutine does not exist}}
>  
> I was also getting errors saying that the "Example" class was not found, or 
> that the "printAndValidate" method was not found (that one comes from the 
> univocity-output-tester dependency)..
>  
> There's something very weird going on and it's not consistently reproducible. 
> If you for example change the code in the failing tests use "*import static 
> com.univocity.parsers.core.routine.ResultSetWritingRoutine.** " you may get a 
> different set of errors. It's pretty intractable.
> I hope this provides enough information, let me know if you need anything 
> else.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (MDEP-664) Get goal misses unit tests

2019-11-15 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MDEP-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MDEP-664.
---
Fix Version/s: 3.1.2
 Assignee: Robert Scholte
   Resolution: Fixed

Fixed in 
[c419cd40a14079bcc1e9fc47053bcbe581201446|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commit;h=c419cd40a14079bcc1e9fc47053bcbe581201446]
Thanks for the patch!

> Get goal misses unit tests
> --
>
> Key: MDEP-664
> URL: https://issues.apache.org/jira/browse/MDEP-664
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>  Components: get
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Somehow the {{get}} goal was missing unit tests. They had been there, but all 
> test methods have been renamed so they didn't get executed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975169#comment-16975169
 ] 

Václav Haisman commented on MASSEMBLY-923:
--

It looks like the issue might be elsewhere. It seems that in 
{{org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase#execute}}
 the set returned by {{dependencyResolver.resolveDependencySets( assembly, 
configSource, assembly.getDependencySets() )}} already contains the {{null}} 
file field in {{DefaultArtifact}}.

> NPE when axis:axis-ant:1.4 is part of dependencySet
> ---
>
> Key: MASSEMBLY-923
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-923
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: dependencySet
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Václav Haisman
>Priority: Critical
>
> I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
> GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for 
> easy reproduction. Just run mvn clean install. It appears to be caused by the 
> POM format of the axis-ant as it is installed in Maven Central.
>  
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
> project maven-assembly-plugin-npe: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single 
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder

[jira] [Updated] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Václav Haisman updated MASSEMBLY-923:
-
Description: 
I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for easy 
reproduction. Just run mvn clean install. It appears to be caused by the POM 
format of the axis-ant as it is installed in Maven Central.

 
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default 
of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
Cau

[jira] [Updated] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Václav Haisman updated MASSEMBLY-923:
-
Description: 
I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
GitHub repository [https://github.com/wilx/maven-assembly-plugin-npe] for easy 
reproduction. Just run mvn clean install. It appears to be caused by the POM 
format of the axis-ant as it is installed in Maven Central.

 

{{[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.: 
NullPointerException -> [Help 1]}}
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single (default) on 
project maven-assembly-plugin-npe: Execution default of goal 
org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:215)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)}}
{{ at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)}}
{{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
{{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
{{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
{{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)}}
{{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)}}
{{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)}}
{{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
{{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)}}
{{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)}}
{{ at java.lang.reflect.Method.invoke (Method.java:566)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)}}
{{Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default of goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single 
failed.}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:148)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)}}
{{ at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)}}
{{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)}}
{{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
{{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
{{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
{{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)}}
{{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)}}
{{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)}}
{{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
{{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)}}
{{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)}}
{{ at java.lang.reflect.Method.invoke (Method.java:566)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)}}
{{ at org.codehaus.plexus.classworlds.launcher.Launcher.m

[jira] [Created] (MASSEMBLY-923) NPE when axis:axis-ant:1.4 is part of dependencySet

2019-11-15 Thread Jira
Václav Haisman created MASSEMBLY-923:


 Summary: NPE when axis:axis-ant:1.4 is part of dependencySet
 Key: MASSEMBLY-923
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-923
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 3.2.0, 3.1.1
Reporter: Václav Haisman


I can reproduce a NPE when axis:axis-ant:1.4 is part of dependencySet. See 
GitHub repository 
[https://github.com/wilx/maven-assembly-plugin-npe|https://github.com/wilx/maven-assembly-plugin-npe]
 for easy reproduction. Just run mvn clean install. It appears to be caused by 
the POM format of the axis-ant as it is installed in Maven Central.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs

2019-11-15 Thread Robert Scholte (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975144#comment-16975144
 ] 

Robert Scholte commented on MNG-6772:
-

My focus is on something else right now. 
And fixing things in Maven Dependency Resolution has a history. Did you notice 
the missing Maven 3.4.0? It was an attempt to improve it, but it complete 
changed Maven behavior, breaking a huge amount of projects.
So changing something that seems to work for quite a while must be done with 
great care.

To me overriding 'central' from within the project is a 'codesmell', the 
preferred way is the settings.xml. I have worked for huge companies and i I 
don't understand the issue with distributing these settings. 
All together I won't pick this up soon, maybe somebody else will.

> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to 
> specifically override the entry in the Super POM. This is specifically what 
> [JFrog Artifactory 
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
>  doing, and seems valid in situations where the _real_ Maven Central may be 
> unreachable.
>  
> The override takes precedence almost all of the time. However, there is at 
> least one scenario where this is not the case, and that is when importing a 
> POM that in turn imports another POM.
>  
> Digging into the code, it appears the reason this happens is because the 
> {{DefaultModelBuilder}} overwrites repositories after interpolation is 
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>  
> From what I can tell, this is done with the intention of overwriting 
> repositories that were added to the local resolver prior to interpolation 
> with the interpolated version. Due to the way the {{DefaultModelResolver}} 
> works, an unintended side effect is that the {{central}} repository from the 
> Super POM is added once after each interpolation. The first time the 
> repository is added, it is added to the {{repositoryIds}} but doesn't 
> actually remove the original repository. The second time it is added is when 
> the original repository will be replaced. Currently, the repositoryIds are 
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the 
> behavior I am seeing where the second nested import POM ends up being where 
> the failure occurs.
>  
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that 
> resets the repositoryIds prior to import POMs being resolved, since they are 
> separate artifact builds. That seems like the most consistent fix to me that 
> covers cases outside of the the Super POM's {{central}} definition.
>  
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for 
> my Artifactory repository, which isn't ideal since it leaves the potential 
> for long timeouts to occur on the real {{central}} when an artifact can't be 
> resolved from my Artifactory repository.
>  
> Mirrors are not an ideal workaround since getting them in place on all 
> possible build environments isn't trivial.
>  
> When looking at the code I noticed 
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being 
> checked in various places, which seems like it would also act as a potential 
> workaround, but I don't see a way to enable this value via MavenCLI or 
> properties of any kind. It seems like this value aligns well with what 
> Artifactory is already trying to enforce, so it would make sense to enable 
> this in projects that intend to exclusively use Artifactory. Is there a 
> supported way to set this value outside of constructing a Maven build in code?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MDEP-664) Get goal misses unit tests

2019-11-15 Thread Maarten Mulders (Jira)
Maarten Mulders created MDEP-664:


 Summary: Get goal misses unit tests
 Key: MDEP-664
 URL: https://issues.apache.org/jira/browse/MDEP-664
 Project: Maven Dependency Plugin
  Issue Type: Improvement
  Components: get
Reporter: Maarten Mulders


Somehow the {{get}} goal was missing unit tests. They had been there, but all 
test methods have been renamed so they didn't get executed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs

2019-11-15 Thread Dustin Singleton (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975096#comment-16975096
 ] 

Dustin Singleton commented on MNG-6772:
---

Is there any hope that we could get this fixed?  We are trying to push all of 
our traffic through an internal repository manager.  Given that we can 
seemingly limit it through all other situations except for pom imports makes me 
feel like the current behavior is inconsistent.

We are doing this change with the hope of being good stewards of the entire 
ecosystem.  We could definitely use settings.xml files on our shared CI boxes, 
but making sure that the correct settings.xml file lands on every single 
developers machine in a really large company is not that likely to work for us. 
 

The other part of this to consider... is there a scenario or reason we would 
even want the current behavior? 

> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to 
> specifically override the entry in the Super POM. This is specifically what 
> [JFrog Artifactory 
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
>  doing, and seems valid in situations where the _real_ Maven Central may be 
> unreachable.
>  
> The override takes precedence almost all of the time. However, there is at 
> least one scenario where this is not the case, and that is when importing a 
> POM that in turn imports another POM.
>  
> Digging into the code, it appears the reason this happens is because the 
> {{DefaultModelBuilder}} overwrites repositories after interpolation is 
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>  
> From what I can tell, this is done with the intention of overwriting 
> repositories that were added to the local resolver prior to interpolation 
> with the interpolated version. Due to the way the {{DefaultModelResolver}} 
> works, an unintended side effect is that the {{central}} repository from the 
> Super POM is added once after each interpolation. The first time the 
> repository is added, it is added to the {{repositoryIds}} but doesn't 
> actually remove the original repository. The second time it is added is when 
> the original repository will be replaced. Currently, the repositoryIds are 
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the 
> behavior I am seeing where the second nested import POM ends up being where 
> the failure occurs.
>  
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that 
> resets the repositoryIds prior to import POMs being resolved, since they are 
> separate artifact builds. That seems like the most consistent fix to me that 
> covers cases outside of the the Super POM's {{central}} definition.
>  
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for 
> my Artifactory repository, which isn't ideal since it leaves the potential 
> for long timeouts to occur on the real {{central}} when an artifact can't be 
> resolved from my Artifactory repository.
>  
> Mirrors are not an ideal workaround since getting them in place on all 
> possible build environments isn't trivial.
>  
> When looking at the code I noticed 
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being 
> checked in various places, which seems like it would also act as a potential 
> workaround, but I don't see a way to enable this value via MavenCLI or 
> properties of any kind. It seems like this value aligns well with what 
> Artifactory is already trying to enforce, so it would make sense to enable 
> this in projects that intend to exclusively use Artifactory. Is there a 
> supported way to set this value outside of constructing a Maven build in code?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEPLOY-262) Fail on HTTP-Statuscode 409 on Upload instead of warn

2019-11-15 Thread Andreas Wirooks (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975093#comment-16975093
 ] 

Andreas Wirooks commented on MDEPLOY-262:
-

See also this logline:

{noformat}
930333 [WARNING] Failed to upload checksum REPLACED-sources.jar.md5: Failed to 
transfer file https://REPLACED-sources.jar.md5 with status code 409
{noformat}

 

> Fail on HTTP-Statuscode 409 on Upload instead of warn
> -
>
> Key: MDEPLOY-262
> URL: https://issues.apache.org/jira/browse/MDEPLOY-262
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> Environment: Debian 10
> Maven 3.6.1
> Artifactory 6.13.1
>Reporter: Andreas Wirooks
>Priority: Major
>
> We have the situation that an upload fails with HTTP-Statuscode 409. Here the 
> maven-deploy-plugin should stop with an error. But it only warns and 
> continues. This results in missing files or in case of overwriting different 
> contents when overwriting did not succeed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MDEPLOY-262) Fail on HTTP-Statuscode 409 on Upload instead of warn

2019-11-15 Thread Andreas Wirooks (Jira)
Andreas Wirooks created MDEPLOY-262:
---

 Summary: Fail on HTTP-Statuscode 409 on Upload instead of warn
 Key: MDEPLOY-262
 URL: https://issues.apache.org/jira/browse/MDEPLOY-262
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy
Affects Versions: 3.0.0-M1
 Environment: Debian 10
Maven 3.6.1
Artifactory 6.13.1
Reporter: Andreas Wirooks


We have the situation that an upload fails with HTTP-Statuscode 409. Here the 
maven-deploy-plugin should stop with an error. But it only warns and continues. 
This results in missing files or in case of overwriting different contents when 
overwriting did not succeed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MCOMPILER-403) Spring Lombok -Werror [ERROR] An unknown compilation problem occurred

2019-11-15 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975072#comment-16975072
 ] 

Jakub Bochenski commented on MCOMPILER-403:
---

Use true to see warnings, the you will see it's 
this issue 
https://github.com/spring-projects/spring-boot/issues/6421#issuecomment-233591004

> Spring Lombok -Werror [ERROR] An unknown compilation problem occurred
> -
>
> Key: MCOMPILER-403
> URL: https://issues.apache.org/jira/browse/MCOMPILER-403
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Windows 10 Apache Maven 3.6.1, Java 1.8.0_231 or 11.0.4
>Reporter: Igor Rybak
>Priority: Major
> Attachments: spring-lombok-werror-bug-demo.zip
>
>
> Compilation fails with -Werror and Lombok in Spring Boot project with the 
> message "An unknown compilation problem occurred"
> Steps to reproduce:
> 1. Open the sample project spring-lombok-werror-bug-demo.zip
> 2. run {{mvn clean package}} in the root of the project (Apache Maven 3.6.1, 
> Java 1.8.0_231 or 11.0.4)
> Here is the same issue on Lombok GitHub repository:
> [https://github.com/rzwitserloot/lombok/issues/2285]
> {code:java}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 5.698 s
> [INFO] Finished at: 2019-11-07T14:48:32+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (default-compile) on project spring-lombok-demo: Compilation failure -> [Help 
> 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (default-compile) on project spring-lombok-demo: Compilation failure
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:498)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: 
> Compilation failure
>  at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:1224)
>  at org.apache.maven.plugin.compiler.CompilerMojo.execute 
> (CompilerMojo.java:187)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
&g

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console

2019-11-15 Thread Aaron Digulla (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975017#comment-16975017
 ] 

Aaron Digulla commented on SUREFIRE-1631:
-

Things will be easier to understand if you used "Maven parent process" instead 
of "Maven" and "Surefire subprocess" / "Surefire child process" instead of 
"self fork JVM" in the error messages.

[https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java;h=9da6d9b50d54ba84206e90a9fe3a5d23c55735b9;hb=08ff28f17ad251bcbe9440b00cc445ce69405efc#l237]

When I read the code, I was under the impression that SurefireBooter is the 
parent (which creates the forked VM) and that the parent controls everything. 
When I look at the code now, I see that the child wants to know whether the 
parent is still there.

That said, just checking the stdin for EOF in the child process should be 
enough to find out whether the parent died / went away; why this complex magic 
with PINGs and the like?

 

> Forked VM terminated without properly saying goodbye with AciveMQ on 
> Windows10 and MinTTY(Cygwin) console
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console

2019-11-15 Thread Aaron Digulla (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975005#comment-16975005
 ] 

Aaron Digulla commented on SUREFIRE-1631:
-

I'm still unsure what happens. When it happened for me, no JVM dumps or errors 
were written. From the thread dumps provided by [~adolfo.cia] , it seems the 
child process was killed in the middle by something.

Does the Maven parent process kill the Surefire child?

If so, why doesn't the parent print the reason anywhere? 

As it is, it looks as if someone suddenly killed the JVM and Maven has no clue.

If my description is correct, please add big fat warnings into the parent 
output: "Killed Surefire child process because XXX. See [https://maven.org/...] 
for details"

 

> Forked VM terminated without properly saying goodbye with AciveMQ on 
> Windows10 and MinTTY(Cygwin) console
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MSHADE-334) reproducible build

2019-11-15 Thread Michael Brackx (Jira)


[ 
https://issues.apache.org/jira/browse/MSHADE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974988#comment-16974988
 ] 

Michael Brackx commented on MSHADE-334:
---

for files copied from other archives the original timestamp could be used iso 
project.build.outputTimestamp

this seems to be the case already for resources (e.g. .xml, .properties, .txt 
files)

> reproducible build
> --
>
> Key: MSHADE-334
> URL: https://issues.apache.org/jira/browse/MSHADE-334
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Michael Brackx
>Priority: Major
>
> currently some entries in the archive use the current time
> for example directories and class files
> see
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MSHADE-334) reproducible build

2019-11-15 Thread Michael Brackx (Jira)
Michael Brackx created MSHADE-334:
-

 Summary: reproducible build
 Key: MSHADE-334
 URL: https://issues.apache.org/jira/browse/MSHADE-334
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 3.2.1
Reporter: Michael Brackx


currently some entries in the archive use the current time

for example directories and class files

see

https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6771) Fix license issues on binary distribution

2019-11-15 Thread Robert Scholte (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MNG-6771:

Fix Version/s: 3.6.3

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
> Fix For: 3.6.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6798) build-helper-maven-plugin: java.lang.IllegalArgumentException: version can neither be null, empty nor blank

2019-11-14 Thread Stefan Seifert (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974597#comment-16974597
 ] 

Stefan Seifert commented on MNG-6798:
-

there is a PR for the build-helper-maven-plugin which seems to fix the problem 
- works fine for me with maven 3.6.2
https://github.com/mojohaus/build-helper-maven-plugin/pull/82

> build-helper-maven-plugin: java.lang.IllegalArgumentException: version can 
> neither be null, empty nor blank
> ---
>
> Key: MNG-6798
> URL: https://issues.apache.org/jira/browse/MNG-6798
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.6.2
>Reporter: Jamin Collins
>Priority: Major
>
> After upgrading to maven 3.6.2 I found that I could no longer successfully 
> build one of my projects.  The error:
> {quote}
>  [ERROR] Failed to execute goal 
> org.codehaus.mojo:build-helper-maven-plugin:3.0.0:released-version 
> (released-version) on project forge-gui-desktop: Execution released-version 
> of goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:released-version 
> failed: version can neither be null, empty nor blank -> [Help 1]
> {quote}
> seemed to indicate a problem with one of the plugins, specifically 
> *build-helper-maven-plugin*.  However, I have found that rolling maven (and 
> only maven) back to 3.6.1 allows the project to build.  So, this appears to 
> be a problem with maven and not the plugin.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


  1   2   3   4   5   6   7   8   9   10   >