@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:
@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.xmlorMETA-INF/services/xxxfiles, 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-Pathmeta 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:
135
137
168
186