[jira] [Closed] (DOXIASITETOOLS-179) Report error line and column from Velocity runtime exception
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed DOXIASITETOOLS-179.
Resolution: Fixed
Assignee: Hervé Boutemy
fixed in
https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git=commit=053dcf9db0046bacfe5b1b47a4842011de7128cf
> Report error line and column from Velocity runtime exception
>
>
> Key: DOXIASITETOOLS-179
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-179
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.7, 1.8
>Reporter: Jan Krupička
>Assignee: Hervé Boutemy
>Priority: Major
> Labels: usability
> Fix For: 1.8.1
>
> Attachments: velocity-exception-site.zip
>
>
> I have a site page {{index.apt.vm}} which is a Velocity template:
> {noformat}
> My best index page
> #set ($text = 'text')
> #set ($text = $text.charAt(-1))
> {noformat}
> When building maven site, this template fails (of course) with a runtime
> exception. Also the maven build fails (good) with the following output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> test-project: Error getting a parser for 'My/site/path/index.apt.vm'
> {noformat}
> This output is not much helpful and is a little misleading. Velocity throws
> an exception with parsing error line and column. It would be nice to see this
> in maven error message so it is easy to see where the problem is.
> I can see full stack trace with maven debug build (-X) but I would expect
> this type of error to be reported in normal build.
> Related class and method:
> {{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)}}
> Velocity method that throws useful exception with error description
> (line/column)
> {{org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)}}
> Velocity exception to catch and use:
> {{org.apache.velocity.exception.ParseErrorException}}
> Full stacktrace from debug output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> org.apache.velocity.exception.MethodInvocationException: Invocation of method
> 'charAt' in class java.lang.String threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> -1 at d:\projects\test\tmp\test\src\site\apt\index.apt.vm[line 3, column 23]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at org.apache.velocity.Template.merge(Template.java:356)
> at org.apache.velocity.Template.merge(Template.java:260)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132)
> 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
>
[jira] [Commented] (MPIR-366) Drop Maven 2 support
[ https://issues.apache.org/jira/browse/MPIR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440005#comment-16440005 ] Hudson commented on MPIR-366: - Build succeeded in Jenkins: Maven TLP » maven-project-info-reports-plugin » MPIR-366 #25 See https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-366/25/ > Drop Maven 2 support > > > Key: MPIR-366 > URL: https://issues.apache.org/jira/browse/MPIR-366 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1502) Forking fails on OS/X
[
https://issues.apache.org/jira/browse/SUREFIRE-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439918#comment-16439918
]
Tibor Digana commented on SUREFIRE-1502:
[~Grim]
Create a separate jira ticket. I executed your project but it is not related to
this issue. Your problem has different root cause. I will explain everything in
new ticket but not here. Thx.
> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp,
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_
> on version 2.21.0 as well as 2.20.1. It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1148)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (MASSEMBLY-850) Class-path ignores runtime dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439877#comment-16439877 ] Leonid Rozenblyum commented on MASSEMBLY-850: - The fix for MASSEMBLY-675 also fixed this ticket for me > Class-path ignores runtime dependencies > --- > > Key: MASSEMBLY-850 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-850 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Ondrej Par >Priority: Major > > I add runtime-scoped dependencies using custom assembly descriptor and use > true in POM. Runtime dependencies are correctly > added to the JAR, and classpath is added to the manifest, however, it only > contains compile-scoped dependencies. > This worked correctly with maven 2 and assembly:attached goal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439879#comment-16439879 ] Leonid Rozenblyum commented on MASSEMBLY-675: - Could a new release of maven-assembly-plugin be created with the fix (since it fixes actually 2 problems)? I'd appreciate that. Thanks! [~gboue] > Maven Assembly packaging wildcard-excluded dependencies > --- > > Key: MASSEMBLY-675 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-675 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Apache Maven 3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac" >Reporter: Frank Wilson >Assignee: Guillaume Boué >Priority: Major > Fix For: 3.1.1 > > Attachments: massembly-675.zip > > > Version 2.4 ignores wildcard exclusions in POM dependencies > Example (perhaps contrived - but easy to setup): > When a pom declares a dependency such as closure-compiler and for some reason > we do not want to pull its dependencies in we could declare this in our POM, > without having to know what those dependencies are: > > > com.google.javascript > closure-compiler > v20131014 > > > * > * > > > > > This is a valid use of the exclusion feature as per [Maven > Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies], > [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about > wildcards were > [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5] > in Git about 10 days ago > Here is the assembly descriptor: > > bin > > dir > > false > > > > > We expect to only find the current project artifact and the closure-compiler > JAR in our directory assembly. However the assembly plugin ignores our POM > directive and includes the closure-compilers dependencies anyway! > Steps to reproduce are: > $ unzip massembly-675.zip > $ cd massembly-675 > $ mvn clean install > $ ls target/massembly-675-1-bin > args4j-2.0.16.jar json-20090211.jar > protobuf-java-2.4.1.jar > closure-compiler-v20131014.jar jsr305-1.3.9.jar > guava-15.0.jar massembly-675-1.jar > *Notice that the excluded jars are included in the assembly* > I would expect to only see the following JARs. > * closure-compiler-v20131014.jar > * massembly-675-1.jar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439873#comment-16439873 ] Leonid Rozenblyum commented on MASSEMBLY-675: - Great fix! For me it also fixed https://issues.apache.org/jira/browse/MASSEMBLY-850 > Maven Assembly packaging wildcard-excluded dependencies > --- > > Key: MASSEMBLY-675 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-675 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Apache Maven 3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac" >Reporter: Frank Wilson >Assignee: Guillaume Boué >Priority: Major > Fix For: 3.1.1 > > Attachments: massembly-675.zip > > > Version 2.4 ignores wildcard exclusions in POM dependencies > Example (perhaps contrived - but easy to setup): > When a pom declares a dependency such as closure-compiler and for some reason > we do not want to pull its dependencies in we could declare this in our POM, > without having to know what those dependencies are: > > > com.google.javascript > closure-compiler > v20131014 > > > * > * > > > > > This is a valid use of the exclusion feature as per [Maven > Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies], > [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about > wildcards were > [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5] > in Git about 10 days ago > Here is the assembly descriptor: > > bin > > dir > > false > > > > > We expect to only find the current project artifact and the closure-compiler > JAR in our directory assembly. However the assembly plugin ignores our POM > directive and includes the closure-compilers dependencies anyway! > Steps to reproduce are: > $ unzip massembly-675.zip > $ cd massembly-675 > $ mvn clean install > $ ls target/massembly-675-1-bin > args4j-2.0.16.jar json-20090211.jar > protobuf-java-2.4.1.jar > closure-compiler-v20131014.jar jsr305-1.3.9.jar > guava-15.0.jar massembly-675-1.jar > *Notice that the excluded jars are included in the assembly* > I would expect to only see the following JARs. > * closure-compiler-v20131014.jar > * massembly-675-1.jar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439760#comment-16439760
]
Robert Scholte commented on MNG-6391:
-
I don't think the issue is about not understanding the reactor build. It simply
looks awkard that the final entry has a version number, even if it is similar
to the module before.
I assume we all agree the first one makes sense. The *only* reason the last one
is printed with a version here is because the list of modules might be long,
which means you need to scroll to the first entry. It has nothing to do with
the context of the module, but it does look like that, as if there is something
special with this module.
Adding a version to every line makes would be correct but makes it much harder
to read.
There's another option: remove it from the last line and accept that with large
projects one need to scroll a little bit. But at least there's no confusion.
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9
[
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439752#comment-16439752
]
Robert Scholte commented on MCOMPILER-339:
--
My first impression was: duplicate of MCOMPILER-270: reducing release to
source/target is dangerous, because when using {{release}} you are ensured that
you're only using code compatible with version N. By translating it to
source/target automatically you will loose this.
The difference in this case is the compilerVersion, but I still have my doubts.
I would try to solve this with a jdk 9 activated profile setting the release
value.
> Skip --release flag if compilerVersion is lower than 1.9
>
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the
> parent-pom.
> However, one submodule must be compiled and run with java8. I had hoped to
> get this working, by setting:
> {noformat}
>
> 8
> 1.8
> 1.8
> 1.8
>
> {noformat}
>
> but it will fail with
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag:
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
> (JavacTool.java:206)*11:53:45* at
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*
>at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
> (JavaxToolsCompiler.java:125)*11:53:45* at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:174)*11:53:45* at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1075)*11:53:45* at
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute
> (TestCompilerMojo.java:176)*11:53:45* at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)*11:53:45* at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)*11:53:45* at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)*11:53:45* at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:196)*11:53:45* at
> java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at
> java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run
> (FutureTask.java:266)*11:53:45* at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1149)*11:53:45* at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run
> (Thread.java:748)
> {noformat}
> If the release flag could only be enabled for compiler versions supporting it
> it would be easier to juggle the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-850) Class-path ignores runtime dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439523#comment-16439523 ] Leonid Rozenblyum commented on MASSEMBLY-850: - It's a pretty annoying bug. Is there any known workaround or possibility to force the maven-assembly-plugin use maven-jar-plugin generated manifest which is correctly including runtime dependencies? > Class-path ignores runtime dependencies > --- > > Key: MASSEMBLY-850 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-850 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Ondrej Par >Priority: Major > > I add runtime-scoped dependencies using custom assembly descriptor and use > true in POM. Runtime dependencies are correctly > added to the JAR, and classpath is added to the manifest, however, it only > contains compile-scoped dependencies. > This worked correctly with maven 2 and assembly:attached goal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-883) Transitive dependencies with scope provided are included with jar-with-dependencies descriptor
[
https://issues.apache.org/jira/browse/MASSEMBLY-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439439#comment-16439439
]
Francois Armand commented on MASSEMBLY-883:
---
As explained here:
[https://stackoverflow.com/questions/49784429/how-to-exclude-transitive-dependencies-with-scope-provided-with-maven-assembly-p]
I believe it's a bug. I now use maven-shade-plugin whose behavior is ok.
> Transitive dependencies with scope provided are included with
> jar-with-dependencies descriptor
> --
>
> Key: MASSEMBLY-883
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-883
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0
>Reporter: Francois Armand
>Priority: Major
>
> In the following case as shown by {{mvn dependency:tree}}, with the
> predifined descriptor {{jar-with-dependencies}}:
>
> {{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile}}
> {{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile}}
> {{[INFO] | | - net.minidev:accessors-smart:jar:1.1:compile}}
> {{[INFO] | - org.slf4j:slf4j-api:jar:1.7.16:provided}}
>
> {{json-path}}, {{json-smart}}, {{accessors-smart}} are included, as expected.
> {{But slf4j-api}} is also included in the resulting jar.
> Other direct dependencies with scope `provided` are correctly excluded from
> the final jar.
> If this is the intendented behavior, which is highly surprising, could you
> document it in the corresponding descriptor documentation
> ([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
> Could you also explain what descriptor would allow to achieve the desired
> behavior (or point to a resource explaining it, I wasn't able to find one).
> Thanks.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-882) ScmWagon has no way to work with GIT in binary mode
[ https://issues.apache.org/jira/browse/SCM-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439404#comment-16439404 ] Ilya Basin commented on SCM-882: [~michael-o] the test files are created on-the-fly by the test cases and committed during the preparation phase. Then the actual test starts. See WagonTestCase.testWagon() > ScmWagon has no way to work with GIT in binary mode > --- > > Key: SCM-882 > URL: https://issues.apache.org/jira/browse/SCM-882 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.9.5 >Reporter: Ilya Basin >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 1.9.6 > > > Msysgit will checkout wagon-scm test-resource with CRLF by default, breaking > the test. Need to clone with core.autocrlf=false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-881) ScmWagon has no way to work with SVN in binary mode
[ https://issues.apache.org/jira/browse/SCM-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439395#comment-16439395 ] Ilya Basin commented on SCM-881: [~michael-o] this patch does not cancel existing props. It prevents new automatic props. > ScmWagon has no way to work with SVN in binary mode > --- > > Key: SCM-881 > URL: https://issues.apache.org/jira/browse/SCM-881 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.9.5 >Reporter: Ilya Basin >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 1.9.6 > > > In some configurations svn will automatically add the svn:eol-style property > to newly added text files. ScmWagon needs to perform the add command without > adding automatic properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-882) ScmWagon has no way to work with GIT in binary mode
[
https://issues.apache.org/jira/browse/SCM-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439393#comment-16439393
]
Michael Osipov commented on SCM-882:
What test resources are you referring to? wagon-scm-test does not contain any
test resources. If you talk about the mangled Subversion repo on Windows, I
have set {{.gitattributes}} on those files last year. The change you proposed
does not correlate with the issue you have.
> ScmWagon has no way to work with GIT in binary mode
> ---
>
> Key: SCM-882
> URL: https://issues.apache.org/jira/browse/SCM-882
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> Msysgit will checkout wagon-scm test-resource with CRLF by default, breaking
> the test. Need to clone with core.autocrlf=false
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-881) ScmWagon has no way to work with SVN in binary mode
[
https://issues.apache.org/jira/browse/SCM-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439381#comment-16439381
]
Michael Osipov commented on SCM-881:
What is the purpose/real world user of/for this? The props are there to be
used, especially if someone has set {{application/octet-stream}} on specific
file types.
> ScmWagon has no way to work with SVN in binary mode
> ---
>
> Key: SCM-881
> URL: https://issues.apache.org/jira/browse/SCM-881
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> In some configurations svn will automatically add the svn:eol-style property
> to newly added text files. ScmWagon needs to perform the add command without
> adding automatic properties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439373#comment-16439373
]
Michael Osipov commented on MNG-6391:
-
The position {{Version:}} looks wrong to me. The build block is for build
times. I find it rather confusing having static information in a dynamic block.
I do also agree with Karl Heinz, in an aggregator project this won't work.
Please also do not modify {{BUILD SUCCESS}} as people might parse this line. It
seems to me that [~agrsbm] does not understand the reactor build order and
assumes it to be in the logical order of the parent POM which must not be true.
Maybe our docs aren't good enough, but I see virtually no benefit moving this
information.
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1502) Forking fails on OS/X
[
https://issues.apache.org/jira/browse/SUREFIRE-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439315#comment-16439315
]
Peter Rader edited comment on SUREFIRE-1502 at 4/16/18 11:38 AM:
-
Similar [problem on Windows (src2jar) but with exit code
1|https://github.com/enexusde/source2runnablejar/tree/test-updated-surefire-version]
. Maybe not a 100% duplicate .
was (Author: grim):
Similar [problem on Windows but with exit code
1|https://github.com/enexusde/source2runnablejar/tree/test-updated-surefire-version].
Maybe not a 100% duplicate .
> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp,
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_
> on version 2.21.0 as well as 2.20.1. It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1148)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>
[jira] [Commented] (SUREFIRE-1502) Forking fails on OS/X
[
https://issues.apache.org/jira/browse/SUREFIRE-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439315#comment-16439315
]
Peter Rader commented on SUREFIRE-1502:
---
Similar [problem on Windows but with exit code
1|https://github.com/enexusde/source2runnablejar/tree/test-updated-surefire-version].
Maybe not a 100% duplicate .
> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp,
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_
> on version 2.21.0 as well as 2.20.1. It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java
> -jar
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
> /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1148)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at 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)
>
[jira] [Updated] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9
[
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated MCOMPILER-339:
--
Description:
usecase: I have a build which is jdk10 by default, declared via the parent-pom.
However, one submodule must be compiled and run with java8. I had hoped to get
this working, by setting:
{noformat}
8
1.8
1.8
1.8
{noformat}
but it will fail with
{noformat}
Caused by: java.lang.IllegalArgumentException: invalid flag:
--release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
(JavacTool.java:206)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:156)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:107)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:64)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
(JavaxToolsCompiler.java:125)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
(JavacCompiler.java:174)*11:53:45* at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:1075)*11:53:45* at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute
(TestCompilerMojo.java:176)*11:53:45* at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)*11:53:45* at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)*11:53:45* at
java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at
java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run
(FutureTask.java:266)*11:53:45* at
java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)*11:53:45* at
java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run
(Thread.java:748)
{noformat}
If the release flag could only be enabled for compiler versions supporting it
it would be easier to juggle the build.
was:
usecase: I have a build which is jdk10 by default, declared via the parent-pom.
However, one submodule must be compiled and run with java8. I had hoped to get
this working, by setting:
{noformat}
8
1.8
1.8
1.8
{noformat}
but it will fail with
{noformat}
Caused by: java.lang.IllegalArgumentException: invalid flag:
--release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
(JavacTool.java:206)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:156)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:107)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:64)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
(JavaxToolsCompiler.java:125)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
(JavacCompiler.java:174)*11:53:45* at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:1075)*11:53:45* at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute
(TestCompilerMojo.java:176)*11:53:45* at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)*11:53:45* at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)*11:53:45* at
java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at
java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run
[jira] [Updated] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9
[
https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated MCOMPILER-339:
--
Description:
usecase: I have a build which is jdk10 by default, declared via the parent-pom.
However, one submodule must be compiled and run with java8. I had hoped to get
this working, by setting:
{noformat}
8
1.8
1.8
1.8
{noformat}
but it will fail with
{noformat}
Caused by: java.lang.IllegalArgumentException: invalid flag:
--release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
(JavacTool.java:206)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:156)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:107)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask
(JavacTool.java:64)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
(JavaxToolsCompiler.java:125)*11:53:45* at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
(JavacCompiler.java:174)*11:53:45* at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:1075)*11:53:45* at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute
(TestCompilerMojo.java:176)*11:53:45* at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)*11:53:45* at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)*11:53:45* at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)*11:53:45* at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)*11:53:45* at
java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at
java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run
(FutureTask.java:266)*11:53:45* at
java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)*11:53:45* at
java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run
(Thread.java:748)
{noformat}
> Skip --release flag if compilerVersion is lower than 1.9
>
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: David J. M. Karlsen
>Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the
> parent-pom.
> However, one submodule must be compiled and run with java8. I had hoped to
> get this working, by setting:
> {noformat}
>
> 8
> 1.8
> 1.8
> 1.8
>
> {noformat}
>
> but it will fail with
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag:
> --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions
> (JavacTool.java:206)*11:53:45* at
> com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45*
> at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45*
>at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
> (JavaxToolsCompiler.java:125)*11:53:45* at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:174)*11:53:45* at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1075)*11:53:45* at
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute
> (TestCompilerMojo.java:176)*11:53:45* at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)*11:53:45* at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)*11:53:45* at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)*11:53:45* at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)*11:53:45*
[jira] [Created] (MCOMPILER-339) Skip --release flag if compilerVersion is lower than 1.9
David J. M. Karlsen created MCOMPILER-339: - Summary: Skip --release flag if compilerVersion is lower than 1.9 Key: MCOMPILER-339 URL: https://issues.apache.org/jira/browse/MCOMPILER-339 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.7.0 Reporter: David J. M. Karlsen -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MENFORCER-301) banDuplicatePomDependencyVersions does not check managementDependencies
[
https://issues.apache.org/jira/browse/MENFORCER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439161#comment-16439161
]
ASF GitHub Bot commented on MENFORCER-301:
--
kudrevatykh opened a new pull request #33: MENFORCER-301 check
dependencyManagement
URL: https://github.com/apache/maven-enforcer/pull/33
really check dependencyManagement section
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> banDuplicatePomDependencyVersions does not check managementDependencies
> ---
>
> Key: MENFORCER-301
> URL: https://issues.apache.org/jira/browse/MENFORCER-301
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Alexander Kudrevatykh
>Priority: Major
>
> MENFORCER-152 added rule for ban duplicate depndencies, but
> dependencyManagement section does not checked correctly
> code {code:java} if ( model.getDependencyManagement() != null )
> {
> List managementDependencies = model.getDependencies();
> Map duplicateManagementDependencies =
> validateDependencies( managementDependencies );{code} should be written as
> {code}
> if ( model.getDependencyManagement() != null )
> {
> List managementDependencies =
> model.getDependencyManagement().getDependencies();
> Map duplicateManagementDependencies =
> validateDependencies( managementDependencies );{code}
> and same fix should be applied to {noformat}profiles{noformat} checking code
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] kudrevatykh opened a new pull request #33: MENFORCER-301 check dependencyManagement
kudrevatykh opened a new pull request #33: MENFORCER-301 check dependencyManagement URL: https://github.com/apache/maven-enforcer/pull/33 really check dependencyManagement section This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (MENFORCER-301) banDuplicatePomDependencyVersions does not check managementDependencies
[
https://issues.apache.org/jira/browse/MENFORCER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kudrevatykh updated MENFORCER-301:
Description:
MENFORCER-152 added rule for ban duplicate depndencies, but
dependencyManagement section does not checked correctly
code {code:java} if ( model.getDependencyManagement() != null )
{
List managementDependencies = model.getDependencies();
Map duplicateManagementDependencies =
validateDependencies( managementDependencies );{code} should be written as
{code}
if ( model.getDependencyManagement() != null )
{
List managementDependencies =
model.getDependencyManagement().getDependencies();
Map duplicateManagementDependencies =
validateDependencies( managementDependencies );{code}
and same fix should be applied to {noformat}profiles{noformat} checking code
was:MENFORCER-152 added rule for ban duplicate depndencies, but
dependencyManagement section does not checked correctly code \{code:java} if (
model.getDependencyManagement() != null ) \{ List
managementDependencies = model.getDependencies(); Map
duplicateManagementDependencies = validateDependencies( managementDependencies
);{code} should be written as \{code} if ( model.getDependencyManagement() !=
null ) \{ List managementDependencies =
model.getDependencyManagement().getDependencies(); Map
duplicateManagementDependencies = validateDependencies( managementDependencies
);{code} and same fix should be applied to \{noformat}profiles\{noformat}
checking code
> banDuplicatePomDependencyVersions does not check managementDependencies
> ---
>
> Key: MENFORCER-301
> URL: https://issues.apache.org/jira/browse/MENFORCER-301
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Alexander Kudrevatykh
>Priority: Major
>
> MENFORCER-152 added rule for ban duplicate depndencies, but
> dependencyManagement section does not checked correctly
> code {code:java} if ( model.getDependencyManagement() != null )
> {
> List managementDependencies = model.getDependencies();
> Map duplicateManagementDependencies =
> validateDependencies( managementDependencies );{code} should be written as
> {code}
> if ( model.getDependencyManagement() != null )
> {
> List managementDependencies =
> model.getDependencyManagement().getDependencies();
> Map duplicateManagementDependencies =
> validateDependencies( managementDependencies );{code}
> and same fix should be applied to {noformat}profiles{noformat} checking code
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-301) banDuplicatePomDependencyVersions does not check managementDependencies
Alexander Kudrevatykh created MENFORCER-301:
---
Summary: banDuplicatePomDependencyVersions does not check
managementDependencies
Key: MENFORCER-301
URL: https://issues.apache.org/jira/browse/MENFORCER-301
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0-M1
Reporter: Alexander Kudrevatykh
MENFORCER-152 added rule for ban duplicate depndencies, but
dependencyManagement section does not checked correctly code \{code:java} if (
model.getDependencyManagement() != null ) \{ List
managementDependencies = model.getDependencies(); Map
duplicateManagementDependencies = validateDependencies( managementDependencies
);{code} should be written as \{code} if ( model.getDependencyManagement() !=
null ) \{ List managementDependencies =
model.getDependencyManagement().getDependencies(); Map
duplicateManagementDependencies = validateDependencies( managementDependencies
);{code} and same fix should be applied to \{noformat}profiles\{noformat}
checking code
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-246) set filtering = true will make some excel file to be broken
[ https://issues.apache.org/jira/browse/MRESOURCES-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439091#comment-16439091 ] george commented on MRESOURCES-246: --- anyway, thanks for your apply~ > set filtering = true will make some excel file to be broken > --- > > Key: MRESOURCES-246 > URL: https://issues.apache.org/jira/browse/MRESOURCES-246 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.0.2 >Reporter: george >Assignee: Robert Scholte >Priority: Major > Attachments: QQ截图20180414171050.png, QQ截图20180414171103.png, > export.xlsx > > > while I set filtering = true, maven-resources-plugin will copy my excel file > to the directory, but the file is broken, can be opened, > after I set filtering = false, or comment this line of settings, the file is > ok, > I use maven-kotlin-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOURCES-246) set filtering = true will make some excel file to be broken
[ https://issues.apache.org/jira/browse/MRESOURCES-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439060#comment-16439060 ] Karl Heinz Marbaise commented on MRESOURCES-246: None of them cause it's intended behaviour. If you give filtering=true means filter everything. If you don't want to filter particular files you have to exclude them or define them accordingly or better go with the suggestion I made with different directories. > set filtering = true will make some excel file to be broken > --- > > Key: MRESOURCES-246 > URL: https://issues.apache.org/jira/browse/MRESOURCES-246 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.0.2 >Reporter: george >Assignee: Robert Scholte >Priority: Major > Attachments: QQ截图20180414171050.png, QQ截图20180414171103.png, > export.xlsx > > > while I set filtering = true, maven-resources-plugin will copy my excel file > to the directory, but the file is broken, can be opened, > after I set filtering = false, or comment this line of settings, the file is > ok, > I use maven-kotlin-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOURCES-246) set filtering = true will make some excel file to be broken
[ https://issues.apache.org/jira/browse/MRESOURCES-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439059#comment-16439059 ] george commented on MRESOURCES-246: --- thanks for your comment, I now just copy all files to output directory, but, is this a bug or a problem? > set filtering = true will make some excel file to be broken > --- > > Key: MRESOURCES-246 > URL: https://issues.apache.org/jira/browse/MRESOURCES-246 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.0.2 >Reporter: george >Assignee: Robert Scholte >Priority: Major > Attachments: QQ截图20180414171050.png, QQ截图20180414171103.png, > export.xlsx > > > while I set filtering = true, maven-resources-plugin will copy my excel file > to the directory, but the file is broken, can be opened, > after I set filtering = false, or comment this line of settings, the file is > ok, > I use maven-kotlin-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-721) Upgrade maven-shared-utils to 3.2.1
Karl Heinz Marbaise created MSHARED-721: --- Summary: Upgrade maven-shared-utils to 3.2.1 Key: MSHARED-721 URL: https://issues.apache.org/jira/browse/MSHARED-721 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-archiver Affects Versions: maven-archiver-3.2.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-archiver-3.2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-720) Upgrade mave-surefire/failsafe-plugin 2.21.0
[ https://issues.apache.org/jira/browse/MSHARED-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439052#comment-16439052 ] Hudson commented on MSHARED-720: Build unstable in Jenkins: Maven TLP » maven-archiver » MSHARED-720 #3 See https://builds.apache.org/job/maven-box/job/maven-archiver/job/MSHARED-720/3/ > Upgrade mave-surefire/failsafe-plugin 2.21.0 > > > Key: MSHARED-720 > URL: https://issues.apache.org/jira/browse/MSHARED-720 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-archiver >Affects Versions: maven-archiver-3.2.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: maven-archiver-3.2.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-720) Upgrade mave-surefire/failsafe-plugin 2.21.0
[ https://issues.apache.org/jira/browse/MSHARED-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439051#comment-16439051 ] Hudson commented on MSHARED-720: Build failed in Jenkins: Maven TLP » maven-archiver » MSHARED-720 #2 See https://builds.apache.org/job/maven-box/job/maven-archiver/job/MSHARED-720/2/ > Upgrade mave-surefire/failsafe-plugin 2.21.0 > > > Key: MSHARED-720 > URL: https://issues.apache.org/jira/browse/MSHARED-720 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-archiver >Affects Versions: maven-archiver-3.2.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: maven-archiver-3.2.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-720) Upgrade mave-surefire/failsafe-plugin 2.21.0
Karl Heinz Marbaise created MSHARED-720: --- Summary: Upgrade mave-surefire/failsafe-plugin 2.21.0 Key: MSHARED-720 URL: https://issues.apache.org/jira/browse/MSHARED-720 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-archiver Affects Versions: maven-archiver-3.2.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-archiver-3.2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DOXIASITETOOLS-179) Report error line and column from Velocity runtime exception
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated DOXIASITETOOLS-179:
-
Affects Version/s: (was: 1.6)
1.7
> Report error line and column from Velocity runtime exception
>
>
> Key: DOXIASITETOOLS-179
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-179
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.7, 1.8
>Reporter: Jan Krupička
>Priority: Major
> Labels: usability
> Fix For: 1.8.1
>
> Attachments: velocity-exception-site.zip
>
>
> I have a site page {{index.apt.vm}} which is a Velocity template:
> {noformat}
> My best index page
> #set ($text = 'text')
> #set ($text = $text.charAt(-1))
> {noformat}
> When building maven site, this template fails (of course) with a runtime
> exception. Also the maven build fails (good) with the following output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> test-project: Error getting a parser for 'My/site/path/index.apt.vm'
> {noformat}
> This output is not much helpful and is a little misleading. Velocity throws
> an exception with parsing error line and column. It would be nice to see this
> in maven error message so it is easy to see where the problem is.
> I can see full stack trace with maven debug build (-X) but I would expect
> this type of error to be reported in normal build.
> Related class and method:
> {{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)}}
> Velocity method that throws useful exception with error description
> (line/column)
> {{org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)}}
> Velocity exception to catch and use:
> {{org.apache.velocity.exception.ParseErrorException}}
> Full stacktrace from debug output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> org.apache.velocity.exception.MethodInvocationException: Invocation of method
> 'charAt' in class java.lang.String threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> -1 at d:\projects\test\tmp\test\src\site\apt\index.apt.vm[line 3, column 23]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at org.apache.velocity.Template.merge(Template.java:356)
> at org.apache.velocity.Template.merge(Template.java:260)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132)
> 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
>
[jira] [Updated] (DOXIASITETOOLS-179) Report error line and column from Velocity runtime exception
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated DOXIASITETOOLS-179:
-
Affects Version/s: 1.6
1.8
> Report error line and column from Velocity runtime exception
>
>
> Key: DOXIASITETOOLS-179
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-179
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6, 1.8
>Reporter: Jan Krupička
>Priority: Major
> Labels: usability
> Fix For: 1.8.1
>
> Attachments: velocity-exception-site.zip
>
>
> I have a site page {{index.apt.vm}} which is a Velocity template:
> {noformat}
> My best index page
> #set ($text = 'text')
> #set ($text = $text.charAt(-1))
> {noformat}
> When building maven site, this template fails (of course) with a runtime
> exception. Also the maven build fails (good) with the following output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> test-project: Error getting a parser for 'My/site/path/index.apt.vm'
> {noformat}
> This output is not much helpful and is a little misleading. Velocity throws
> an exception with parsing error line and column. It would be nice to see this
> in maven error message so it is easy to see where the problem is.
> I can see full stack trace with maven debug build (-X) but I would expect
> this type of error to be reported in normal build.
> Related class and method:
> {{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)}}
> Velocity method that throws useful exception with error description
> (line/column)
> {{org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)}}
> Velocity exception to catch and use:
> {{org.apache.velocity.exception.ParseErrorException}}
> Full stacktrace from debug output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> org.apache.velocity.exception.MethodInvocationException: Invocation of method
> 'charAt' in class java.lang.String threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> -1 at d:\projects\test\tmp\test\src\site\apt\index.apt.vm[line 3, column 23]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at org.apache.velocity.Template.merge(Template.java:356)
> at org.apache.velocity.Template.merge(Template.java:260)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132)
> 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
>
[jira] [Updated] (DOXIASITETOOLS-179) Report error line and column from Velocity runtime exception
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated DOXIASITETOOLS-179:
-
Fix Version/s: 1.8.1
> Report error line and column from Velocity runtime exception
>
>
> Key: DOXIASITETOOLS-179
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-179
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6, 1.8
>Reporter: Jan Krupička
>Priority: Major
> Labels: usability
> Fix For: 1.8.1
>
> Attachments: velocity-exception-site.zip
>
>
> I have a site page {{index.apt.vm}} which is a Velocity template:
> {noformat}
> My best index page
> #set ($text = 'text')
> #set ($text = $text.charAt(-1))
> {noformat}
> When building maven site, this template fails (of course) with a runtime
> exception. Also the maven build fails (good) with the following output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> test-project: Error getting a parser for 'My/site/path/index.apt.vm'
> {noformat}
> This output is not much helpful and is a little misleading. Velocity throws
> an exception with parsing error line and column. It would be nice to see this
> in maven error message so it is easy to see where the problem is.
> I can see full stack trace with maven debug build (-X) but I would expect
> this type of error to be reported in normal build.
> Related class and method:
> {{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)}}
> Velocity method that throws useful exception with error description
> (line/column)
> {{org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)}}
> Velocity exception to catch and use:
> {{org.apache.velocity.exception.ParseErrorException}}
> Full stacktrace from debug output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> org.apache.velocity.exception.MethodInvocationException: Invocation of method
> 'charAt' in class java.lang.String threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> -1 at d:\projects\test\tmp\test\src\site\apt\index.apt.vm[line 3, column 23]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at org.apache.velocity.Template.merge(Template.java:356)
> at org.apache.velocity.Template.merge(Template.java:260)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132)
> 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)
>
[jira] [Commented] (DOXIASITETOOLS-179) Report error line and column from Velocity runtime exception
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439017#comment-16439017
]
Hervé Boutemy commented on DOXIASITETOOLS-179:
--
ok, found the cause: with Velocity 1.5, Velocity displays error message in logs
before sending its VelocityException
{noformat}[ERROR] Method charAt threw exception for reference $text in template
C:\Users\mosipov\Downloads\velocity-exception-site\src\site\apt\index.apt.vm at
[20,17]{noformat}
Then the general exception handling algorithm did not try to get the info: it
was displayed.
With Velocity 1.7, this Velocity error log behaviour disappeared, which is IMHO
more consistent.
Then the exception handling is not sufficient any more...
I'll update the code tonight, since there is some cleanup to do around this old
code
> Report error line and column from Velocity runtime exception
>
>
> Key: DOXIASITETOOLS-179
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-179
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Reporter: Jan Krupička
>Priority: Major
> Labels: usability
> Attachments: velocity-exception-site.zip
>
>
> I have a site page {{index.apt.vm}} which is a Velocity template:
> {noformat}
> My best index page
> #set ($text = 'text')
> #set ($text = $text.charAt(-1))
> {noformat}
> When building maven site, this template fails (of course) with a runtime
> exception. Also the maven build fails (good) with the following output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> test-project: Error getting a parser for 'My/site/path/index.apt.vm'
> {noformat}
> This output is not much helpful and is a little misleading. Velocity throws
> an exception with parsing error line and column. It would be nice to see this
> in maven error message so it is easy to see where the problem is.
> I can see full stack trace with maven debug build (-X) but I would expect
> this type of error to be reported in normal build.
> Related class and method:
> {{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)}}
> Velocity method that throws useful exception with error description
> (line/column)
> {{org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)}}
> Velocity exception to catch and use:
> {{org.apache.velocity.exception.ParseErrorException}}
> Full stacktrace from debug output:
> {noformat}
> [ERROR] Error parsing My/site/path/index.apt.vm as a velocity template, using
> as text.
> org.apache.velocity.exception.MethodInvocationException: Invocation of method
> 'charAt' in class java.lang.String threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> -1 at d:\projects\test\tmp\test\src\site\apt\index.apt.vm[line 3, column 23]
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at org.apache.velocity.Template.merge(Template.java:356)
> at org.apache.velocity.Template.merge(Template.java:260)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:381)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
>
[jira] [Commented] (MNG-6394) ${revision} and parent.releativePath
[
https://issues.apache.org/jira/browse/MNG-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439016#comment-16439016
]
Dorian Vallant commented on MNG-6394:
-
I think so. I have configured flatten-maven-plugin in my parent-project's pom.
Do I have to configure it in child's pom too?
> ${revision} and parent.releativePath
>
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
>
> If the CI friendly ${revision} property is used it seems maven does not
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
> pom.xml
> child-project/
> pom.xml
> parent-project/pom.xml:
> ...
> my.group
> parentArtifact
> ${revision}
> pom
> ...
> child-project/pom.xml:
>
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f
> child-project/pom.xml clean install' all works fine as long as the parent
> project is present in the file system. But if you move the parent project to
> another place, build & install it to your local repository and then try to
> build the child project, maven tries to download the pom.xml of the parent
> project but does not replace ${revision}. So maven complains about a missing
> dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
