Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.1.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      Fedora 25

      Description

      When executing 'mvn package' on the attached project, the produced archive(s) are not produced as expected. As an example, the following entries in the zip archive I expect to be marked as directories and end with a slash rather than the current state:

      crwsrwsrwx         0  11-Feb-2016  21:30:54  META-INF/maven/org.slf4j
      crwsrwsrwx         0  11-Feb-2016  21:30:54  META-INF/maven/org.slf4j/slf4j-api
      

      In the tar archive they are links which is also not expected.

      I have also tried to find any reference to this in maven-archiver and plexus-archiver but wasn't able to find anything.
      Using the unzip utility asks the following:

      replace META-INF/maven? [y]es, [n]o, [A]ll, [N]one, [r]ename: 
      

      during unzip which was also unexpected.

      1. effio24.xml
        69 kB
        Andreas Aronsson
      2. effio25.xml
        90 kB
        Andreas Aronsson
      3. incorrectentries.zip
        4 kB
        Andreas Aronsson
      4. incorrectentries-compress114snapshot.zip
        6 kB
        Andreas Aronsson

        Activity

        Hide
        gboue Guillaume Boué added a comment -

        I was able to reproduce the behaviour on Ubuntu 16.04, so here are more information. zipinfo incorrectentries-1-SNAPSHOT.jar shows

        lrwsrwsrwt  2.0 unx        0 bl defN 16-Feb-11 21:30 META-INF/maven
        lrwsrwsrwt  2.0 unx        0 bl defN 16-Feb-11 21:30 META-INF/maven/org.slf4j
        lrwsrwsrwt  2.0 unx        0 bl defN 16-Feb-11 21:30 META-INF/maven/org.slf4j/slf4j-api
        lrwsrwsrwt  2.0 unx        0 bl defN 17-Jan-10 23:41 META-INF/maven/com.example.incorrectentries
        lrwsrwsrwt  2.0 unx        0 bl defN 17-Jan-10 23:41 META-INF/maven/com.example.incorrectentries/incorrectentries
        

        when those should be directories. I noticed however, that the slf4j-api JAR also contained faulty entries; executing zipinfo ~/.m2/repository/org/slf4j/slf4j-api/1.7.16/slf4j-api-1.7.16.jar shows

        ?rwsrwsrwt  2.0 unx        0 b- stor 16-Feb-11 21:30 META-INF/maven/
        ?rwsrwsrwt  2.0 unx        0 b- stor 16-Feb-11 21:30 META-INF/maven/org.slf4j/
        ?rwsrwsrwt  2.0 unx        0 b- stor 16-Feb-11 21:30 META-INF/maven/org.slf4j/slf4j-api/
        

        with a leading ? (not sure what that means).

        When changing the slf4j-api dependency to, for example, log4j:log4j:1.2.17, running zipinfo incorrectentries-1-SNAPSHOT.jar shows the expected

        drwxr-xr-x  2.0 unx        0 b- stor 12-May-06 13:24 META-INF/maven/
        drwxr-xr-x  2.0 unx        0 b- stor 12-May-06 13:24 META-INF/maven/log4j/
        drwxr-xr-x  2.0 unx        0 b- stor 12-May-06 13:24 META-INF/maven/log4j/log4j/
        

        but there is still a

        lrwsrwsrwt  2.0 unx        0 bl defN 17-Jan-10 23:32 META-INF/maven/com.example.incorrectentries
        lrwsrwsrwt  2.0 unx        0 bl defN 17-Jan-10 23:32 META-INF/maven/com.example.incorrectentries/incorrectentries
        

        remaining.

        Show
        gboue Guillaume Boué added a comment - I was able to reproduce the behaviour on Ubuntu 16.04, so here are more information. zipinfo incorrectentries-1-SNAPSHOT.jar shows lrwsrwsrwt 2.0 unx 0 bl defN 16-Feb-11 21:30 META-INF/maven lrwsrwsrwt 2.0 unx 0 bl defN 16-Feb-11 21:30 META-INF/maven/org.slf4j lrwsrwsrwt 2.0 unx 0 bl defN 16-Feb-11 21:30 META-INF/maven/org.slf4j/slf4j-api lrwsrwsrwt 2.0 unx 0 bl defN 17-Jan-10 23:41 META-INF/maven/com.example.incorrectentries lrwsrwsrwt 2.0 unx 0 bl defN 17-Jan-10 23:41 META-INF/maven/com.example.incorrectentries/incorrectentries when those should be directories. I noticed however, that the slf4j-api JAR also contained faulty entries; executing zipinfo ~/.m2/repository/org/slf4j/slf4j-api/1.7.16/slf4j-api-1.7.16.jar shows ?rwsrwsrwt 2.0 unx 0 b- stor 16-Feb-11 21:30 META-INF/maven/ ?rwsrwsrwt 2.0 unx 0 b- stor 16-Feb-11 21:30 META-INF/maven/org.slf4j/ ?rwsrwsrwt 2.0 unx 0 b- stor 16-Feb-11 21:30 META-INF/maven/org.slf4j/slf4j-api/ with a leading ? (not sure what that means). When changing the slf4j-api dependency to, for example, log4j:log4j:1.2.17 , running zipinfo incorrectentries-1-SNAPSHOT.jar shows the expected drwxr-xr-x 2.0 unx 0 b- stor 12-May-06 13:24 META-INF/maven/ drwxr-xr-x 2.0 unx 0 b- stor 12-May-06 13:24 META-INF/maven/log4j/ drwxr-xr-x 2.0 unx 0 b- stor 12-May-06 13:24 META-INF/maven/log4j/log4j/ but there is still a lrwsrwsrwt 2.0 unx 0 bl defN 17-Jan-10 23:32 META-INF/maven/com.example.incorrectentries lrwsrwsrwt 2.0 unx 0 bl defN 17-Jan-10 23:32 META-INF/maven/com.example.incorrectentries/incorrectentries remaining.
        Hide
        johnchapin John Chapin added a comment -

        FWIW, I experienced the same issue - it manifested as a failure to unzip jar files on AWS's Lambda platform.

        Downgrading the maven-assembly-plugin to version 2.6 solved this issue for me. I didn't make any changes to the slf4j-api dependencies.

        Show
        johnchapin John Chapin added a comment - FWIW, I experienced the same issue - it manifested as a failure to unzip jar files on AWS's Lambda platform. Downgrading the maven-assembly-plugin to version 2.6 solved this issue for me. I didn't make any changes to the slf4j-api dependencies.
        Hide
        andreas.aronsson Andreas Aronsson added a comment - - edited

        Downgrading works fine for me too.
        I see the same problem with leading ? in
        commons-logging-1.2 but not in commons-logging-1.1.1
        httpclient-4.3.5.jar and all httpclient versions in my m2 cache 4.0.1 4.0.2 4.2.3 4.3.5 4.5.1 4.5.2

        commons-io-2.4 has the faulty entries but not commons-io-2.5. I will try to find out what differs.

        Regardless, it might be a good idea to handle faulty entries like in version 2.6 since there seems to be a large amount of jar files out there that are affected.

        Show
        andreas.aronsson Andreas Aronsson added a comment - - edited Downgrading works fine for me too. I see the same problem with leading ? in commons-logging-1.2 but not in commons-logging-1.1.1 httpclient-4.3.5.jar and all httpclient versions in my m2 cache 4.0.1 4.0.2 4.2.3 4.3.5 4.5.1 4.5.2 commons-io-2.4 has the faulty entries but not commons-io-2.5. I will try to find out what differs. Regardless, it might be a good idea to handle faulty entries like in version 2.6 since there seems to be a large amount of jar files out there that are affected.
        Hide
        andreas.aronsson Andreas Aronsson added a comment - - edited

        Attached effective-pom for commons-io 2.4 and 2.5. It seems that they are built with maven-assembly-plugin 2.3 and 2.5.5 respectively.

        Looks like https://issues.apache.org/jira/browse/MASSEMBLY-422 is the original cause.

        Show
        andreas.aronsson Andreas Aronsson added a comment - - edited Attached effective-pom for commons-io 2.4 and 2.5. It seems that they are built with maven-assembly-plugin 2.3 and 2.5.5 respectively. Looks like https://issues.apache.org/jira/browse/MASSEMBLY-422 is the original cause.
        Hide
        gboue Guillaume Boué added a comment -

        The root cause of this issue seems to be in Commons Compress, I created COMPRESS-379.

        Show
        gboue Guillaume Boué added a comment - The root cause of this issue seems to be in Commons Compress, I created COMPRESS-379 .
        Hide
        andreas.aronsson Andreas Aronsson added a comment -

        Maybe we need a separate issue for maven-assembly-plugin-3.x.x to handle the invalid zip files like 2.6?

        Show
        andreas.aronsson Andreas Aronsson added a comment - Maybe we need a separate issue for maven-assembly-plugin-3.x.x to handle the invalid zip files like 2.6?
        Hide
        gboue Guillaume Boué added a comment -

        This can't be solved at the Assembly Plugin level. You can still force the use of plexus-archiver 3.0.1 inside the Assembly plugin dependencies and see if it works for you, but it can create other issues. There could potentially be a work-around inside plexus-archiver (don't rely on the output of isUnixSymlink in case of broken entries in this code), but let's see what the Compress issue brings first.

        Show
        gboue Guillaume Boué added a comment - This can't be solved at the Assembly Plugin level. You can still force the use of plexus-archiver 3.0.1 inside the Assembly plugin dependencies and see if it works for you, but it can create other issues. There could potentially be a work-around inside plexus-archiver (don't rely on the output of isUnixSymlink in case of broken entries in this code ), but let's see what the Compress issue brings first.
        Hide
        andreas.aronsson Andreas Aronsson added a comment -

        I see. Interesting and unfortunate.
        If I understood this correctly, this means that maven-assembly-plugin-3.x is unable to create a zip file from jar files created by maven-assembly-plugin-2.4 that will unzip without errors. This will remain to be the case for many years to come. That will also mean that anyone with the same use case must stay at maven-assembly-plugin-2.6 for as long. Perhaps a good idea to add this gotcha/limitation/whatever to the documentation?

        Show
        andreas.aronsson Andreas Aronsson added a comment - I see. Interesting and unfortunate. If I understood this correctly, this means that maven-assembly-plugin-3.x is unable to create a zip file from jar files created by maven-assembly-plugin-2.4 that will unzip without errors. This will remain to be the case for many years to come. That will also mean that anyone with the same use case must stay at maven-assembly-plugin-2.6 for as long. Perhaps a good idea to add this gotcha/limitation/whatever to the documentation?
        Hide
        gboue Guillaume Boué added a comment -

        This is fixed in Commons Compress. Pending their release of 1.14, you can force a dependency on org.apache.commons:commons-compress:1.14-SNAPSHOT in the Assembly plugin's dependencies to have the correct behaviour here (the snapshot repository to use is https://repository.apache.org/content/repositories/snapshots).

        Show
        gboue Guillaume Boué added a comment - This is fixed in Commons Compress. Pending their release of 1.14, you can force a dependency on org.apache.commons:commons-compress:1.14-SNAPSHOT in the Assembly plugin's dependencies to have the correct behaviour here (the snapshot repository to use is https://repository.apache.org/content/repositories/snapshots ).
        Hide
        andreas.aronsson Andreas Aronsson added a comment -

        Attaching updated project as per instructions.

        Show
        andreas.aronsson Andreas Aronsson added a comment - Attaching updated project as per instructions.
        Hide
        andreas.aronsson Andreas Aronsson added a comment - - edited

        The snapshot does seem to fix the issue.
        But I am getting some inconsistent behavior:

        [INFO] Building tar: /home/andreasa/tmp/incorrectentries/target/incorrectentries-1-SNAPSHOT.tar
        [WARNING] When creating tar entry
        java.lang.NullPointerException
        	at org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:41)
        	at org.codehaus.plexus.components.io.resources.Deferred.getContents(Deferred.java:60)
        	at org.codehaus.plexus.components.io.resources.proxy.ResourceInvocationHandler.invoke(ResourceInvocationHandler.java:62)
        	at com.sun.proxy.$Proxy23.getContents(Unknown Source)
        	at org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:137)
        	at org.codehaus.plexus.archiver.tar.TarArchiver.tarFile(TarArchiver.java:329)
        	at org.codehaus.plexus.archiver.tar.TarArchiver.execute(TarArchiver.java:168)
        	at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:993)
        	at org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445)
        	at org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:184)
        	at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:476)
        	at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:58)
        	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
        	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
        	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
        	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
        	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
        	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
        	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
        	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
        	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
        	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        	at java.lang.reflect.Method.invoke(Method.java:498)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
        

        This does not happen on every run.
        Another one even weirder

        [INFO] Building tar: /home/andreasa/tmp/incorrectentries/target/incorrectentries-1-SNAPSHOT.tar
        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        #  SIGSEGV (0xb) at pc=0x00007efc15de3a24, pid=23890, tid=0x00007efc16b65700
        #
        # JRE version: OpenJDK Runtime Environment (8.0_111-b16) (build 1.8.0_111-b16)
        # Java VM: OpenJDK 64-Bit Server VM (25.111-b16 mixed mode linux-amd64 compressed oops)
        # Problematic frame:
        # C  [libc.so.6+0x90a24]  __memcpy_sse2_unaligned_erms+0x44
        #
        # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
        #
        # An error report file with more information is saved as:
        # /home/andreasa/tmp/incorrectentries/hs_err_pid23890.log
        #
        # If you would like to submit a bug report, please visit:
        #   http://bugreport.java.com/bugreport/crash.jsp
        # The crash happened outside the Java Virtual Machine in native code.
        # See problematic frame for where to report the bug.
        #
        /usr/bin/mvn: line 20: 23890 Aborted                 (core dumped) $M2_HOME/bin/mvn "$@"
        

        When I remove the tar packaging it is all working well.
        Perhaps a separate issue for the tar packaging?

        Show
        andreas.aronsson Andreas Aronsson added a comment - - edited The snapshot does seem to fix the issue. But I am getting some inconsistent behavior: [INFO] Building tar: /home/andreasa/tmp/incorrectentries/target/incorrectentries-1-SNAPSHOT.tar [WARNING] When creating tar entry java.lang.NullPointerException at org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:41) at org.codehaus.plexus.components.io.resources.Deferred.getContents(Deferred.java:60) at org.codehaus.plexus.components.io.resources.proxy.ResourceInvocationHandler.invoke(ResourceInvocationHandler.java:62) at com.sun.proxy.$Proxy23.getContents(Unknown Source) at org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:137) at org.codehaus.plexus.archiver.tar.TarArchiver.tarFile(TarArchiver.java:329) at org.codehaus.plexus.archiver.tar.TarArchiver.execute(TarArchiver.java:168) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:993) at org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445) at org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:184) at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:476) at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:58) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) This does not happen on every run. Another one even weirder [INFO] Building tar: /home/andreasa/tmp/incorrectentries/target/incorrectentries-1-SNAPSHOT.tar # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007efc15de3a24, pid=23890, tid=0x00007efc16b65700 # # JRE version: OpenJDK Runtime Environment (8.0_111-b16) (build 1.8.0_111-b16) # Java VM: OpenJDK 64-Bit Server VM (25.111-b16 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x90a24] __memcpy_sse2_unaligned_erms+0x44 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/andreasa/tmp/incorrectentries/hs_err_pid23890.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /usr/bin/mvn: line 20: 23890 Aborted (core dumped) $M2_HOME/bin/mvn "$@" When I remove the tar packaging it is all working well. Perhaps a separate issue for the tar packaging?
        Hide
        michael-o Michael Osipov added a comment -

        The crash means that there is a bug in the native ZIP code (highly likely) in the VM. I have such crashes randomly on Tomcat when the content is compressed with GZIP on the fly. Unless you can't reproduce the issue, you are lost. I disabled compression on Tomcat.

        Show
        michael-o Michael Osipov added a comment - The crash means that there is a bug in the native ZIP code (highly likely) in the VM. I have such crashes randomly on Tomcat when the content is compressed with GZIP on the fly. Unless you can't reproduce the issue, you are lost. I disabled compression on Tomcat.
        Hide
        andreas.aronsson Andreas Aronsson added a comment -

        Looks like commons-compress-1.14 was released 2017-05-14 http://apache.mirrors.spacedump.net//commons/compress/binaries/
        Recent release is still on commons-compress-1.9
        Is it a simple version bump or does Maven Assembly Plugin need some work to integrate that version?
        Thanks.

        Show
        andreas.aronsson Andreas Aronsson added a comment - Looks like commons-compress-1.14 was released 2017-05-14 http://apache.mirrors.spacedump.net//commons/compress/binaries/ Recent release is still on commons-compress-1.9 Is it a simple version bump or does Maven Assembly Plugin need some work to integrate that version? Thanks.
        Hide
        khmarbaise Karl Heinz Marbaise added a comment -

        plexus-archiver 3.5 contains commons-compress-1.14 which is part of maven-assembly-plugin:3.1.0.

        Show
        khmarbaise Karl Heinz Marbaise added a comment - plexus-archiver 3.5 contains commons-compress-1.14 which is part of maven-assembly-plugin:3.1.0.
        Hide
        khmarbaise Karl Heinz Marbaise added a comment -

        Base on the VOTE I have started for maven-assembly-plugin 3.1.0 can someone verify this? A feedback on the dev list would be great...

        Show
        khmarbaise Karl Heinz Marbaise added a comment - Base on the VOTE I have started for maven-assembly-plugin 3.1.0 can someone verify this? A feedback on the dev list would be great...
        Hide
        andreas.aronsson Andreas Aronsson added a comment - - edited

        Good with a proper fixversion .

        I used the original project in which I first saw this issue to test the staged binaries.
        With 2.6 no incorrect entries are created.
        3.0.0 produces incorrect entries.
        3.1.0 no incorrect entries.
        It seems to be working beautifully as you predicted.
        Unfortunately I don't know how to post to maven-dev without first subscribing to the list.
        When the vote was cast I was not subscribed (usually only follow the rss feed).

        Show
        andreas.aronsson Andreas Aronsson added a comment - - edited Good with a proper fixversion . I used the original project in which I first saw this issue to test the staged binaries. With 2.6 no incorrect entries are created. 3.0.0 produces incorrect entries. 3.1.0 no incorrect entries. It seems to be working beautifully as you predicted. Unfortunately I don't know how to post to maven-dev without first subscribing to the list. When the vote was cast I was not subscribed (usually only follow the rss feed).
        Hide
        khmarbaise Karl Heinz Marbaise added a comment -

        Hi Andreas Aronsson,
        You can simply subscribe...and the VOTE can be VOTEd on later or if you like to see the history you can see that via the mailing list archives: https://maven.apache.org/mail-lists.html

        apart from that. Many thanks for your feedback.

        Show
        khmarbaise Karl Heinz Marbaise added a comment - Hi Andreas Aronsson , You can simply subscribe...and the VOTE can be VOTEd on later or if you like to see the history you can see that via the mailing list archives: https://maven.apache.org/mail-lists.html apart from that. Many thanks for your feedback.
        Hide
        khmarbaise Karl Heinz Marbaise added a comment -

        Fixed by upgrades through maven-archiver (plexus-archiver 3.5)...

        Show
        khmarbaise Karl Heinz Marbaise added a comment - Fixed by upgrades through maven-archiver (plexus-archiver 3.5)...

          People

          • Assignee:
            khmarbaise Karl Heinz Marbaise
            Reporter:
            andreas.aronsson Andreas Aronsson
          • Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development