Shade used to modify the POM structure during build, but Maven was
changed to disallow this behavior for reasons regarding build consistency.
I ran into this issue somewhat recently. My approach for now, similar to
your "Solution 3", to exclude the shaded dependencies from the module
dependency,
o from here? Should this be
brought to Maven Developer List for collaboration on improving the design?
Thank you,
Kyle Marek
[1]:
See:
https://maven.apache.org/shared/maven-filtering/apidocs/org/apache/maven/shared/filtering/MavenFileFilter.html#copyFile(java.io.File,%20java.io.File,%20boolean,%
>
> On 2019/03/24 01:45:50, Kyle Marek wrote:
>> Not sure that it will help with version number matches, but you could
>> also use Git submodules to bring multiple repositories together in a
>> single tree.
>>
>> See: https://git-scm.com/book/en/v2/Git-Tools-Subm
Not sure that it will help with version number matches, but you could
also use Git submodules to bring multiple repositories together in a
single tree.
See: https://git-scm.com/book/en/v2/Git-Tools-Submodules
On 3/23/19 9:26 PM, ga...@oedata.com wrote:
> Hi Karl,
>
> Thank you for replying on
Building the shaded module separately was my workaround for a few days.
My current workaround is to specify the intra-module dependency in my
parent pom under dependencyManagement with a list of exclusions for the
artifacts I am shading into it. Effectively I am manually "reducing" the
dependency
I am having a dependency conflict issue in a project I am working on.
Specifically, a dependency of a dependency of a dependency depends on
Jersey 1.9 for internal client purposes, while I am using Jersey 2.28 in
implementing a REST interface for the high level functionality of the
project. Since
