maven-shade-plugin
maven-shade-plugin copied to clipboard
apache
[MSHADE-265] correct merging of module-info in shades
Romain Manni-Bucau opened MSHADE-265 and commented
Should work by merging of the encountered module info jut also automatic module name in manifest. The hard part being removing the not needed entries which are sometimes not simply the ones of the included classes - SPI need it still
Issue Links:
- MSHADE-264 handle module-info merge in shades for java 9 support ("is duplicated by")
Robert Scholte commented
We had this discussion with a couple of Maven teammember and Mark Reinhold at FOSDEM and we came to the conclusion we should never merge module descriptors. The main reason: you will break strong encapsulation. There is still an open issue for it on the JPMS issue list, waiting to be picked up in a next Java release. I think in case of libraries this cannot be solved. But in case of applications I hope implementing MSHADE-262 will do the job.
Romain Manni-Bucau commented
I know but it literally means "dont use shade plugin from now on" and "no migration of shade usages". Im sure we - or oracle - can do something better, in particular with the fatjar/shade/uberjar usage. At least we should provide a transformer with some include exclude config for all type of module info entries.
Robert Scholte commented
Let's define the usecases first (maybe with ITs), otherwise the discussion is too abstract. The chance is that modularization does solve some issues we used to solve with shading.
Romain Manni-Bucau commented
Ok, my direct use case is xbean (from geronimo) project. We do several shades and since asm has now some module-info, we need to merge it properly. This use case is simple since we want to export everything so can be a global toggle instead of fine merge. My "this week" workaround will ve to exclude module info and use automatic module name since we need to release very soon but a real shade solution is hoped for next releases.
Next big shades cases are meecrowave (from openwebbeans) where we shade several asf libs which will all have module info file at some point.
Thinking out loud: is the exclude/automatic name workaround a first valid impl?
Robert Scholte commented
Not sure you are aware of it, but with MSHADE-258 module-info files are already removed. The idea is that if you don't add a module descriptor, then there's no need to keep these files: they should end up on the classpath anyway disabling all JPMS features.
Romain Manni-Bucau commented
Hmm, was not aware and tested and older version
Can be a start if it validates the module name presence - but it is not enough since for libs (xbean or beam case) it will not provide enough flexibility when all the stack will have moved to java 9 and need "uses" or "provides".
Robert Scholte commented
Just to be sure we're on the same page, can you create a minimal project or setup of projects to show what you want to achieve?
Romain Manni-Bucau commented
Created https://github.com/rmannibucau/sample-shade-java9 representing a simple case for lib just one step more complicated than asm (which just exports everything). Does it help enough?
Sebastian Stenzel commented
Not sure if this is even on the roadmap, but for the record, I want to add something that needs to be taken care of by when applying package relocations:
The jar tool adds the optional ModulePackages attribute to the {}module-info.class{}. If it is present, it is required to contain an exhaustive list of the jar's packages, because the class loader uses this as the single source of truth and ignores any unlisted packages.
I.e. when relocating packages, this attribute needs to be updated or deleted (so the class loader falls back to scanning the whole jar). Otherwise a shaded jar will cause NoClassDefFoundErrors at runtime.
See Alan Bateman's comment on this StackOverflow post:
Tools or plugins doing this must update the value of the ModulePackages attribute.