Thanks for reporting this and pointing to the workaround.

I personally would tend to not include your pull-request, as this should be fixed with ProGuard first. As you wrote, this is a workaround, but a proper fix might be better.

I'll leave the decisions to @wvengen how to handle this.

Thanks for taking the time to look at this @FibreFoX, much appreciated. I do agree that ProGuard should be fixed. They do have a workaround for this, which is to supply:

--libraryjars somelib.jar(!META-INF/versions/**)

However it isn't possible to provide this configuration option via the plugin currently.

Without this change (or another that provides a means to the same end) users of the proguard-maven-plugin will have to reject all library updates that provide multi release jars until ProGuard updates with Java 9 support, which may be sometime.

The only other options I can think of would be stripping the jar's manually before running ProGuard or writing their own mojo / shell script to do this.

There is another option I can think of: making it possible to pass own strings instead of hard-coding some, this would make this maven-plugin more compatible to further adjustments, including that workaround without binding it to that specific one.

How do you think about this idea?

I think that's a better approach, and saves having to unwind things in the plugin when Java 9 support is added to ProGuard.

How do you see this working from a configuration point of view? A single setting that sets this for all library jars?

Your approach inside the ProGuardMojo was like a single property :) so I assume we should just introduce a new one. Btw: nice catch for refactoring same code fragments 👍

Excellent - I've done that and issued a new pull request.

ping @wvengen does this look good for you? If so, please accept PR #63 and prepare for a new release, as this might be useful for all the JDK 9 adopters.

@liamsharp How did you get your change to work with jxBrowser? When adding the option for jxbrowser-6.18.jar I get error that the jar is specified twice.

@rcantrel Is this question related to the proposed change?

With this fix in place, I've just had to update my configuration to include, which should work for all multi release jar's, it's not specific to JxBrowser:

<libraryJarExclusion>(!META-INF/versions/**)</libraryJarExclusion>

Can you build with a version of JxBrowser before they added Java 9 support? If you have some code I can check out I can take a quick look for you.

@liamsharp yeah it was related to the proposed change. Proguard newbie apparently. To use the libraryjars configuration option, I needed to remove my dependency to jxbrowser-6.19.jar. Thanks for this this PR, btw.

@liamsharp I was rereading you last comment and think you are saying that there is a better way to do what I want. Is there a way to do something like in my pom?
<option>-libraryjars *.jar(!META-INF/versions/**)</option>
or
<option>-libraryJarExclusion (!META-INF/versions/**)</option>
So I don't have to specify a particular jar? Neither of the above options worked for me.

@rcantrel I've just got jxbrowser as a dependancy and the exclusion mentioned before. If you create an example cutdown project to demonstrate the issue I can take a look for you.

@liamsharp @rcantrel a bit off-topic? ;) further discussion should be done in a separate project, makes a bit noise here.

@wvengen @FibreFoX do you have a status update or ETA for this issue? More and more libraries are releasing MR jars and this is becoming a problem.

I'd offer to help, but it seems that there is already a PR that has been ready for a while?

hi @wvengen , is there any update regarding this issue? I was trying out Proguard for my project for the first time and I am currently stuck with this.

Seems like this is fixed by #103. Can be reopened if this is not the case.

From https://wvengen.github.io/proguard-maven-plugin/

You can use inLibsFilter to apply ProGuard classpathentry Filters to all input lib jars
    <inLibsFilter>!META-INF/versions/**</inLibsFilter>