Open ebourg opened 3 months ago
I will not be adding anything to support Java 8 or earlier. It is time to move on.
The same situation may arise in later JDKs when new modules are introduced though. Would you object to a 10 line PR addressing this issue?
If it fixes issues between using 11, 17 and 21 and so on, then it should be fixed yes. I would merge such a PR.
It is time to move on.
Agreed, that's why it would be nice if there was a migration path that allows legacy system to switch. We can't just do this in one day, first we need testing, then a time when we probably need to be able to build with both java 8 and modern Java, and finally only modern Java.
Also please note that the documentation only has Java 8 examples: https://wvengen.github.io/proguard-maven-plugin/
You are right and I would be happy to merge and release any new contributions to examples. They are quite outdated. You (or anyone else) can target gh-pages branch: https://github.com/wvengen/proguard-maven-plugin/tree/gh-pages
If you need very long-lived support for many Java versions there are some, for example https://github.com/wvengen/proguard-maven-plugin/issues/355#issuecomment-2296167468 Other possibilites are of course difference development branches, profiles or environmental variables.
I've some troubles supporting both Java 8 and Java 9+ with the same plugin configuration. For example to build with Java 8 I use this:
and for Java 9+ I use this:
But I can't use a mixed configuration:
In this case Proguard complains about missing files.
The workaround is to duplicate the whole plugin configuration in two different profiles, but I'd like to avoid adding 50 lines of plugin declaration for this.
Would it be possible to modify the plugin to check if the libraries listed exist before using them and ignore those that are missing?