Can't use zip inputs with assembled cmd jar

[willp-bl]

Zip files cannot be used as inputs to "gather" when using the assembled c3po-cmd jar due to the assembly not merging META-INF/services, see: http://blog.xebia.com/2011/07/20/jar-with-deps-dont-like-meta-infservices/ That page specifically mentions TrueZIP having a problem with it.

This means I have to extract zip files by myself before using c3po-cmd (and I have a lot of zip files)

[peshkira]

Thank you for the bug report.

Could you please share a couple of zips that cause the problem. I have already used it with different types of archives and it worked. AFAIK the open planets used it also on archived collections successfully. May be the error is caused by something else. The logs will probably be helpful as well.

[willp-bl]

Unfortunately I can't share these zip files. They are created with the JRE zip classes, containing ~10k test files, each containing Tika characterization metadata. The files are named 000000.txt, 000001.txt etc.

I am running c3po-cmd on Windows, connecting to a local c3po VM, see: opf-labs#4 (using code from your 040 branch)

When running -jar-with-dependencies (from mvn:assembly:assembly) I get a stack trace that looks like:
IOException: temp\c3poarchives\0 (not a file)
truezip.file.TBIO.cp_r0:178
truezip.file.TBIO.cp_r:138
truezip.file.TFile.cp_r:3181
LocalFileGatherer.extractArchive:241

Looking at the META-INF/services entries in the truezip jars and in the c3po cmd jar I can see that they definitely are not merged in the assembly. I am also having problems getting c3po-cmd to run successfully from within Eclipse, where it should work (it looks like it works but objects are not ingested into mongodb). I'll be able to look in to this in a couple of weeks time and get back to you.

[peshkira]

Thank you for your report. I will take a look as well and will try to reproduce it with zips of my own.
Please let me know, if you have a solution or more insights once you get a chance to look at it.

[peshkira]

Hi, I had a chance to take a look at the codebase during the weekend. I completely forgot that I already had this problem. Take a look at #57 . In the integration branch, I have fixed that issue by going back to commons-compress. So if you want, you can try to bundle that version, or pull up only this fix in a fork of your own.

Unfortunately, I am not sure when I will be able to completely merge these changes, as I still have some work to do in the web component.

Please let me know, if this solves your problem, so that I can close this issue