TrueZip – Not only annoying but buggy as well!
Now, I wouldn’t mind for any other library to have some bugs here and there – everyone’s code has them, of course. But this one was getting on my nerve for a long time already. I bet it was someone’s university project: all this unnecessary complexity, all this amateur API with tons of duplicate methods doing almost the same .. I mean, just viewing a ZIP file as a “virtual file system” – doesn’t it look like someone’s thesis to you ?! Come one, people usually pack and unpack them, you know. With occasional updates which I think are so rare that it’s much simpler to unpack the archive to temporal folder and pack it back (which is already happening behind the scenes anyway – see below)
Some things that I’ve discovered lately:
- If you pack a folder that contains other ZIP archives (I had to pack a folder with two big ZIPs inside, each one a JDK distribution) – the library seems to be repacking them!
– I don’t know. Probably because it’s so smart thing to do.
But how do I know that ?
– Size of (supposedly repacked) ZIP files is changing – it is dropping down a bit inside new archive
– There are lot’s of “tzp-ctrl.tmp” files created in my temp folder during the process
– New archives do not open on Linux any more but only on Windows
- Build process can’t be terminated when “pack” is in process – it can only be done by killing “java.exe”. So sweet.
- There were many times when TrueZip Maven plugin silently did nothing and created no archive when <includes> were involved (which I re-checked many times, of course, but I won’t be surprised if TrueZip has it’s own logic for how <include> works, like where it’s base directory and the like). So I had to pack the whole folder without <includes> and then remove the files that I didn’t want. Yes, it is silly, no doubt about that.
And, btw, I really don’t like when things go wrong silently (which is a plague in some projects – Ant and Velocity are first coming to mind, you have an undefined property but those two ignore it silently).
Hey, TrueZip! If for some reason I have wrong <include> patterns (which I’m sure were correct, but .. nevermind) and no archive is actually created – why being so silent about that ? In my code an exception is thrown when a combination of include and exclude patterns returns an empty Collection (and exception is specifying all three: base directory, include patterns, exclude patterns).
- Not a bug but a pure headache: things go really wrong if you forget to make this umount() call after creating an archive. Like clicking an “Ok” button – it flushes all data to disk. There’s also an update() call as well but it “may retain some temporary files” (surprise, surprise!) so one shouldn’t really call it (which I did until noticed this subtle difference)
I do hope I won’t have to post about this library again.