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

[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(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
>   at 
> 

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

[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.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 

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

[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

[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

[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 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 

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

[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.main 

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

[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/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
> 

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

[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

[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

[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 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> 

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

[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.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 

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

[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

[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 "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 
> 

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

[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

[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)

[GitHub] [maven-dependency-plugin] rfscholte merged pull request #25: [MDEP-664] Restore disabled unit tests for Get goal

[GitBox]

rfscholte merged pull request #25: [MDEP-664] Restore disabled unit tests for 
Get goal
URL: https://github.com/apache/maven-dependency-plugin/pull/25
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[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.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 

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

[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)
Caused by: 

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

[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.main 

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

[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

[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)

[GitHub] [maven-dependency-plugin] mthmulders opened a new pull request #25: [MDEP-664] Restore disabled unit tests for Get goal

[GitBox]

mthmulders opened a new pull request #25: [MDEP-664] Restore disabled unit 
tests for Get goal
URL: https://github.com/apache/maven-dependency-plugin/pull/25
 
 
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [X] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MDEP-664) filed for the change 
(usually before you start working on it).  Trivial changes like typos do not 
require a JIRA issue.  Your pull request should address just this issue, 
without pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line 
and body.
- [X] Format the pull request title like `[MDEP-XXX] - Fixes bug in 
ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA 
issue. Best practice is to use the JIRA issue title in the pull request title 
and in the first line of the commit message.
- [X] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an 
[Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please 
ask on the developers list.
   
   To make clear that you license your contribution under the [Apache License 
Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have 
to acknowledge this by using the following check-box.
   
- [X] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[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

[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

[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

[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

[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 
> (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 

[GitHub] [maven-dependency-plugin] S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554323925
 
 
   @mthmulders 
   > > As for the tests I have an issue as all the tree dependency tests 
are disabled for the moment and not quite working. My skill in java is not good 
enough to make it work crying_cat_face
   > 
   > I don't really understand what you mean. On master branch, running `mvn 
verify`, I'm seeing
   > 
   > ```
   > Tests run: 247, Failures: 0, Errors: 0, Skipped: 0
   > ```
   > 
   > Could you please elaborate?
   ```
   package org.apache.maven.plugins.dependency.tree;
   public void testVoid()
   {
   // TODO: tests disabled during MDEP-339 work, to be reactivated
   }
   public void _testTreeTestEnvironment()
   ...
   public void _testTreeDotSerializing()
   ...
   public void _testTreeGraphMLSerializing()
   ...
   public void _testTreeTGFSerializing()
   ...
   ```
   
   As i understand it `_` means ignore this testcase. Removing `_` results is 
   `mvn verify`
   ```
   [ERROR] Errors: 
   [ERROR]   TestTreeMojo.testTreeDotSerializing:104->runTreeMojo:174 » 
NullPointer
   [ERROR]   TestTreeMojo.testTreeGraphMLSerializing:120->runTreeMojo:174 » 
NullPointer
   [ERROR]   TestTreeMojo.testTreeTGFSerializing:139->runTreeMojo:174 » 
NullPointer
   [ERROR]   TestTreeMojo.testTreeTestEnvironment:87 » NullPointer
   [INFO] 
   [ERROR] Tests run: 255, Failures: 0, Errors: 4, Skipped: 0
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[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)

[GitHub] [maven-dependency-plugin] mthmulders commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

mthmulders commented on issue #24: [MDEP-435] Added xml outputType to 
dependency tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554312759
 
 
   > As for the tests I have an issue as all the tree dependency tests are 
disabled for the moment and not quite working. My skill in java is not good 
enough to make it work 
   
   I don't really understand what you mean. On master branch, running `mvn 
verify`, I'm seeing
   
   ```
   Tests run: 247, Failures: 0, Errors: 0, Skipped: 0
   ```
   
   Could you please elaborate?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[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

[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

[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)

[GitHub] [maven-dependency-plugin] S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554289705
 
 
   @rfscholte 
   ```
   
 org.apache.maven.plugins
 maven-dependency-plugin
 3.1.2-SNAPSHOT
 maven-plugin
 
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-dependency-plugin] S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554284537
 
 
   
   
   
   
   > Looks quite good, just know that a project cannot have a `scope`, and its 
`type` is called `packaging`.
   
   Will update the root node then


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-dependency-plugin] rfscholte commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

rfscholte commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554283078
 
 
   Looks quite good, just know that a project cannot have a `scope`, and its 
`type` is called `packaging`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[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)

[GitHub] [maven-dependency-plugin] S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554273028
 
 
   As for the tests I have an issue as all the tree dependency tests are 
disabled for the moment and not quite working. My skill in java is not good 
enough to make it work :crying_cat_face: 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-dependency-plugin] S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

S4n60w3n commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-554272389
 
 
   @rfscholte Is this more to your liking? 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services