As promised, some more feedback: Thomas is right, I was wrong. Maven Shade does attach the DRP, I just did not use it because it is created by default in the base directory, not in the build directory, which causes extra hoops to jump through concerning Maven Clean and .gitignore. The output directory for the DRP can be adjusted, but the help text warns about an open issue of 9+ years which leads to follow-up problems, because under the hood it modifies the base directory, which is of course counter-productive. So yes, Thomas, the DRP can be made to get attached to the build, there is just a extra Git and Maven configuration work to be done in order to get a clean solution. The Maven Flatten solution I use now for this purpose does not have such issues AFAIK, but is ugly for other reasons, like I said (POMs getting mutilated pretty much outside of user control). Alas, the world is not perfect.
Still hoping for a more generic way to produce a DRP also for other plugins such as Assembly. But we are making progress. :) -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 25.04.2021 15:29 (GMT +07:00): > Last time I checked, Maven Shade did *not* attach the dependency-reduced > POM, but that was a while ago and the project I am contributing to uses > Maven Assembly. I am certainly going to try again later today or > tomorrow when I back at my desk and have access to my computer. I shall > report back here, then. Thanks for the hint. :-) > > I would still be grateful for other hints, too, ideally also some which > work for Assembly or One-JAR, i.e. independently of a specific plugin. > Plugin-specific is welcome too, though, because every partial solution > can be a step forward or a reason to debate with co-developer to favour > one plugin over others. > > > Thomas Broyer schrieb am 25.04.2021 15:05 (GMT +07:00): > >> Well, maven-shade-plugin does "attach" the dependency-reduced POM: >> https://github.com/apache/maven-shade-plugin/blob/768092f38b0b1650217642cf10b7b0c381cbf707/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1191 >> At least when you install or deployed, that POM gets installed/deployed >> rather than the original one. >> >> Le dim. 25 avr. 2021 à 04:09, Alexander Kriegisch <alexan...@kriegisch.name> >> a écrit : >> >>> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
