assembly / jar-with-dependencies:

Discussion:

Kristian Rink

2011-02-04 12:58:10 UTC

Folks;

after using assembly / jar-with-dependencies in many internal cases so
far in order to quickly build "fat", runnable jar files, at the moment
I happen to be completely stuck with this. The project to be built is a
.jar artifact, having jcouchdb, apache tika 0.8 and a few other
dependencies declared.

My configuration looks like this, in pom.xml:

<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>svcs.Launcher</mainClass>
</manifest>
</archive>
</configuration>
</plugin>

Usually I run mvn clean install assembly:assembly which, for that
setup, works fine in all my other projects - same as introducing an
<execution> ("attached" to lifecycle phase "package") does. In this
project, however, things reproducibly fail like this:

[...]
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
create assembly: Error creating assembly archive jar-with-dependencies:
Problem creating jar: Unexpected end of ZLIB input stream at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:429)
[...]
22 more Caused by: java.io.EOFException: Unexpected end of ZLIB input
stream at java.util.zip.ZipFile$1.fill(ZipFile.java:227) at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141) at
java.io.FilterInputStream.read(FilterInputStream.java:116) at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:565)
at
org.codehaus.plexus.archiver.jar.JarArchiver.zipFile(JarArchiver.java:553)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:595)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:426)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:349)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:250)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:852) ...
24 more
[...]

Surprisingly, as soon as I disable / leave out the tika dependency,
assembly:assembly works as intended. Unfortunately, this is not what I
want / need. :) So, is there anything I can completely do wrong here?
Where could be the problem? Any size restrictions to .jar files in
terms of byte size or file count? Is there any way to make maven more
"verbose" about what exactly is happening, i.e. at which point in
building the .jar the EOFException is being thrown? mvn version, by the
way:

[13:50:03] ***@n428:~$ mvn --version
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21

TIA and all the best,
Kristian

Kristian Rink

2011-02-04 18:38:05 UTC

Permalink

Kristian Rink

2011-02-04 18:38:33 UTC

Permalink

Wayne Fay

2011-02-04 21:37:32 UTC

Permalink

Post by Kristian Rink
Problem creating jar: Unexpected end of ZLIB input stream at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:429)
Surprisingly, as soon as I disable / leave out the tika dependency,
assembly:assembly works as intended. Unfortunately, this is not what I

Are you sure the Apache Tika jar that you've got in your repo is a
valid jar file? Can you open it with jar -xf and make sure? I'd
suspect there is a problem with the jar since adding that dep is
breaking your build.

Otherwise, how big is your assembled artifact without this jar? I've
heard of some really massive assemblies so I doubt that is your
problem, but its worth asking...

Wayne

Kristian Rink

2011-02-07 09:47:31 UTC

Permalink

Hi Wayne, all;

... and first off, thanks a bunch for getting me sorted out.

Am Fri, 4 Feb 2011 16:37:32 -0500

Post by Wayne Fay
Are you sure the Apache Tika jar that you've got in your repo is a
valid jar file? Can you open it with jar -xf and make sure? I'd
suspect there is a problem with the jar since adding that dep is
breaking your build.

Well, at the moment, I downgraded the dependency in there (tika 0.8 ->
tika 0.7), and this seems to eliminate the problem so I kow it's either
about 0.8 (plus transitive dependencies) being way larger or tika 0.8
being somehow broken. However, at the moment, given the error messages
seen in there, I failed to even see which jar might cause this kind of
trouble. Is there any way of how to get more qualified output on that?

Post by Wayne Fay
Otherwise, how big is your assembled artifact without this jar? I've
heard of some really massive assemblies so I doubt that is your
problem, but its worth asking...

I am not completely sure how large it will get using assembly:assembly.
The version built with tika 0.7 is about 20 megs in size, given 0.8
seems to come with some more dependencies / features, think it's about
to be somewhere in between 20 and 30 megs...

Thanks in advance and all the best,
Kristian

Wayne Fay

2011-02-07 16:04:08 UTC

Permalink

Post by Kristian Rink
Well, at the moment, I downgraded the dependency in there (tika 0.8 ->
tika 0.7), and this seems to eliminate the problem so I kow it's either
about 0.8 (plus transitive dependencies) being way larger or tika 0.8
being somehow broken. However, at the moment, given the error messages
seen in there, I failed to even see which jar might cause this kind of
trouble. Is there any way of how to get more qualified output on that?

Did you try "mvn -e ..." or "mvn -X ..." to get more debugging
information during the build? I doubt you would get anything that
would help in this specific case, though. If you really want to debug
it, you probably need to trace it in an IDE or add some additional
logging in AbstractZipArchiver.zipFile().

Post by Kristian Rink
seems to come with some more dependencies / features, think it's about
to be somewhere in between 20 and 30 megs...

No, I'm talking about assemblies that are hundreds of megs or multiple
gigs. There should not be any troubles building assemblies that are
merely tens of megs.

I suspect there is something wrong with the Tika 0.8 jar or one of its
dependencies. Did you ask the Tika people about any of this? Perhaps
one of their users has some experiences to share.

Wayne