Shading copies other projects' classes into your own JAR, so their license duties come along. Use the Maven Shade plugin's resource transformers to merge NOTICE content and avoid duplicate license files, then open the finished JAR and confirm the notices are actually present.
Why shaded JARs are a license blind spot
A normal Maven dependency lives in its own JAR with its own META-INF folder. A shaded or "uber" JAR flattens many dependencies into one archive. Two things happen. The dependency's code now ships inside your artifact, and its license and NOTICE files may collide or be overwritten, because they share paths like META-INF/LICENSE and META-INF/NOTICE.
If you ship that JAR to customers, or put it inside a product, you are redistributing the bundled code. That is the case where permissive license notice duties and copyleft duties both apply. This is engineering guidance, not legal advice.
What the Shade plugin offers
The Maven Shade plugin documents several resource transformers. Two are relevant here:
| Transformer | What the docs say it does |
|---|---|
| ApacheLicenseResourceTransformer | Prevents license duplication |
| ApacheNoticeResourceTransformer | Prepares a merged NOTICE |
The documentation explains the reason for the second one: some licenses, including Apache License 2.0, require that notices are preserved by downstream distributors, and the transformer automates assembling an appropriate NOTICE. It can simply merge in dependent notices.
Apache 2.0 section 4 is the text behind that. If the work includes a NOTICE file, derivative works you distribute must include a readable copy of its attribution notices, in a NOTICE file, in documentation, or in a display your software generates.
Steps for a shaded build
- List what gets shaded. Check the plugin's artifactSet or includes, so you know exactly which dependencies are in the JAR.
- Add the license and notice transformers in the shade configuration.
- Build and unzip the JAR. Look in META-INF for LICENSE and NOTICE files, and read the NOTICE.
- Compare the shaded list with your SBOM. Every bundled component should have its license text available somewhere in the release.
- Handle licenses the transformers do not cover. MIT, BSD and other licenses with no NOTICE convention still need their text kept. A separate third party notices file in the release is the usual answer.
- Add a test that fails if META-INF/NOTICE is missing from the artifact.
Two traps to watch
First, relocation. Shading often renames packages so your copy does not clash with another one on the classpath. Relocation does not change the license. The code is still the original author's.
Second, minimizing. Some builds strip unused classes. The JAR then holds only part of a library, but the license still applies to that part.
If any shaded dependency is under a copyleft license, stop and review. Bundling GPL code into a JAR you distribute is a different question from bundling Apache code. Our posts on internal use versus distribution and LGPL combined works explain where to start.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the inventory lists transitive components too, which is the list you need to compare against your shaded JAR.
Safeguard's SBOM and dependency scanning gives you that component and license list per build, and policies can gate a pull request on a license rule. You can try a free scan at gold.safeguard.sh.
Quick check
Does relocating packages remove the need for notices?
No. Relocation renames packages, but the code is still the original author's work and the license still applies.
Do I need this if the JAR is only used inside my company?
Duties generally attach to distribution, so purely internal use is a different case. If the JAR later ships to a customer or inside a product, the answer changes. Check with counsel for your situation.
Sources
Last reviewed: 19 October 2026.
