[jira] [Comment Edited] (MINVOKER-247) NPE in InstallMojo
[
https://issues.apache.org/jira/browse/MINVOKER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822617#comment-16822617
]
Adrian Cole edited comment on MINVOKER-247 at 4/21/19 3:37 AM:
---
particularly at the edge of large projects, this bug is debilitating for
efficiency as you have to use `--am` to avoid tripping it. For example, in
zipkin this adds a few minutes even skipping tests.
Is there any way that a fix can be released here even if it "should" be
reverted whenever the upstream concern is addressed?
FWIW we are on absolute latest maven 3.6.1 and no other plug-ins are
out-of-date (to our knowledge)
was (Author: adriancole):
particularly at the edge of large projects, this bug is debilitating for
efficiency as you have to use `--am` to avoid tripping it. For example, in
zipkin this adds a few minutes even skipping tests.
Is there any way that a fix can be released here even if it "should" be
reverted whenever the upstream concern is addressed?
> NPE in InstallMojo
> --
>
> Key: MINVOKER-247
> URL: https://issues.apache.org/jira/browse/MINVOKER-247
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Blocker
> Fix For: 3.2.1
>
>
> {code:java}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectPom
> (InstallMojo.java:387)
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectArtifacts
> (InstallMojo.java:325)
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectDependencies
> (InstallMojo.java:462)
> at org.apache.maven.plugins.invoker.InstallMojo.execute
> (InstallMojo.java:184){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINVOKER-247) NPE in InstallMojo
[
https://issues.apache.org/jira/browse/MINVOKER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822617#comment-16822617
]
Adrian Cole commented on MINVOKER-247:
--
particularly at the edge of large projects, this bug is debilitating for
efficiency as you have to use `--am` to avoid tripping it. For example, in
zipkin this adds a few minutes even skipping tests.
Is there any way that a fix can be released here even if it "should" be
reverted whenever the upstream concern is addressed?
> NPE in InstallMojo
> --
>
> Key: MINVOKER-247
> URL: https://issues.apache.org/jira/browse/MINVOKER-247
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Blocker
> Fix For: 3.2.1
>
>
> {code:java}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectPom
> (InstallMojo.java:387)
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectArtifacts
> (InstallMojo.java:325)
> at org.apache.maven.plugins.invoker.InstallMojo.installProjectDependencies
> (InstallMojo.java:462)
> at org.apache.maven.plugins.invoker.InstallMojo.execute
> (InstallMojo.java:184){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822543#comment-16822543 ] Hudson commented on MNG-6573: - Build failed in Jenkins: Maven TLP » maven-scm-publish-plugin » stabilize #6 See https://builds.apache.org/job/maven-box/job/maven-scm-publish-plugin/job/stabilize/6/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822539#comment-16822539 ] Hudson commented on MNG-6573: - Build succeeded in Jenkins: Maven TLP » maven-doxia-site » master #5 See https://builds.apache.org/job/maven-box/job/maven-doxia-site/job/master/5/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6636) NPE on reporting convertion (DefaultReportingConverter) when inheritance of with no reports
[
https://issues.apache.org/jira/browse/MNG-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6636:
---
Summary: NPE on reporting convertion (DefaultReportingConverter) when
inheritance of with no reports (was: NPE on reporting convertion when
inheritance of with no reports)
> NPE on reporting convertion (DefaultReportingConverter) when inheritance of
> with no reports
> ---
>
> Key: MNG-6636
> URL: https://issues.apache.org/jira/browse/MNG-6636
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.1
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.2
>
>
> when launching Maven on maven-site:
> {noformat}$ mvn clean
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:606)
> 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: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at
> org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616){noformat}
> caused by the fact that there is no elements in following
> reportSet:
> {code:xml}
> true
> ${site.output}
>
>
> org.apache.maven.plugins
> maven-project-info-reports-plugin
>
>
>
> true
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-6644.
--
Resolution: Duplicate
as written in the release notes
https://maven.apache.org/docs/3.6.1/release-notes.html#Known_Issues , this is a
known issue tracked as MNG-6636
and there is a workaround that should be easy to use
closing this issue as duplicate
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> 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)
> 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.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> 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)
> at
[GitHub] [maven-surefire] Tibor17 opened a new pull request #231: Failsafe: Killing self fork JVM. PING timeout elapsed.
Tibor17 opened a new pull request #231: Failsafe: Killing self fork JVM. PING timeout elapsed. URL: https://github.com/apache/maven-surefire/pull/231 Follows the discussion in https://lists.apache.org/thread.html/74fcc1fe41c656c01ac76e7a3f177b8c1a45a5c35e0e014ae7f6a0b8@%3Cusers.maven.apache.org%3E 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] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822459#comment-16822459
]
Hudson commented on MNG-6642:
-
Build succeeded in Jenkins: Maven TLP » maven » master #199
See https://builds.apache.org/job/maven-box/job/maven/job/master/199/
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5995) Maven itself cannot run without maven-compat
[
https://issues.apache.org/jira/browse/MNG-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822460#comment-16822460
]
Hudson commented on MNG-5995:
-
Build succeeded in Jenkins: Maven TLP » maven » master #199
See https://builds.apache.org/job/maven-box/job/maven/job/master/199/
> Maven itself cannot run without maven-compat
>
>
> Key: MNG-5995
> URL: https://issues.apache.org/jira/browse/MNG-5995
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, core
>Affects Versions: 3.3.9
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For all the 3.0 versions of the maven-plugins we require to not depend on
> maven-compat anymore. However, the Maven distribution still requires
> maven-compat. A simple proof: remove {{lib/maven-compat-3.x.y}} and execute
> {{mvn validate}}.
> You'll get the following exception:
> {noformat}[WARNING] Error injecting:
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was
> bound.
> while locating
> org.apache.maven.project.DefaultProjectBuildingHelper{noformat}
> Reason: there's only one implementation: o.a.m.r.l.LegacyRepositorySystem,
> which is part of maven-compat.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6646) Upgrade maven-assembly-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822458#comment-16822458 ] Hudson commented on MNG-6646: - Build succeeded in Jenkins: Maven TLP » maven » master #199 See https://builds.apache.org/job/maven-box/job/maven/job/master/199/ > Upgrade maven-assembly-plugin to 3.1.1 > -- > > Key: MNG-6646 > URL: https://issues.apache.org/jira/browse/MNG-6646 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.2 > > > Upgrade the Maven Assembly plug-in to improve build time - 4 times faster for > creating a package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822452#comment-16822452
]
Hudson commented on MNG-6405:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6646) Upgrade maven-assembly-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822453#comment-16822453 ] Hudson commented on MNG-6646: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/ > Upgrade maven-assembly-plugin to 3.1.1 > -- > > Key: MNG-6646 > URL: https://issues.apache.org/jira/browse/MNG-6646 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.2 > > > Upgrade the Maven Assembly plug-in to improve build time - 4 times faster for > creating a package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6627) upgrade plexus-component-metadata to 2.0.0 to get reproducible META-INF/plexus/components.xml
[ https://issues.apache.org/jira/browse/MNG-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822451#comment-16822451 ] Hudson commented on MNG-6627: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/ > upgrade plexus-component-metadata to 2.0.0 to get reproducible > META-INF/plexus/components.xml > - > > Key: MNG-6627 > URL: https://issues.apache.org/jira/browse/MNG-6627 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.1 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: 3.6.2 > > > see [https://s.apache.org/MavenReproducibleBuilds] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822454#comment-16822454
]
Hudson commented on MNG-6642:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5995) Maven itself cannot run without maven-compat
[
https://issues.apache.org/jira/browse/MNG-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822455#comment-16822455
]
Hudson commented on MNG-5995:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> Maven itself cannot run without maven-compat
>
>
> Key: MNG-5995
> URL: https://issues.apache.org/jira/browse/MNG-5995
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, core
>Affects Versions: 3.3.9
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For all the 3.0 versions of the maven-plugins we require to not depend on
> maven-compat anymore. However, the Maven distribution still requires
> maven-compat. A simple proof: remove {{lib/maven-compat-3.x.y}} and execute
> {{mvn validate}}.
> You'll get the following exception:
> {noformat}[WARNING] Error injecting:
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was
> bound.
> while locating
> org.apache.maven.project.DefaultProjectBuildingHelper{noformat}
> Reason: there's only one implementation: o.a.m.r.l.LegacyRepositorySystem,
> which is part of maven-compat.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822450#comment-16822450
]
Hudson commented on MNG-6618:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.1
>
>
> Hi, this is the same issue as
> [MNG-6360|https://issues.apache.org/jira/browse/MNG-6360]. Unfortunately I
> was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code:java}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 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:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> 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
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>
[jira] [Commented] (MNG-6522) Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
[ https://issues.apache.org/jira/browse/MNG-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822456#comment-16822456 ] Hudson commented on MNG-6522: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/ > Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea > -- > > Key: MNG-6522 > URL: https://issues.apache.org/jira/browse/MNG-6522 > Project: Maven > Issue Type: Improvement > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > * JDK 12 Windows and Linux (/) > - JDK 13 Window and Linux (/) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6611) Update animal-sniffer-maven-plugin to 1.17
[ https://issues.apache.org/jira/browse/MNG-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822448#comment-16822448 ] Hudson commented on MNG-6611: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/ > Update animal-sniffer-maven-plugin to 1.17 > -- > > Key: MNG-6611 > URL: https://issues.apache.org/jira/browse/MNG-6611 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Attachments: MNG-6611-stacktrace.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Update animal-sniffer-maven-plugin from 1.15 to version 1.17 to get support > for use [multi-release jar|http://openjdk.java.net/jeps/238] that was > introduced in 1.16 > https://github.com/mojohaus/animal-sniffer/milestone/2?closed=1 > will permit to use MR jars as dependency to Maven's Core - like slf4j > 1.8.0-beta4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822447#comment-16822447 ] Hudson commented on MNG-6573: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6605) Allow to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822449#comment-16822449
]
Hudson commented on MNG-6605:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> Allow to suppress download messages in interactive mode
> ---
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
> Attachments: 2019-03-06_14-06-09.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven] slachiewicz commented on issue #245: Remove unused code that triggers Error Prone.
slachiewicz commented on issue #245: Remove unused code that triggers Error Prone. URL: https://github.com/apache/maven/pull/245#issuecomment-485127971 Thx, done in fdde73fcb418a9d476cec61ccfa140e870f169bb 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] josephw opened a new pull request #245: Remove unused code that triggers Error Prone.
josephw opened a new pull request #245: Remove unused code that triggers Error Prone. URL: https://github.com/apache/maven/pull/245 Running Error Prone over Maven triggers an infinite recursion check in AbstractCoreMavenComponentTestCase.PluginBuilder; on inspection, the class is unused. Remove it, along with the commented- out (since bc257a588e) reference to it. - [y] 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] [Updated] (MJAVADOC-600) -bottom parameter breaks some doclets
[
https://issues.apache.org/jira/browse/MJAVADOC-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Parry updated MJAVADOC-600:
---
Description:
When using with some custom doclets e.g. pdfdoclet 1.0.2, you cannot suppress
the -bottom parameter - :which causes the doclet to fail :
{code:java}
Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:javadoc (default-cli) on
project WordNetTestApp: An error has occurred in PDF Doclet Output report
generation:
Exit code: 1 - javadoc: error - invalid flag: -bottom
{code}
> -bottom parameter breaks some doclets
> -
>
> Key: MJAVADOC-600
> URL: https://issues.apache.org/jira/browse/MJAVADOC-600
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Stephen Parry
>Priority: Major
>
> When using with some custom doclets e.g. pdfdoclet 1.0.2, you cannot suppress
> the -bottom parameter - :which causes the doclet to fail :
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:javadoc (default-cli) on
> project WordNetTestApp: An error has occurred in PDF Doclet Output report
> generation:
> Exit code: 1 - javadoc: error - invalid flag: -bottom
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-600) -bottom parameter breaks some doclets
Stephen Parry created MJAVADOC-600: -- Summary: -bottom parameter breaks some doclets Key: MJAVADOC-600 URL: https://issues.apache.org/jira/browse/MJAVADOC-600 Project: Maven Javadoc Plugin Issue Type: Bug Reporter: Stephen Parry -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[
https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822409#comment-16822409
]
Tibor Digana edited comment on SUREFIRE-1652 at 4/20/19 11:35 AM:
--
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different {{major or minor version}} (in
bytecode of *.class files) than the version of Java runtime supports in Maven,
this JRE fails because Java in Maven does not understand the bytecode. So, it
is curious that the same JVM ({{javac}}) produced two major versions depending
on JVM option and {{java}} from the same JVM does not understand it been
incompatible for itself. Although version in forked JVM is totally fine and
understands the the classes compiled by {{javac}} because {{javac}} and forked
JVM start with the same option {{--enable-preview}}.
It is the same situation as if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{version}} (in
bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicated change and still questionary.
was (Author: tibor17):
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different {{major version}} (in bytecode
of *.class files) than the version of Java runtime supports in Maven, this JRE
fails because Java in Maven does not understand the bytecode. So, it is curious
that the same JVM ({{javac}}) produced two major versions depending on JVM
option and {{java}} from the same JVM does not understand it been incompatible
for itself. Although version in forked JVM is totally fine and understands the
the classes compiled by {{javac}} because {{javac}} and forked JVM start with
the same option {{--enable-preview}}.
It is the same situation as if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
(in bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicated change and still questionary.
> surefire/failsafe fails with --enable-preview in java 12
>
>
> Key: SUREFIRE-1652
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1652
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Krzysztof Krason
>Assignee: Tibor Digana
>Priority: Blocker
>
> Minimal example: [https://github.com/krzyk/lombok-jdk10-example]
>
> When I run the build `mvn clean verify` in the above repository I get
> following error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test)
> on project lombok-jdk10: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed:
> java.lang.UnsupportedClassVersionError: Preview features are not enabled for
> com/kirela/lombok/BarTest (class file version 56.65535). Try running with
> '--enable-preview' -> [Help 1]
>
> Tests work when I remove `--enable-preview` from compiler OR when I remove
> "forkCount" from surefire (and failsafe) configuration.
> As I understand argLine property should be used in all forks, but appears to
> be ignored, there is no difference if I use it as a property or as a
> configuration paramater in surefire/failsafe.
>
> This bug makes using Java 12 with preview features unusable with
> surefire/failsafe.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[
https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822409#comment-16822409
]
Tibor Digana edited comment on SUREFIRE-1652 at 4/20/19 10:57 AM:
--
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different {{major version}} (in bytecode
of *.class files) than the version of Java runtime supports in Maven, this JRE
fails because Java in Maven does not understand the bytecode. So, it is curious
that the same JVM ({{javac}}) produced two major versions depending on JVM
option and {{java}} from the same JVM does not understand it been incompatible
for itself. Although version in forked JVM is totally fine and understands the
the classes compiled by {{javac}} because {{javac}} and forked JVM start with
the same option {{--enable-preview}}.
It is the same situation as if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
(in bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicated change and still questionary.
was (Author: tibor17):
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different {{major version}} (in bytecode
of *.class files) than the version of Java runtime supports in Maven, this JRE
fails because Java in Maven does not understand the bytecode. So, it is curious
that the same JVM ({{javac}}) produced two major versions depending on JVM
option and {{java}} from the same JVM does not understand it been incompatible
for itself. Although version in forked JVM is totally fine and understands the
the classes compiled by {{javac}} because {{javac}} and forked JVM start with
the same option {{--enable-preview}}.
It is the same as if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
(in bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicated change and still questionary.
> surefire/failsafe fails with --enable-preview in java 12
>
>
> Key: SUREFIRE-1652
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1652
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Krzysztof Krason
>Assignee: Tibor Digana
>Priority: Blocker
>
> Minimal example: [https://github.com/krzyk/lombok-jdk10-example]
>
> When I run the build `mvn clean verify` in the above repository I get
> following error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test)
> on project lombok-jdk10: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed:
> java.lang.UnsupportedClassVersionError: Preview features are not enabled for
> com/kirela/lombok/BarTest (class file version 56.65535). Try running with
> '--enable-preview' -> [Help 1]
>
> Tests work when I remove `--enable-preview` from compiler OR when I remove
> "forkCount" from surefire (and failsafe) configuration.
> As I understand argLine property should be used in all forks, but appears to
> be ignored, there is no difference if I use it as a property or as a
> configuration paramater in surefire/failsafe.
>
> This bug makes using Java 12 with preview features unusable with
> surefire/failsafe.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[
https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822409#comment-16822409
]
Tibor Digana edited comment on SUREFIRE-1652 at 4/20/19 10:54 AM:
--
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different {{major version}} (in bytecode
of *.class files) than the version of Java runtime supports in Maven, this JRE
fails because Java in Maven does not understand the bytecode. So, it is curious
that the same JVM ({{javac}}) produced two major versions depending on JVM
option and {{java}} from the same JVM does not understand it been incompatible
for itself. Although version in forked JVM is totally fine and understands the
the classes compiled by {{javac}} because {{javac}} and forked JVM start with
the same option {{--enable-preview}}.
It is the same as if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
(in bytecode) than the JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicated change and still questionary.
was (Author: tibor17):
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different version than the version of Java
runtime in Maven, this fails because Java in Maven does not understand it.
Although version in forked JVM is totally fine and understands the the classes
compiled by {{javac}} because {{javac}} and forked JVM start with the same
option {{--enable-preview}}.
It is the same sa if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
than JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicate change and still questionary.
> surefire/failsafe fails with --enable-preview in java 12
>
>
> Key: SUREFIRE-1652
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1652
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Krzysztof Krason
>Assignee: Tibor Digana
>Priority: Blocker
>
> Minimal example: [https://github.com/krzyk/lombok-jdk10-example]
>
> When I run the build `mvn clean verify` in the above repository I get
> following error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test)
> on project lombok-jdk10: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed:
> java.lang.UnsupportedClassVersionError: Preview features are not enabled for
> com/kirela/lombok/BarTest (class file version 56.65535). Try running with
> '--enable-preview' -> [Help 1]
>
> Tests work when I remove `--enable-preview` from compiler OR when I remove
> "forkCount" from surefire (and failsafe) configuration.
> As I understand argLine property should be used in all forks, but appears to
> be ignored, there is no difference if I use it as a property or as a
> configuration paramater in surefire/failsafe.
>
> This bug makes using Java 12 with preview features unusable with
> surefire/failsafe.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[
https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822409#comment-16822409
]
Tibor Digana commented on SUREFIRE-1652:
[~krzyk]
> I don't understand why `argLine` doesn't work in this case?
+explanation:+
The {{argLine}} does what it has to do without any issue.
The plugin runs JUnit filter which finally selects relevant classes to run in
one or multiple JVMs.
So the JUnit engine runs twice. Once in plugin JVM, and second in the forked
JVM.
Due to the classes are compiled with different version than the version of Java
runtime in Maven, this fails because Java in Maven does not understand it.
Although version in forked JVM is totally fine and understands the the classes
compiled by {{javac}} because {{javac}} and forked JVM start with the same
option {{--enable-preview}}.
It is the same sa if you compiled your sources with Java 12 by
{{maven-compiler-plugin}} using the toolchain and run the whole Maven build
with Java 11. So the classes would be compiled with higher {{major version}}
than JRE could understand in Maven process.
We have a wish to rework providers and perform the filtering inside of the
forked JVM but this is very compilicate change and still questionary.
> surefire/failsafe fails with --enable-preview in java 12
>
>
> Key: SUREFIRE-1652
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1652
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Krzysztof Krason
>Assignee: Tibor Digana
>Priority: Blocker
>
> Minimal example: [https://github.com/krzyk/lombok-jdk10-example]
>
> When I run the build `mvn clean verify` in the above repository I get
> following error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test)
> on project lombok-jdk10: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed:
> java.lang.UnsupportedClassVersionError: Preview features are not enabled for
> com/kirela/lombok/BarTest (class file version 56.65535). Try running with
> '--enable-preview' -> [Help 1]
>
> Tests work when I remove `--enable-preview` from compiler OR when I remove
> "forkCount" from surefire (and failsafe) configuration.
> As I understand argLine property should be used in all forks, but appears to
> be ignored, there is no difference if I use it as a property or as a
> configuration paramater in surefire/failsafe.
>
> This bug makes using Java 12 with preview features unusable with
> surefire/failsafe.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[ https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822380#comment-16822380 ] Krzysztof Krason edited comment on SUREFIRE-1652 at 4/20/19 6:44 AM: - [~tibor17] Sorry I forgot to add the tests there - now they are there. OK, with `MAVEN_OPTS=--enable-preview` it works, but I think this is a similar case as with the Java 9 modules. This is not a bug, but a design decision that was made and going forward we (those that use Java) should adapt to that new situation. Aside from the Java bug (or feature) - I don't understand why `argLine` doesn't work in this case? It looks like `argLine` is not passed to forked JVMs, which looks like a real bug on surefire/failsafe side. was (Author: krzyk): [~tibor17] Sorry I forgot to add the tests there. OK, with `MAVEN_OPTS=--enable-preview` it works, but I think this is a similar case as with the Java 9 modules. This is not a bug, but a design decision that was made and going forward we (those that use Java) should adapt to that new situation. Aside from the Java bug (or feature) - I don't understand why `argLine` doesn't work in this case? It looks like `argLine` is not passed to forked JVMs, which looks like a real bug on surefire/failsafe side. > surefire/failsafe fails with --enable-preview in java 12 > > > Key: SUREFIRE-1652 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1652 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krzysztof Krason >Assignee: Tibor Digana >Priority: Blocker > > Minimal example: [https://github.com/krzyk/lombok-jdk10-example] > > When I run the build `mvn clean verify` in the above repository I get > following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) > on project lombok-jdk10: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed: > java.lang.UnsupportedClassVersionError: Preview features are not enabled for > com/kirela/lombok/BarTest (class file version 56.65535). Try running with > '--enable-preview' -> [Help 1] > > Tests work when I remove `--enable-preview` from compiler OR when I remove > "forkCount" from surefire (and failsafe) configuration. > As I understand argLine property should be used in all forks, but appears to > be ignored, there is no difference if I use it as a property or as a > configuration paramater in surefire/failsafe. > > This bug makes using Java 12 with preview features unusable with > surefire/failsafe. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[ https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822380#comment-16822380 ] Krzysztof Krason commented on SUREFIRE-1652: [~tibor17] Sorry I forgot to add the tests there. OK, with `MAVEN_OPTS=--enable-preview` it works, but I think this is a similar case as with the Java 9 modules. This is not a bug, but a design decision that was made and going forward we (those that use Java) should adapt to that new situation. Aside from the Java bug (or feature) - I don't understand why `argLine` doesn't work in this case? It looks like `argLine` is not passed to forked JVMs, which looks like a real bug on surefire/failsafe side. > surefire/failsafe fails with --enable-preview in java 12 > > > Key: SUREFIRE-1652 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1652 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krzysztof Krason >Assignee: Tibor Digana >Priority: Blocker > > Minimal example: [https://github.com/krzyk/lombok-jdk10-example] > > When I run the build `mvn clean verify` in the above repository I get > following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) > on project lombok-jdk10: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed: > java.lang.UnsupportedClassVersionError: Preview features are not enabled for > com/kirela/lombok/BarTest (class file version 56.65535). Try running with > '--enable-preview' -> [Help 1] > > Tests work when I remove `--enable-preview` from compiler OR when I remove > "forkCount" from surefire (and failsafe) configuration. > As I understand argLine property should be used in all forks, but appears to > be ignored, there is no difference if I use it as a property or as a > configuration paramater in surefire/failsafe. > > This bug makes using Java 12 with preview features unusable with > surefire/failsafe. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
