Open gilles-duboscq opened 3 years ago
Hi @gilles-duboscq ! Thanks for your report. Indeed this is not yet supported but I'll tag this as enhancement
and hopefully it can be added at some point.
This feature would be much appreciated. I read somewhere that it was not implemented because of the enormous amount of work/complexity it would impose. The current workaround is to remove all redundant/versioned files. I have a proposal for another workaround: Most libraries only have a very little amount of versioned files, which are mostly used to work around JVM issues (like the switch between 8 and 9). Why don't you leave everything around these files untouched? I mean the originals and their versions. Maybe shrink names but even without that you would still achieve an enormous overall compression without breaking libs. What I am doing now with libs, for example with Log4J2, is, to check the META-INF/versions. Build exclusions for the classes and copy the versioned files back in as a manual step. That is pretty tedious and error prone. I would gladly exchange a JAR with a few bytes more to get rid of that workflow...
I agree with @vjay82, there should be an option to simply copy META-INF/versions/**
over to the processed jar.
FWIW, I am running into the same issue with log4j as well.
Currently proguard doesn't support Multi-Release JAR files and it actively filters out
META-INF/versions/**
.When processing libraries, the recommended workaround](https://sourceforge.net/p/proguard/bugs/671/) is to find or crate a jar that contains the class files for the desired version.
However that doesn't help when the output of proguard should itself be a multi-release JAR.