I'm trying to understand why only one (new) MacBookPro in our dev-team, running OS-X 10.10.5, is having a problem completing the Assemble phase of a Project that no other MacBook on the project is having. I'm wondering if anyone else run into this contradictory phenomenon, and does anyone have an explanation for it?
This is the error we get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly- plugin:2.5.5:single (attachConfig) on project cmr-impl: Execution attachConfig of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: group id '1377585961' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit -> [Help 1]
So yes, I know that if I use the <tarLongFileMode>posix<tarLongFileMode>
mode in the POM the problem goes away. However, this is not required on any of the other MacBooks running the same version of Java and Maven, so it's not really the correct 'answer'. The only difference I can find is that my colleagues are all running OS-X 10.9.x, but I can't find a justification that this is in any way relevant.
To rule out a bad Maven library download or bad plug-ins, I deleted the entire .m2/repository
directory and its contents (two or three times), as well as the apache-maven-3.3.3
install, replacing it with first 3.2.1, then 3.1.1, and then 2.5, and finally 3.0.4. Doesn't clear it.
FYI, this is NOT related to an IDE. This is all command line "mvn -X clean install".
Please don't just tell me to use the <tarLongFileMode>posix<tarLongFileMode>
- like I said, that's known, and it doesn't explain why the Assembly phase is behaving so irrationally from one MacBook to the other.
Thanks in advance.
This is the Java version info:
$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: /usr/local/apache-maven-3.0.4
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
This is the full error stack:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (attachConfig) on project cmr-impl: Execution attachConfig of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: group id '1377585961' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (attachConfig) on project cmr-impl: Execution attachConfig of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: group id '1377585961' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution attachConfig of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: group id '1377585961' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.RuntimeException: group id '1377585961' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit
at org.codehaus.plexus.archiver.commonscompress.archivers.tar.TarArchiveOutputStream.failForBigNumber(TarArchiveOutputStream.java:635)
at org.codehaus.plexus.archiver.commonscompress.archivers.tar.TarArchiveOutputStream.failForBigNumberWithPosixMessage(TarArchiveOutputStream.java:630)
at org.codehaus.plexus.archiver.commonscompress.archivers.tar.TarArchiveOutputStream.failForBigNumbers(TarArchiveOutputStream.java:613)
at org.codehaus.plexus.archiver.commonscompress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:290)
at org.codehaus.plexus.archiver.tar.TarArchiver.tarFile(TarArchiver.java:330)
at org.codehaus.plexus.archiver.tar.TarArchiver.execute(TarArchiver.java:189)
at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:1039)
at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :cmr-impl
The answer to this issue turned out to be that the User's GroupID number on that one mac exceeded the 2097151 size specified for the library-code when in standard mode. The OSX GroupIDs differ depending on the MacBook generations. The reason that "posix" can solve the underlying issue, is that the POSIX mode has a larger variable-size to hold the GroupID internally, and the newer MacBooks then don't fail trying to put a big number in it. So it had nothing to do with the Maven-Assembly's functionality at all, but with the underlying library's code-base. Specifying the POSIX mode is a work-around, not a requirement, but could be considered as a potentially valid 'recommended' for all POM use-cases since it would prevent niche-machines failing the build-phase.
Will there be cases where POSIX cannot be specified for some other reason and therefore this would be an unhelpful solution? That's quite possible in the grand scheme of OS' and libraries.
The appropriateness of any chosen solution should always be based in the why of it, not that it incidentally makes an issue go away without clear comprehension of how it achieves it.