[jira] [Updated] (MINVOKER-223) postBuildHookScript must be executed even if the maven build fail
[ https://issues.apache.org/jira/browse/MINVOKER-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated MINVOKER-223: Description: In order to do some cleanup I need this script to executed even if the Maven build fail. Version <= 3.0.0 it's not the case. was: In order to do some cleanup I need this script to executed even if the Maven build fail. ATM it's not the case. > postBuildHookScript must be executed even if the maven build fail > - > > Key: MINVOKER-223 > URL: https://issues.apache.org/jira/browse/MINVOKER-223 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 3.0.1 > > > In order to do some cleanup I need this script to executed even if the Maven > build fail. > Version <= 3.0.0 it's not the case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MINVOKER-223) postBuildHookScript must be executed even if the maven build fail
Olivier Lamy (*$^¨%`£) created MINVOKER-223: --- Summary: postBuildHookScript must be executed even if the maven build fail Key: MINVOKER-223 URL: https://issues.apache.org/jira/browse/MINVOKER-223 Project: Maven Invoker Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Olivier Lamy (*$^¨%`£) Assignee: Olivier Lamy (*$^¨%`£) Fix For: 3.0.1 In order to do some cleanup I need this script to executed even if the Maven build fail. ATM it's not the case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059904#comment-16059904
]
Guillaume Boué edited comment on MANTRUN-200 at 6/22/17 9:06 PM:
-
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern. In any Mojo, doing
{code:java}
ServiceLoader.load(ScriptEngineFactory.class, classLoader).iterator().hasNext();
{code}
returns {{false}} when the {{classLoader}} used is the plugin class loader,
obtained with {{getClass().getClassLoader()}}. It is the same result of
{{false}} when using thread class loader.
However, when using the system class loader with
{{ClassLoader.getSystemClassLoader()}}, this call correctly returns {{true}},
which is strange because the plugin class loader should have the system class
loader as parent.
was (Author: gboue):
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern. In any Mojo, doing
{code:java}
ServiceLoader.load(ScriptEngineFactory.class, classLoader).iterator().hasNext();
{code}
returns {{false}} when the {{classLoader}} used is the plugin class loader,
obtained with {{getClass().getClassLoader()}}. It is the same result of
{{false}} when using thread class loader.
However, when using the system class loader with
{{ClassLoader.getSystemClassLoader()}}, this call correctly returns {{true}}.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any
[jira] [Comment Edited] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059904#comment-16059904
]
Guillaume Boué edited comment on MANTRUN-200 at 6/22/17 9:01 PM:
-
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern. In any Mojo, doing
{code:java}
ServiceLoader.load(ScriptEngineFactory.class, classLoader).iterator().hasNext();
{code}
returns {{false}} when the {{classLoader}} used is the plugin class loader,
obtained with {{getClass().getClassLoader()}}. It is the same result of
{{false}} when using thread class loader.
However, when using the system class loader with
{{ClassLoader.getSystemClassLoader()}}, this call correctly returns {{true}}.
was (Author: gboue):
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern. In any Mojo, doing
{code:java}
ServiceLoader.load(ScriptEngineFactory.class, classLoader).iterator().hasNext();
{code}
returns {{false}} when the {{classLoader}} used is the plugin class loader,
obtained with {{getClass().getClassLoader()}}.
However, when using the system class loader with
{{ClassLoader.getSystemClassLoader()}}, this call correctly returns {{true}}.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}},
[jira] [Comment Edited] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059904#comment-16059904
]
Guillaume Boué edited comment on MANTRUN-200 at 6/22/17 8:46 PM:
-
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern. In any Mojo, doing
{code:java}
ServiceLoader.load(ScriptEngineFactory.class, classLoader).iterator().hasNext();
{code}
returns {{false}} when the {{classLoader}} used is the plugin class loader,
obtained with {{getClass().getClassLoader()}}.
However, when using the system class loader with
{{ClassLoader.getSystemClassLoader()}}, this call correctly returns {{true}}.
was (Author: gboue):
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-231) Reactor Module Convergence doesn't work when relativePath is set
[
https://issues.apache.org/jira/browse/MENFORCER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-231:
---
Fix Version/s: (was: 3.0.0)
3.0.1
> Reactor Module Convergence doesn't work when relativePath is set
>
>
> Key: MENFORCER-231
> URL: https://issues.apache.org/jira/browse/MENFORCER-231
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
>Reporter: Daniel Roig
> Fix For: 3.0.1
>
> Attachments: menforcer-231.zip
>
>
> When setting version to X in the root pom of a multi-module build and version
> Y in a child pom and the child pom specifies a correct {{}} tag
> in the parent section of the child pom, Maven will not fail the build.
> I tried invoking {{mvn validate}} from the root and it reported that the
> build succeeded. However, if I remove the {{}} from the parent
> section, the enforcer rule correctly reports that the module build is
> incoherent.
> Moreover, if I invoke {{mvn -pl :sub-module validate}} _with_ the
> {{}} reinserted, it will again correctly report an incoherent
> build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-268) Usage of CI friendly version placeholders does not work
[
https://issues.apache.org/jira/browse/MENFORCER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-268:
---
Fix Version/s: (was: 3.0.0)
3.0.1
> Usage of CI friendly version placeholders does not work
> ---
>
> Key: MENFORCER-268
> URL: https://issues.apache.org/jira/browse/MENFORCER-268
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.4.1, 3.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.1
>
>
> If I use the placeholders in a project based on the [CI
> Friendly|http://maven.apache.org/maven-ci-friendly.html] currently
> maven-enforcer-plugin fails like this:
> {code}
> [INFO] --- flatten-maven-plugin:1.0.0:clean (flatten.clean) @ domain ---
> [INFO] Deleting /Users/kama/ws-git/javaee/domain/.flattened-pom.xml
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven) @ domain ---
> Downloading:
> http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/$%7Brevision%7D$%7Bsha1%7D$%7Bchangelist%7D/parent-$%7Brevision%7D$%7Bsha1%7D$%7Bchangelist%7D.pom
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireNoRepositories
> failed with message:
> Could not find artifact
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist} in nexus
> (http://localhost:8081/nexus/content/groups/public)
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist}
> from the specified remote repositories:
> nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
> snapshots=true)
> [WARNING] Rule 4: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist} in
> http://localhost:8081/nexus/content/groups/public was cached in the local
> repository, resolution will not be reattempted until the update interval of
> nexus has elapsed or updates are forced
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist}
> from the specified remote repositories:
> nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
> snapshots=true)
> {code}
> This is currently based on reading the pom file itself instead of using the
> parts which are offered via Maven Core...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-265) Get site generation working
[
https://issues.apache.org/jira/browse/MENFORCER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-265:
---
Fix Version/s: 3.0.0
> Get site generation working
> ---
>
> Key: MENFORCER-265
> URL: https://issues.apache.org/jira/browse/MENFORCER-265
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.4.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.4.2, 3.0.0
>
>
> Currently a {{mvn site}} will fail.
> {code}
> [INFO] Rendering site with org.apache.maven.skins:maven-fluido-skin:jar:1.4
> skin.
> [INFO] Rendering 1 Doxia document: 1 xdoc
> [ERROR] Parser Exception: META-INF/maven/site.vm
> org.apache.velocity.runtime.parser.ParseException: Encountered "source" at
> line 1162, column 52.
> Was expecting one of:
> "," ...
> ")" ...
> {code}
> Need to update maven-site skin..
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-253) Upgrade maven-shared-components parent to version 30
[ https://issues.apache.org/jira/browse/MENFORCER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-253: --- Fix Version/s: 3.0.0 > Upgrade maven-shared-components parent to version 30 > > > Key: MENFORCER-253 > URL: https://issues.apache.org/jira/browse/MENFORCER-253 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 1.4.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2, 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-259) The rule BanDuplicatePomDependencyVersions is not documented
[
https://issues.apache.org/jira/browse/MENFORCER-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-259:
---
Fix Version/s: 3.0.0
> The rule BanDuplicatePomDependencyVersions is not documented
>
>
> Key: MENFORCER-259
> URL: https://issues.apache.org/jira/browse/MENFORCER-259
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
> Fix For: 1.4.2, 3.0.0
>
>
> The rule {{BanDuplicatePomDependencyVersions}} can be used to fail the build
> if duplicate dependencies are declared directly in the POM, but this rule
> isn't documented in the [list of standard
> rules|http://maven.apache.org/enforcer/enforcer-rules/index.html].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-263) Upgrade mrm-maven-plugin to 1.0.0
[ https://issues.apache.org/jira/browse/MENFORCER-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-263: --- Fix Version/s: 3.0.0 > Upgrade mrm-maven-plugin to 1.0.0 > - > > Key: MENFORCER-263 > URL: https://issues.apache.org/jira/browse/MENFORCER-263 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.4.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2, 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-272) Allow site generation to work
[
https://issues.apache.org/jira/browse/MENFORCER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-272:
---
Fix Version/s: 3.0.0
> Allow site generation to work
> -
>
> Key: MENFORCER-272
> URL: https://issues.apache.org/jira/browse/MENFORCER-272
> Project: Maven Enforcer Plugin
> Issue Type: Task
> Components: Documentation
>Reporter: Jesse Glick
>Assignee: Stephen Connolly
>Priority: Minor
> Fix For: 1.4.2, 3.0.0
>
>
> I was unable to get {{mvn site:site}} to run locally, first because of a
> {{NullPointerException}}, then because of a Javadoc error. Patch proposed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-240) Link to page does not work
[ https://issues.apache.org/jira/browse/MENFORCER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-240: --- Fix Version/s: 3.0.0 > Link to page does not work > -- > > Key: MENFORCER-240 > URL: https://issues.apache.org/jira/browse/MENFORCER-240 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Affects Versions: 1.4.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2, 3.0.0 > > > http://maven.apache.org/enforcer/enforcer-api/index.html The link in the left > navigation bar "Maven Enforcer Plugin" is not correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-254) version 1.4.1 cause extra-enforcer-rules ITs failures
[ https://issues.apache.org/jira/browse/MENFORCER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-254: --- Fix Version/s: 3.0.0 > version 1.4.1 cause extra-enforcer-rules ITs failures > - > > Key: MENFORCER-254 > URL: https://issues.apache.org/jira/browse/MENFORCER-254 > Project: Maven Enforcer Plugin > Issue Type: Bug >Affects Versions: 1.4.1 >Reporter: Hervé Boutemy >Priority: Blocker > Fix For: 1.4.2, 3.0.0 > > Attachments: pom.xml > > > when building extra-enforcer-rules > http://www.mojohaus.org/extra-enforcer-rules/ with 1.4.1, some ITs fail: no > issue with 1.4 or any other release -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot
[ https://issues.apache.org/jira/browse/MENFORCER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-204: --- Fix Version/s: 3.0.0 > Add new rule: should be able to make sure that project artifact is a Snapshot > - > > Key: MENFORCER-204 > URL: https://issues.apache.org/jira/browse/MENFORCER-204 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.4.1 >Reporter: Adrien Lecharpentier >Assignee: Guillaume Boué > Fix For: 1.4.2, 3.0.0 > > Attachments: MENFORCER-RequireSnapshotVersion.patch > > > As it is currently possible to validate the current project is a release, we > should have to inverse rule: validate the current project is a snapshot. > The use case: in CI, ensure that the current project is in snapshot version > before doing a `mvn deploy`. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-247) Add a "require file checksum" rule
[ https://issues.apache.org/jira/browse/MENFORCER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-247: --- Fix Version/s: 3.0.0 > Add a "require file checksum" rule > -- > > Key: MENFORCER-247 > URL: https://issues.apache.org/jira/browse/MENFORCER-247 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Lyubomyr Shaydariv >Assignee: Guillaume Boué > Fix For: 1.4.2, 3.0.0 > > Attachments: require.file.checksum.patch > > > Hi. > Sometimes there is a need to have a rule to check a file against a predefined > checksum. Let's say, a result of a generated file in the build output > directory is expected to result in a required checksum, or some source/test > files must result in predefined checksums. I've came across such a rule on > GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would > be nice to have this one as a standard rule. > What I've done already: > * Adapted the original source to the source code base in > http://svn.apache.org/repos/asf/maven/enforcer/trunk (1.4.2-SNAPSHOT) > * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, > SHA-1, SHA-256, SHA-384, SHA-512 > * Added some tests > * Added an example for all hashing functions to the generated site. > What I'm not sure about: > * Would you accept this feature as one that's worth be a part of standard > rules. > * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts > pull requests as I've noticed probably automatically generated `git-svn-id` > field in `git log` output. So probably the patch might be committed to the > Subversion repository first. > Here is the patch diff on GitHub: > https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-273) RequireUpperBoundDeps.excludes
[
https://issues.apache.org/jira/browse/MENFORCER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-273:
---
Fix Version/s: 3.0.0
> RequireUpperBoundDeps.excludes
> --
>
> Key: MENFORCER-273
> URL: https://issues.apache.org/jira/browse/MENFORCER-273
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Jesse Glick
>Assignee: Stephen Connolly
> Fix For: 1.4.2, 3.0.0
>
>
> Sometimes it is desirable to run the {{requireUpperBoundDeps}} rule even
> though it is known that there will be certain failures, so that the set of
> failures can be strictly controlled. Currently there is no option allowing
> you to do that. Other dependency-related rules allow you to specify a list of
> excludes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-266) Remove usage of prerequisites in parent pom
[ https://issues.apache.org/jira/browse/MENFORCER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-266: --- Fix Version/s: 3.0.0 > Remove usage of prerequisites in parent pom > --- > > Key: MENFORCER-266 > URL: https://issues.apache.org/jira/browse/MENFORCER-266 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 1.4.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2, 3.0.0 > > > Currently building with Maven 3.5.0 will produce a WARNING about the usage of > prerequisites in non maven-plugin pom's -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-234) Link to plugin's web site is reported as redirected by maven linkcheck plugin.
[ https://issues.apache.org/jira/browse/MENFORCER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-234: --- Fix Version/s: 3.0.0 > Link to plugin's web site is reported as redirected by maven linkcheck plugin. > -- > > Key: MENFORCER-234 > URL: https://issues.apache.org/jira/browse/MENFORCER-234 > Project: Maven Enforcer Plugin > Issue Type: Bug >Affects Versions: 1.4 > Environment: maven enforcer plugin, checkstyle >Reporter: Andrei Selkin >Assignee: Tibor Digana > Fix For: 1.4.2, 3.0.0 > > > Hello! > We use maven linkcheck plugin to check links on checkstyle's website: > http://checkstyle.sourceforge.net/ . The plugin reports that on page > http://checkstyle.sourceforge.net/plugins.html the following link is > redirected: > http://maven.apache.org/enforcer/maven-enforcer-plugin (301 Moved > Permanently) at > http://maven.apache.org/components/enforcer/maven-enforcer-plugin/ . > Links on plugins.html are generated by Apache Maven Project Info Reports > Plugin. All URLs are grabbed from effective POMs of plugins. > Here is the code: > https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L239 > https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L269 > In effective POM of maven enforcer plugin the problematic link is: > http://maven.apache.org/enforcer/maven-enforcer-plugin > Should be: > http://maven.apache.org/components/enforcer/maven-enforcer-plugin/ > As a result, we do not have an ability to change plugins urls on that page, > because those links are specified by plugins developers. > So, please correct the link, because there are contradictions between > linkcheck and maven enforcer plugin. > Thank in advance! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-228) DependencyConvergence: Simplify logging errors
[
https://issues.apache.org/jira/browse/MENFORCER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-228:
---
Fix Version/s: 3.0.0
> DependencyConvergence: Simplify logging errors
> --
>
> Key: MENFORCER-228
> URL: https://issues.apache.org/jira/browse/MENFORCER-228
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2; Oracle JDK 8
>Reporter: Stephan Krull
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4.2, 3.0.0
>
>
> The dependency convergence rule check works great. I just wonder if it is
> really necessary to log the according error messages two times:
> see source code
> http://svn.apache.org/viewvc/maven/enforcer/tags/1.4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup
> {code:title=lines 127 to 134}
> for ( CharSequence errorMsg : errorMsgs )
> {
> log.warn( errorMsg );
> }
> if ( errorMsgs.size() > 0 )
> {
> throw new EnforcerRuleException( "Failed while enforcing releasability
> the error(s) are " + errorMsgs );
> }
> {code}
> this produces outputs like:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4:enforce (enforce dependency convergence)
> @ bom ---
> [WARNING]
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> [WARNING]
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for commons-logging:commons-logging:1.1.3 paths
> to dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework:spring-context:4.0.9.RELEASE
> +-org.springframework:spring-core:4.0.9.RELEASE
> +-commons-logging:commons-logging:1.1.3
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-com.orientechnologies:orientdb-graphdb:2.1-rc1
> +-com.tinkerpop.blueprints:blueprints-core:2.6.0
> +-commons-logging:commons-logging:1.1.1
> ,
> Dependency convergence error for org.slf4j:jcl-over-slf4j:1.7.6 paths to
> dependency are:
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.activiti:activiti-bpmn-converter:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.activiti:activiti-engine:5.17.0
> +-org.slf4j:jcl-over-slf4j:1.7.6
> and
> +-my.group:my.artifact:2.1-SNAPSHOT
> +-org.springframework.ldap:spring-ldap-core:2.0.2.RELEASE
> +-org.springframework.data:spring-data-commons:1.6.1.RELEASE
> +-org.slf4j:jcl-over-slf4j:1.7.1
> ]
> {noformat}
> the warning log messages are identical to the messages of the exception. so
> just skip one of the outputs if possible.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-239) Fix link in navigation (enforcer/maven-enforcer-plugin/index.html) RESOURCES
[ https://issues.apache.org/jira/browse/MENFORCER-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MENFORCER-239: --- Fix Version/s: 3.0.0 > Fix link in navigation (enforcer/maven-enforcer-plugin/index.html) RESOURCES > > > Key: MENFORCER-239 > URL: https://issues.apache.org/jira/browse/MENFORCER-239 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Affects Versions: 1.4.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.4.2, 3.0.0 > > > Fix the name in the navigation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059904#comment-16059904
]
Guillaume Boué commented on MANTRUN-200:
This can be reproduced for any plugin, not just the Antrun Plugin, so this may
be a Maven core concern.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> 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:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MDEP-572.
---
Resolution: Fixed
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.9
>Reporter: Tim Gokcen
> Fix For: 2.10
>
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059863#comment-16059863
]
Guillaume Boué commented on MDEP-572:
-
Yes, this was most likely fixed with an upgrade of Commons Compress that came
with an upgrade of Plexus Archiver.
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.9
>Reporter: Tim Gokcen
> Fix For: 2.10
>
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Gokcen updated MDEP-572:
Affects Version/s: 2.9
Fix Version/s: 2.10
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.9
>Reporter: Tim Gokcen
> Fix For: 2.10
>
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059843#comment-16059843
]
Tim Gokcen commented on MDEP-572:
-
After some further experimentation, I can confirm that the tar behaviour is
still broken in 2.9 but is fixed in release 2.10. I'm guessing it may have had
to do with the plexus-archiver upgrade that was included with that release?
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.9
>Reporter: Tim Gokcen
> Fix For: 2.10
>
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059839#comment-16059839
]
Hudson commented on MDEP-572:
-
UNSTABLE: Integrated in Jenkins build maven-plugins #9010 (See
[https://builds.apache.org/job/maven-plugins/9010/])
[MDEP-572] Truncated filenames extracting tar files.
Adding IT showing that the plugin keeps the correct file name when unpacking a
TAR file with POSIX long file mode containing a file with a very long file
name. (gboue: [http://svn.apache.org/viewvc/?view=rev=1799601])
* (add) maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child1
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child1/assembly.xml
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child1/pom.xml
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child1/this-is-an-empty-text-file-with-a-name-that-is-longer-than-100-characters-to-verify-that-the-name-is-fully-kept-when-unpacking-from-a-tar.txt
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child2
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/child2/pom.xml
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/invoker.properties
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/pom.xml
* (add)
maven-dependency-plugin/src/it/projects/mdep-572-unpack-tar-long-file/verify.bsh
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8
>Reporter: Tim Gokcen
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059778#comment-16059778
]
Guillaume Boué commented on MDEP-572:
-
I can't reproduce this problem starting with version 2.10 of the plugin (3.0.0
and 3.0.1 also work correctly). Can you update to this version and report back?
I have added an integration test in
[r1799601|http://svn.apache.org/viewvc?rev=1799601=rev] showing the
correct behaviour with current latest version.
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8
>Reporter: Tim Gokcen
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Gokcen updated MDEP-572:
Description:
The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
silently truncating file paths to 100 characters. Tarballs that work just fine
with BSD or GNU tar has its filenames truncated by the unpack step (without any
kind of warning or error).
In my particular example, the Tarball was created by the Apache Maven Assembly
Plugin using {{posix}}.
As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order to
manually execute tar.
(Aside: another suggested solution, e.g., on [this StackOverflow question about
the
issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
is to use the Antrun plugin and execute the {{}} task, but the annoying
thing about that is that Ant doesn't respect file permissions when extracting
tar archives)
was:
The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
silently truncating file paths to 100 characters. Tarballs that work just fine
with BSD or GNU tar has its filenames truncated by the unpack step (without any
kind of warning or error).
In my particular example, the Tarball was created by the Apache Maven Assembly
Plugin using {{posix}}.
As a work-around, I'm using the
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8
>Reporter: Tim Gokcen
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the org.codehaus.mojo Exec-Maven-Plugin in order
> to manually execute tar.
> (Aside: another suggested solution, e.g., on [this StackOverflow question
> about the
> issue|https://stackoverflow.com/questions/26024732/maven-dependency-plugin-unpack-dependencies-cant-support-tar-containing-paths-o]
> is to use the Antrun plugin and execute the {{}} task, but the
> annoying thing about that is that Ant doesn't respect file permissions when
> extracting tar archives)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MDEP-572) Truncated filenames extracting tar files.
[
https://issues.apache.org/jira/browse/MDEP-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Gokcen updated MDEP-572:
Description:
The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
silently truncating file paths to 100 characters. Tarballs that work just fine
with BSD or GNU tar has its filenames truncated by the unpack step (without any
kind of warning or error).
In my particular example, the Tarball was created by the Apache Maven Assembly
Plugin using {{posix}}.
As a work-around, I'm using the
was:
The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
silently truncating file paths to 100 characters. Tarballs that work just fine
with BSD or GNU tar has its filenames truncated by the unpack step (without any
kind of warning or error).
In my particular example, the Tarball was created by the Apache Maven Assembly
Plugin using {{posix}}.
> Truncated filenames extracting tar files.
> -
>
> Key: MDEP-572
> URL: https://issues.apache.org/jira/browse/MDEP-572
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8
>Reporter: Tim Gokcen
>
> The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
> silently truncating file paths to 100 characters. Tarballs that work just
> fine with BSD or GNU tar has its filenames truncated by the unpack step
> (without any kind of warning or error).
> In my particular example, the Tarball was created by the Apache Maven
> Assembly Plugin using {{posix}}.
> As a work-around, I'm using the
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MDEP-572) Truncated filenames extracting tar files.
Tim Gokcen created MDEP-572:
---
Summary: Truncated filenames extracting tar files.
Key: MDEP-572
URL: https://issues.apache.org/jira/browse/MDEP-572
Project: Maven Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.8
Reporter: Tim Gokcen
The {{unpack}} goal doesn't handle POSIX.1-2001 long filenames in tar files,
silently truncating file paths to 100 characters. Tarballs that work just fine
with BSD or GNU tar has its filenames truncated by the unpack step (without any
kind of warning or error).
In my particular example, the Tarball was created by the Apache Maven Assembly
Plugin using {{posix}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
