POM is only relevant if you're deploying that archive to a repository. I wouldn't fret myself over it if you're not deploying the uberjars to nexus.
On Sun, Apr 25, 2021 at 2:09 AM Alexander Kriegisch <alexan...@kriegisch.name> wrote: > > I am sorry if I am asking a question the answer to which might be obious > to others, but for a long time I have wondered why I do not find any > examples for the following use case which IMO is probably quite common: > > ** I build an uber JAR containing some module dependencies, possibly > also transitive ones. This could be done using Maven Shade or Maven > Assembly, maybe even something with nested JARs like One-JAR. > ** The built uber JAR replaces the module's original artifact when > installed and/or deployed. > ** By default, the original POM gets attached to the build. This is > undesirable, because the uber JAR no longer depends on those > dependencies. They are only needed in the POM during the build as > such in order to be able to include them in the uber JAR at all. > > My question: How do I automatically create and attach a > dependency-reduced POM to the build, replacing the original POM? > Ideally, I would have options to also filter out other POM elements such > as repositories, but that is optional and not the main scope of this > question. > > Presently, I use Flatten Maven Plugin for this purpose. For certain > reasons, I am not very happy with it because it requires extra work, it > mutilates my POMs with regard to formatting and removing things I do not > wish to be removed, but it works. > > I also know that Maven Shade automatically creates a dependency-reduced > POM if not told otherwise. But that POM is not attached to the build. > Maybe I could do so using Build Helper, but both Flatten Maven and Build > Helper seem like crutches, and I cannot help but wonder which built-in > Maven functionality escaped my attention so far. Is there a canonical > way to do that, such as resource filtering? Can I even apply that to > POMs? I feel like I might be doing something phenomenally stupid, > possibly missing a more straightforward way of solving this problem. > > -- > Alexander Kriegisch > https://scrum-master.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
