Composing fat jar using runtime dependencies is error prone in case of duplicate resources

[reinhapa]

@melix what was the reason to create a fat jar containing all runtime dependencies in the first place?

I have problems with dependencies, that will define specialized resources as META-INF/beans.xml or META-INF/services/xxx files, that exists in multiple dependencies and can have different content. This leads in my case to false behavior in case as there are multiple Java service definitions for the same interface/abstract class or CDI Bean definitions that in one artifact defines a different discovery mode than in an other artifact.

In case of JMH the solution is to add an Class-Path meta info attribute containing the runtime dependencies in oder to work around this problem. This could also mitigate the path length problem on a Windows installation too..

The following issues could maybe benefit of a reconciling this decision:

• JMH putting gradle logging jar on classpath, causing logback conflict #135
• The filename or extension is too long #137
• "jmhJar" task creates invalid jar #168
• Plugin putting logback on classpath but it is already in the fat jar #186