[jira] [Commented] (MPH-152) Enhance console output of "evaluate" goal to indicate result
[
https://issues.apache.org/jira/browse/MPH-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504300#comment-16504300
]
Karl Heinz Marbaise commented on MPH-152:
-
The usage of evaluate related to output without creating a file is done in
MPH-144 which is part of the next release which is currently under VOTING on
dev list...
But about your point the evaluation status should be taken into account...which
sounds like a good idea...
> Enhance console output of "evaluate" goal to indicate result
>
>
> Key: MPH-152
> URL: https://issues.apache.org/jira/browse/MPH-152
> Project: Maven Help Plugin
> Issue Type: Improvement
> Components: evaluate
>Affects Versions: 3.0.1
>Reporter: Paul Benedict
>Priority: Minor
>
> I have two requirements for consideration:
> # Scripts should be able to easily get the resolution status.
> # Scripts should be able to easily get the resolved expression value.
> When evaluating an expression, the output does not have a good marker to help
> scripts identity the resolution. Current plugin behavior prints the value
> (practically buried among Maven's logging) or "null object or invalid
> expression" message.
> The {{-o}} option could be used, of course, but file creation is more
> overhead than necessary. But what is good about the {{-o}} option is that it
> prints a clear marker:
> {code:none}
> > mvn help:evaluate -Dexpression=settings.localRepository -Doutput=out.txt
> [INFO] Scanning for projects...
> . . .
> [INFO] Result of evaluation written to: c:\proj\out.txt{code}
> Can you consider something similar for the console?
> Example possible solutions:
> {code:none}
> > mvn help:evaluate -Dexpression=settings.localRepository
> [INFO] Scanning for projects...
> . . .
> [INFO] Result of evaluation: /home/joeuser/.m2/repository{code}
> And again:
> {code:none}
> > mvn help:evaluate -Dexpression=zzz
> [INFO] Scanning for projects...
> . . .
> [INFO] Result of evaluation: null{code}
> PS: If you think current behavior should be preserved, a new plugin option
> can be introduced. However, as [shown by this
> link|https://stackoverflow.com/questions/5916157/how-to-get-the-maven-local-repo-location],
> I think people have a difficult time clobbering together an answer to parse
> reliably. There are other examples on that site if you're interested. So I
> don't think any effort should be taken with introducing a new option. Just my
> 2 cents. Since the fragility already exists, just provide an "official"
> solution to remediate it.
> Thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-321) Problematic Java 9 modules are silently ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503945#comment-16503945
]
Hudson commented on MCOMPILER-321:
--
Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » master #26
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/master/26/
> Problematic Java 9 modules are silently ignored
> ---
>
> Key: MCOMPILER-321
> URL: https://issues.apache.org/jira/browse/MCOMPILER-321
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Marcel Kolsteren
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: maven-compiler-plugin-bug.zip
>
>
> Before the compilation starts, the compiler plugin prepares the module path
> and the class path. Unfortunately, this process is very lenient. If the
> plugin cannot find a module that is specified in the module-info file, it
> doesn't report this problem, and it just carries on. In the end, the compiler
> will give a "module not found", giving no clue about the root cause.
> As an example, I attached a simple maven project with a module info file that
> refers to an automatic module named {{jython-standalone}}. The dependencies
> contain a jar file {{jython-standalone-2.7.0.jar}}. That jar file contains no
> module information, and it would normally be resolvable as an automatic
> module. However, when building the project, the Java compiler fails with this
> error:
> {{module not found: jython.standalone}}
> The root cause of the error is that the jar file contains a class at top
> level, which is illegal for a module. So, the error message "module not
> found" is misleading.
> I think this is a bug, because the maven-compiler-plugin fails to perform its
> task of building a correct module path, but doesn't tell, and just carries
> on. Instead, it should stop, and give an informative error message.
> Relevant source code:
> * [https://github.com/apache/maven-compiler-plugin], class {{CompilerMojo}}
> * [https://github.com/codehaus-plexus/plexus-languages], class
> {{LocationManager}} and {{MainClassModuleNameExtractor}}
> *
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html]
> The {{MainClassModuleNameExtractor}} uses the {{ModuleFinder}} class of the
> JDK to find modules. I think that these two error situations should lead to
> an error and a clear description of possible causes:
> * {{ModuleFinder#findAll}} returns an empty set.
> * {{ModuleFinder#findAll}} results in a {{FindException}}. When this happens
> is well documented in the {{ModuleFinder#of}} method. This exception is
> currently swallowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-321) Problematic Java 9 modules are silently ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503872#comment-16503872
]
Hudson commented on MCOMPILER-321:
--
Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #4
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/4/
> Problematic Java 9 modules are silently ignored
> ---
>
> Key: MCOMPILER-321
> URL: https://issues.apache.org/jira/browse/MCOMPILER-321
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Marcel Kolsteren
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: maven-compiler-plugin-bug.zip
>
>
> Before the compilation starts, the compiler plugin prepares the module path
> and the class path. Unfortunately, this process is very lenient. If the
> plugin cannot find a module that is specified in the module-info file, it
> doesn't report this problem, and it just carries on. In the end, the compiler
> will give a "module not found", giving no clue about the root cause.
> As an example, I attached a simple maven project with a module info file that
> refers to an automatic module named {{jython-standalone}}. The dependencies
> contain a jar file {{jython-standalone-2.7.0.jar}}. That jar file contains no
> module information, and it would normally be resolvable as an automatic
> module. However, when building the project, the Java compiler fails with this
> error:
> {{module not found: jython.standalone}}
> The root cause of the error is that the jar file contains a class at top
> level, which is illegal for a module. So, the error message "module not
> found" is misleading.
> I think this is a bug, because the maven-compiler-plugin fails to perform its
> task of building a correct module path, but doesn't tell, and just carries
> on. Instead, it should stop, and give an informative error message.
> Relevant source code:
> * [https://github.com/apache/maven-compiler-plugin], class {{CompilerMojo}}
> * [https://github.com/codehaus-plexus/plexus-languages], class
> {{LocationManager}} and {{MainClassModuleNameExtractor}}
> *
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html]
> The {{MainClassModuleNameExtractor}} uses the {{ModuleFinder}} class of the
> JDK to find modules. I think that these two error situations should lead to
> an error and a clear description of possible causes:
> * {{ModuleFinder#findAll}} returns an empty set.
> * {{ModuleFinder#findAll}} results in a {{FindException}}. When this happens
> is well documented in the {{ModuleFinder#of}} method. This exception is
> currently swallowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-321) Problematic Java 9 modules are silently ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503814#comment-16503814
]
Hudson commented on MCOMPILER-321:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Problematic Java 9 modules are silently ignored
> ---
>
> Key: MCOMPILER-321
> URL: https://issues.apache.org/jira/browse/MCOMPILER-321
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Marcel Kolsteren
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: maven-compiler-plugin-bug.zip
>
>
> Before the compilation starts, the compiler plugin prepares the module path
> and the class path. Unfortunately, this process is very lenient. If the
> plugin cannot find a module that is specified in the module-info file, it
> doesn't report this problem, and it just carries on. In the end, the compiler
> will give a "module not found", giving no clue about the root cause.
> As an example, I attached a simple maven project with a module info file that
> refers to an automatic module named {{jython-standalone}}. The dependencies
> contain a jar file {{jython-standalone-2.7.0.jar}}. That jar file contains no
> module information, and it would normally be resolvable as an automatic
> module. However, when building the project, the Java compiler fails with this
> error:
> {{module not found: jython.standalone}}
> The root cause of the error is that the jar file contains a class at top
> level, which is illegal for a module. So, the error message "module not
> found" is misleading.
> I think this is a bug, because the maven-compiler-plugin fails to perform its
> task of building a correct module path, but doesn't tell, and just carries
> on. Instead, it should stop, and give an informative error message.
> Relevant source code:
> * [https://github.com/apache/maven-compiler-plugin], class {{CompilerMojo}}
> * [https://github.com/codehaus-plexus/plexus-languages], class
> {{LocationManager}} and {{MainClassModuleNameExtractor}}
> *
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html]
> The {{MainClassModuleNameExtractor}} uses the {{ModuleFinder}} class of the
> JDK to find modules. I think that these two error situations should lead to
> an error and a clear description of possible causes:
> * {{ModuleFinder#findAll}} returns an empty set.
> * {{ModuleFinder#findAll}} results in a {{FindException}}. When this happens
> is well documented in the {{ModuleFinder#of}} method. This exception is
> currently swallowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-311) NPE when --patch-module is used
[
https://issues.apache.org/jira/browse/MCOMPILER-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503813#comment-16503813
]
Hudson commented on MCOMPILER-311:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> NPE when --patch-module is used
> ---
>
> Key: MCOMPILER-311
> URL: https://issues.apache.org/jira/browse/MCOMPILER-311
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Java 10 in Windows 10
>Reporter: Zhihong Zhang
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
>
> When "--patch-module" argument is added to the compiler, the plugin always
> throws NullPointerException. For example,
> {code:xml}
>
> --patch-module
> java.xml.ws.annotation=jsr305-3.0.1.jar
>
> {code}
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1004)
> at
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> {code}
> The bug is caused by an unimplemented method in CompilerMOJO.java,
> {code:title=CompilerMOJO.java|borderStyle=solid}
> @Override
> protected Map getPathElements()
> {
> // TODO Auto-generated method stub
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-336) Dependency that should be on modulepath sometime put on classpath
[
https://issues.apache.org/jira/browse/MCOMPILER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503811#comment-16503811
]
Hudson commented on MCOMPILER-336:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Dependency that should be on modulepath sometime put on classpath
> -
>
> Key: MCOMPILER-336
> URL: https://issues.apache.org/jira/browse/MCOMPILER-336
> Project: Maven Compiler Plugin
> Issue Type: Task
>Affects Versions: 3.7.0
>Reporter: Martin Desruisseaux
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: module-vs-classpath.zip
>
>
> {{maven-compiler-plugin}} sometime puts modularized dependencies on the
> {{javac}} {{-classpath}} option instead than {{-modulepath}}, which cause
> compilation failure. A test case is attached. Step to reproduce:
> {noformat}
> cd module-vs-classpath
> cd a
> mvn install
> cd ../b
> mvn clean install
> mvn install
> {noformat}
> The last command fail with the following error message:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project b: Compilation failure
> [ERROR] module not found: test.a
> {noformat}
> Execution with the {{-X}} option shows that the {{test.a}} dependency is
> correctly declared in {{-modulepath}} when executing {{mvn clean install}},
> but is wrongly declared in {{-classpath}} when executing {{mvn install}}.
> A workaround is to remove the
> {{false}} option in
> the {{pom.xml}} files, or to execute {{touch src/main/java/module-info.java}}
> before {{mvn install}}. However the same error message occurs when attempting
> to execute {{mvn site}}, for which case I have found no workaround yet (note:
> the {{mvn site}} problem is not reproduced by the attached
> {{module-vs-classpath.zip}} file).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore
[
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503809#comment-16503809
]
Hudson commented on MNGSITE-332:
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
> Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this
> has to be changed into links to {{sha1}} and {{sha256}} instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-342) Unsupported class file major version 55
[
https://issues.apache.org/jira/browse/MCOMPILER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503812#comment-16503812
]
Hudson commented on MCOMPILER-342:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Unsupported class file major version 55
> ---
>
> Key: MCOMPILER-342
> URL: https://issues.apache.org/jira/browse/MCOMPILER-342
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Mincong Huang
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 3.7.1
>
> Attachments: log.txt
>
>
> Maven compiler plugin does not support classes created by JDK 11 (major
> version 55). If you have classes created by JDK 11 in your classpath when
> using Maven Compiler, you've the following errors:
> {quote}
> Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project java-examples-dev-core: Execution
> default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed:
> Unsupported class file major version 55 -> [Help 1]
> {quote}
> See https://github.com/mincong-h/MCOMPILER-342 for reproduction
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-341) Compile module-info.java files located in test sources
[
https://issues.apache.org/jira/browse/MCOMPILER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503810#comment-16503810
]
Hudson commented on MCOMPILER-341:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Compile module-info.java files located in test sources
> --
>
> Key: MCOMPILER-341
> URL: https://issues.apache.org/jira/browse/MCOMPILER-341
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: Christian Stein
>Assignee: Robert Scholte
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.7.1
>
>
> Support compilation of projects with test sources containing modules – along
> with explicit module descriptors ({{module-info.java}} files).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-192) No error reporting with forked compiler when Compiler includes non java files
[
https://issues.apache.org/jira/browse/MCOMPILER-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503807#comment-16503807
]
Hudson commented on MCOMPILER-192:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> No error reporting with forked compiler when Compiler includes non java files
> -
>
> Key: MCOMPILER-192
> URL: https://issues.apache.org/jira/browse/MCOMPILER-192
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7
>Reporter: Trevor Baker
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.1
>
> Attachments: test2.zip
>
>
> I notice one of my builds had this in the maven-compiler-plugin configuration:
> {noformat}
> my/path/MyFile.inc
> {noformat}
> In 2.5.1, the inc file is excluded from the generated compiler file and the
> build is successful.
> In 3.0, the inc file is included in the generated compiler file and the build
> is not successful. There are no warnings or errors displayed.
> The CLI returnCode is 2 but there is no output to grab messages from. When I
> grab the generated compiler file and run by myself on the command line, I get
> this:
> {noformat}
> $ cmd.exe /X /C "C:\tools\jdk-1.6.0_33\bin\javac.exe
> @C:/Tools/cygwin/tmp/org.codehaus.plexus.compiler.javac.JavacCompiler3357522045371592375arguments"
> javac: invalid flag: C:/Users/me/project/src/java/my/path/MyFile.inc
> Usage: javac
> use -help for a list of possible options
> {noformat}
> I've removed the inc file from the compiler configuration, but the compiler
> plugin should handle more gracefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-332) Java 10 not supported
[
https://issues.apache.org/jira/browse/MCOMPILER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503806#comment-16503806
]
Hudson commented on MCOMPILER-332:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Java 10 not supported
> -
>
> Key: MCOMPILER-332
> URL: https://issues.apache.org/jira/browse/MCOMPILER-332
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 10, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
> Default locale: en_DK, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"
>Reporter: Troels Nørgaard
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
>
> Running on Java 10 on Mac OS X (Latest), compile and test-compile works at
> source/target/release level 9. However, setting the level to 10 causes an
> IllegalArgumentException from ASM, even if no local type inference code is
> present.
> Exception:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.:
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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)
> 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)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.parse(AsmModuleInfoParser.java:80)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.getModuleDescriptor(AsmModuleInfoParser.java:54)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:83)
> at
> org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:281)
> at
> org.apache.maven.plugin.compi
[jira] [Commented] (MCOMPILER-338) Build Issue based on MCOMPILER-192 IT
[
https://issues.apache.org/jira/browse/MCOMPILER-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503808#comment-16503808
]
Hudson commented on MCOMPILER-338:
--
Build failed in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-321 #3
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-321/3/
> Build Issue based on MCOMPILER-192 IT
> -
>
> Key: MCOMPILER-338
> URL: https://issues.apache.org/jira/browse/MCOMPILER-338
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.7.1
>
>
> Currently the master is blocked by not working IT {{MCOMPILER-192}} which
> fails.
> The issue is related to the differences of platform/os which results in
> failing the {{verify.groovy}} which was originally implemented for one
> platform but based on our intention to build on different platforms and JDK's
> which is really needed this fails.
> The things which needed to be done:
> * Upgrade surefire.version to 2.21.0 (to work in JDK 10)
> * MCOMPILER-197/invoker.properties
> ** We need to limit the run to 1.6, 1.7, 1.8 cause openjpa has no version
> which woks for JDK 9 / 10
> * src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java
> ** Need to change the source/target to have 6 instead of 5 cause JDK9/JDK10
> do not support source/target 5 anymore.
> ** I think we should change this setup and find a better way.
> * groovy-project-with-new-plexus-compiler
> ** Needed run only for 1.6, 1.7 and 1.8
> * MCOMPILER-192/verify.groovy
> ** Had to limit the comparison to particular areas of the output
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MPH-152) Enhance console output of "evaluate" goal to indicate result
Paul Benedict created MPH-152:
-
Summary: Enhance console output of "evaluate" goal to indicate
result
Key: MPH-152
URL: https://issues.apache.org/jira/browse/MPH-152
Project: Maven Help Plugin
Issue Type: Improvement
Components: evaluate
Affects Versions: 3.0.1
Reporter: Paul Benedict
I have two requirements for consideration:
# Scripts should be able to easily get the resolution status.
# Scripts should be able to easily get the resolved expression value.
When evaluating an expression, the output does not have a good marker to help
scripts identity the resolution. Current plugin behavior prints the value
(practically buried among Maven's logging) or "null object or invalid
expression" message.
The {{-o}} option could be used, of course, but file creation is more overhead
than necessary. But what is good about the {{-o}} option is that it prints a
clear marker:
{code:none}
> mvn help:evaluate -Dexpression=settings.localRepository -Doutput=out.txt
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation written to: c:\proj\out.txt{code}
Can you consider something similar for the console?
Example possible solutions:
{code:none}
> mvn help:evaluate -Dexpression=settings.localRepository
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation: /home/joeuser/.m2/repository{code}
And again:
{code:none}
> mvn help:evaluate -Dexpression=zzz
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation: null{code}
PS: If you think current behavior should be preserved, a new plugin option can
be introduced. However, as [shown by this
link|https://stackoverflow.com/questions/5916157/how-to-get-the-maven-local-repo-location],
I think people have a difficult time clobbering together an answer to parse
reliably. There are other examples on that site if you're interested. So I
don't think any effort should be taken with introducing a new option. Just my 2
cents. Since the fragility already exists, just provide an "official" solution
to remediate it.
Thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6422) Maven by default does not check checksums; Maven lacks reproducible builds capability
[
https://issues.apache.org/jira/browse/MNG-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503493#comment-16503493
]
Karl Heinz Marbaise commented on MNG-6422:
--
First there have to be warnings in your build about non matching checksums or
failures to download them...which is the first hint...Apart from that I would
recommend to change your checksum policy to fail in cases of wrong checksums
etc...via {{settings.xml}} file See here:
https://maven.apache.org/settings.html#repositories
> Maven by default does not check checksums; Maven lacks reproducible builds
> capability
> -
>
> Key: MNG-6422
> URL: https://issues.apache.org/jira/browse/MNG-6422
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Martin Vysny
>Priority: Major
>
> Maven by default does not check checksums of downloaded jar files. That leads
> to ridiculous situations like for example when a misconfigured Artifactory
> instance provides HTML directory listing instead of an actual jar file
> (because of incorrect path or access denied or other reason). Maven should
> reject such jar file (since it can't match the check sum), but instead it
> happily stores it into the local repository and then later fails that it's
> not a valid zip file.
> This issue exposes something even worse - you actually can't have
> reproducible builds with Maven since the reproducibility of the build depends
> on whatever you have in your local .m2 repository. So for example the build
> fails for me (since my local .m2 is populated by borked jar files which are
> really html files), but it succeeds for my colleagues (simply because they
> populated their local .m2 repo at different time and they have proper actual
> jar files).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-528) Invalid 'expires' attribute
[
https://issues.apache.org/jira/browse/MJAVADOC-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roberto Benedetti updated MJAVADOC-528:
---
Description:
When detectLinks is enabled and the plugin checks if the url is valid, warnings
like this
{code:java}
Invalid cookie header: "Set-Cookie: logged_in=no; domain=.github.com; path=/;
expires=Sun, 06 Jun 2038 14:02:43 -; secure; HttpOnly". Invalid 'expires'
attribute: Sun, 06 Jun 2038 14:02:43 -
{code}
may appear.
Previous warning was due to {{com.google.code.gson:gson:jar:2.5}} dependency
and is raised by HttpClient which does not expect 'expires' values compliant to
RFC 6265.
The attachment is a patch which makes HttpClient ignore cookies. Maybe a
better solution would be upgrading to the latest HttpComponents API which
supports RFC 6265.
was:
When detectLinks is enabled and the plugin checks if the url is valid, warnings
like this
{code:java}
Invalid cookie header: "Set-Cookie: logged_in=no; domain=.github.com; path=/;
expires=Sun, 06 Jun 2038 14:02:43 -; secure; HttpOnly". Invalid 'expires'
attribute: Sun, 06 Jun 2038 14:02:43 -
{code}
may appear.
The warning is raised by HttpClient which does not expect 'expires' values
compliant to RFC 6265.
The attachment is a patch which makes HttpClient ignore cookies. Maybe a better
solution would be upgrading to the latest HttpComponents API which supports RFC
6265.
> Invalid 'expires' attribute
> ---
>
> Key: MJAVADOC-528
> URL: https://issues.apache.org/jira/browse/MJAVADOC-528
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
>Reporter: Roberto Benedetti
>Priority: Major
> Labels: detectLinks
> Attachments: cookie.patch
>
>
> When detectLinks is enabled and the plugin checks if the url is valid,
> warnings like this
> {code:java}
> Invalid cookie header: "Set-Cookie: logged_in=no; domain=.github.com; path=/;
> expires=Sun, 06 Jun 2038 14:02:43 -; secure; HttpOnly". Invalid 'expires'
> attribute: Sun, 06 Jun 2038 14:02:43 -
> {code}
> may appear.
> Previous warning was due to {{com.google.code.gson:gson:jar:2.5}} dependency
> and is raised by HttpClient which does not expect 'expires' values compliant
> to RFC 6265.
> The attachment is a patch which makes HttpClient ignore cookies. Maybe a
> better solution would be upgrading to the latest HttpComponents API which
> supports RFC 6265.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-528) Invalid 'expires' attribute
Roberto Benedetti created MJAVADOC-528:
--
Summary: Invalid 'expires' attribute
Key: MJAVADOC-528
URL: https://issues.apache.org/jira/browse/MJAVADOC-528
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.1
Reporter: Roberto Benedetti
Attachments: cookie.patch
When detectLinks is enabled and the plugin checks if the url is valid, warnings
like this
{code:java}
Invalid cookie header: "Set-Cookie: logged_in=no; domain=.github.com; path=/;
expires=Sun, 06 Jun 2038 14:02:43 -; secure; HttpOnly". Invalid 'expires'
attribute: Sun, 06 Jun 2038 14:02:43 -
{code}
may appear.
The warning is raised by HttpClient which does not expect 'expires' values
compliant to RFC 6265.
The attachment is a patch which makes HttpClient ignore cookies. Maybe a better
solution would be upgrading to the latest HttpComponents API which supports RFC
6265.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-527) detectLinks may pass invalid urls to javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roberto Benedetti updated MJAVADOC-527: --- Description: The url of artifact com.sun.mail:mailapi:1.5.5 is [http://javamail.java.net/mailapi], so the plugin tests if [http://javamail.java.net/mailapi/apidocs/package-list] is valid. That url redirects to [https://javaee.github.io/javamail/] which is JavaMail home page, so the plugin thinks the url is valid and passes it to javadoc. javadoc warns about invalid link. Maybe checking if the effective url is still "package-list" would be safer. was: The url of artifact com.sun.mail:mailapi:1.5.5 is http://javamail.java.net/mailapi, so the plugin tests if http://javamail.java.net/mailapi/apidocs/package-list is valid. That url redirects to https://javaee.github.io/javamail/ which is JavaMail home page, so the plugin thinks the url is valid and passes it to javadoc. javadoc warns about wrong link. Maybe checking if the effective url is still "package-list" would be safer. > detectLinks may pass invalid urls to javadoc > > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Priority: Major > Labels: detectLinks > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-527) detectLinks may pass invalid urls to javadoc
Roberto Benedetti created MJAVADOC-527: -- Summary: detectLinks may pass invalid urls to javadoc Key: MJAVADOC-527 URL: https://issues.apache.org/jira/browse/MJAVADOC-527 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 3.0.1 Environment: Windows 10 JDK 8 Maven 3.5.2 Reporter: Roberto Benedetti The url of artifact com.sun.mail:mailapi:1.5.5 is http://javamail.java.net/mailapi, so the plugin tests if http://javamail.java.net/mailapi/apidocs/package-list is valid. That url redirects to https://javaee.github.io/javamail/ which is JavaMail home page, so the plugin thinks the url is valid and passes it to javadoc. javadoc warns about wrong link. Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6422) Maven by default does not check checksums; Maven lacks reproducible builds capability
Martin Vysny created MNG-6422: - Summary: Maven by default does not check checksums; Maven lacks reproducible builds capability Key: MNG-6422 URL: https://issues.apache.org/jira/browse/MNG-6422 Project: Maven Issue Type: Bug Affects Versions: 3.5.0 Reporter: Martin Vysny Maven by default does not check checksums of downloaded jar files. That leads to ridiculous situations like for example when a misconfigured Artifactory instance provides HTML directory listing instead of an actual jar file (because of incorrect path or access denied or other reason). Maven should reject such jar file (since it can't match the check sum), but instead it happily stores it into the local repository and then later fails that it's not a valid zip file. This issue exposes something even worse - you actually can't have reproducible builds with Maven since the reproducibility of the build depends on whatever you have in your local .m2 repository. So for example the build fails for me (since my local .m2 is populated by borked jar files which are really html files), but it succeeds for my colleagues (simply because they populated their local .m2 repo at different time and they have proper actual jar files). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
