Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
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 >> 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
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
> I doubt that uberjars should be used as dependencies at all
I disagree. There are tons of valid usage scenarios. Look at AspectJ
runtime, AspectJ tools (compiler), AspectJ weaver, dozens of Java agents
which might contain relocated classes from ASM and/or Byte Buddy etc.
You want to use those, you want to test those and consequently depend on
those. Maybe your world is as simple as your IMO over-simplifying
statement suggests, mine is not.
I really would appreciate conrete answers to my questions instead of
philosophical discussions about the Maven Way, spiced up with
suggestions to script my build, which is exactly *not* the Maven Way.
--
Alexander Kriegisch
https://scrum-master.de
Mantas Gridinas schrieb am 25.04.2021 17:24 (GMT +07:00):
> I second this approach. It's much more simple, maintainble and you retain
> the ability to monkeypatch production deployments. You can later chain it
> into assembly plugin to produce an archive that contains your launch
> scripts, dependencies, configurations, and perhaps even the JDK itself. If
> youre against having launchscripts, you can write classpath into manifest
> via archive plugin.
>
> I doubt that uberjars should be used as dependencies at all considering
> they usually suffer from split package issue. If yours doesnt, it probably
> uses some special classloader, which makes runtime much more complex than
> it needs to be.
>
> On Sun, Apr 25, 2021, 12:45 Jim N wrote:
>
>> there's nothing that really painlessly replaced the first
>> maven fatjar since it became outmoded.
>>
>> that said, i use dependency plugin to dump a lib/ dir even for reactor
>> builds, and then a shell script that uses that classpath syntax to load a
>> directory at a time.
>>
>> this happens with maven exec anyways, just less fragile.
>>
>> sometimes shade chokes on a manifest glitch and in practice fixing that is
>> less efficient than a robust lib/ dir
>>
>> in the parent-most pom if the levels go deeper, verbatim from the
>> dependency plugin docs, is
>> ```!xml
>>
>>
>> maven-dependency-plugin
>>
>>
>> install
>>
>> copy-dependencies
>>
>>
>>
>> ${project.build.directory}/lib
>>
>>
>>
>>
>> ```
>> in bin/ of the top level i have the tiniest specific bash runner, easily
>> ported to windows as well.
>>
>> ```!bash
>> #!/usr/bin/env bash
>>
>> set -fx
>> JDIR=$(dirname $0)/../apprunner
>> exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
>> ${EXECMAIN:=apprunner.MyMain} "$@"
>> ```
>>
>> often it's a helpful thing to keep these shell scripts handy to record
>> variaous -XX and -D parameters in the comments or at run time.
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
With all due respect, this is horrible. It is not just a scripted build
and like Ant through the back door, but also shell- and
platform-specific (unless you happen to have Git Bash or so installe on
Windows).
Furthermore, it does not even relate to my question.
--
Alexander Kriegisch
https://scrum-master.de
Jim N schrieb am 25.04.2021 16:45 (GMT +07:00):
> there's nothing that really painlessly replaced the first
> maven fatjar since it became outmoded.
>
> that said, i use dependency plugin to dump a lib/ dir even for reactor
> builds, and then a shell script that uses that classpath syntax to load a
> directory at a time.
>
> this happens with maven exec anyways, just less fragile.
>
> sometimes shade chokes on a manifest glitch and in practice fixing that is
> less efficient than a robust lib/ dir
>
> in the parent-most pom if the levels go deeper, verbatim from the
> dependency plugin docs, is
> ```!xml
>
>
> maven-dependency-plugin
>
>
> install
>
> copy-dependencies
>
>
>
> ${project.build.directory}/lib
>
>
>
>
> ```
> in bin/ of the top level i have the tiniest specific bash runner, easily
> ported to windows as well.
>
> ```!bash
> #!/usr/bin/env bash
>
> set -fx
> JDIR=$(dirname $0)/../apprunner
> exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
> ${EXECMAIN:=apprunner.MyMain} "$@"
> ```
>
> often it's a helpful thing to keep these shell scripts handy to record
> variaous -XX and -D parameters in the comments or at run time.
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
For executable JARs I do this as well.
Sometimes for simpler projects, I'll add:
true
lib/
to the JAR plugin. I use the assembly plugin to place everything in its
proper place.
That way I can just ship a tar.gz or zip file with all of the bits.
Unzip / untar the archive and run java -jar jarfile.jar.
Tweaks can be made to account for a bin directory, a home directory on
which to base both logging and classpath starting points, etc. That way
you can put the shell / cmd / bat file in the path, set up a location to
find other jars, and keep logging in a reasonable place.
. . . just my two cents
/mde/
On 4/25/2021 3:24 AM, Mantas Gridinas wrote:
I second this approach. It's much more simple, maintainble and you retain
the ability to monkeypatch production deployments. You can later chain it
into assembly plugin to produce an archive that contains your launch
scripts, dependencies, configurations, and perhaps even the JDK itself.
If
youre against having launchscripts, you can write classpath into manifest
via archive plugin.
I doubt that uberjars should be used as dependencies at all considering
they usually suffer from split package issue. If yours doesnt, it probably
uses some special classloader, which makes runtime much more complex than
it needs to be.
On Sun, Apr 25, 2021, 12:45 Jim N wrote:
there's nothing that really painlessly replaced the first
maven fatjar since it became outmoded.
that said, i use dependency plugin to dump a lib/ dir even for reactor
builds, and then a shell script that uses that classpath syntax to load a
directory at a time.
this happens with maven exec anyways, just less fragile.
sometimes shade chokes on a manifest glitch and in practice fixing that is
less efficient than a robust lib/ dir
in the parent-most pom if the levels go deeper, verbatim from the
dependency plugin docs, is
```!xml
maven-dependency-plugin
install
copy-dependencies
${project.build.directory}/lib
```
in bin/ of the top level i have the tiniest specific bash runner, easily
ported to windows as well.
```!bash
#!/usr/bin/env bash
set -fx
JDIR=$(dirname $0)/../apprunner
exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
${EXECMAIN:=apprunner.MyMain} "$@"
```
often it's a helpful thing to keep these shell scripts handy to record
variaous -XX and -D parameters in the comments or at run time.
OpenPGP_signature
Description: OpenPGP digital signature
Re: Scratching my head over repositories ...
Oh damn it! I should have figured that out! It now works. Thanks Anders! /Tommy Från: Anders Hammar Svara: Maven Users List Datum: 24 april 2021 at 19:43:58 Till: Maven Users List Ämne: Re: Scratching my head over repositories ... Ok, the problem is that you've declared a repository but it should be a pluginRepository as it's a plugin or a dependency of one. /Anders (mobile) Den lör 24 apr. 2021 16:36Tommy Svensson skrev: > To be clearer: > > [ERROR] Plugin > se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:2.2.2 or one > of its dependencies could not be resolved: Failure to find > se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:jar:2.2.2 in > https://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced -> [Help 1] > > Repo definition in root pom.xml: > > > ns-repo > ns-artifact-repository > https://download.natusoft.se/maven > > > From > > se.natusoft.tools.codelicmgr > CodeLicenseManager-maven-plugin > 2.2.2 > > Usage: > > > se.natusoft.tools.codelicmgr > CodeLicenseManager-maven-plugin > > > > install-licence-info > ... > And I got the version wrong in first mail, it is 2.2.2, not 2.2.1 and > 2.2.2 also does exist in my webserver repo. From CyberDuck view copy + > paste: > ... > /public_html/maven/se/natusoft/tools/codelicmgr/CodeLicenseManager/2.2.2 > > > .../public_html/maven/se/natusoft/tools/codelicmgr/CodeLicenseManager/2.2.2/_remote.repositories > > > /public_html/maven/se/natusoft/tools/codelicmgr/CodeLicenseManager/2.2.2/CodeLicenseManager-2.2.2.pom > > > .../public_html/maven/se/natusoft/tools/codelicmgr/CodeLicenseManager/2.2.2/CodeLicenseManager-2.2.2.pom.md5 > > > .../public_html/maven/se/natusoft/tools/codelicmgr/CodeLicenseManager/2.2.2/CodeLicenseManager-2.2.2.pom.sha1 > > > And yes, the rest of the artifacts are there too. > > /Tommy > > > Från: Tommy Svensson > Svara: Maven Users List > Datum: 24 april 2021 at 15:21:03 > Till: Maven Users List > Ämne: Re: Scratching my head over repositories ... > > I am using latest IDEA which supplies maven 3.6.3. > > No version ranges. > > My interpretation of > https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order > > > says that maven central is always first. > > -- > > About Maven Central: Many years ago I did submit some tools of mine to > maven central. That was a truly painful experience. I wrote a mail to this > mailing list about it where I suggested that it would be greatly beneficial > to everyone if the procedure to get artifacts to maven central was an easy > one. I only got one reply and that was from jbarush at JFrog who asked if I > was aware of Bintray. Bintray showed how easy and trivial this really > should be. I think they set a standard there. > > I recently googled about releasing to maven central thinking that it might > have improved, and it has, but not enough. > > JFrog offered free Artifactory account for open source. Artifactory also > needs its own repository and URL, there is no common like JCenter as far as > I have been able to determine. Thereby it doesn't offer more than my web > server does. And pushing to my web server is 100% painless. It does not > waste my time in any way, and I value my time. What I'm doing on GitHub is > partly for personal need/want, but mostly for fun, and then it should be > fun all the way. > > Don't misunderstand me. I'm a big fan of maven. Its only the maven central > handling that I'm in disagreement with. > > /Tommy > > > Från: Anders Hammar > Svara: Maven Users List > Datum: 22 april 2021 at 20:37:20 > Till: Maven Users List > Ämne: Re: Scratching my head over repositories ... > > But it should work. At least as long as you specify the version. > This is what we do when we create patched versions of external libraries. > We publish them to our internal repo but with the "correct" groupId and > artifactId, but a version that identifies it as patched (1.2-ISSUE123 > e.g.). I admit it's been a while since we did it the last time, but it > worked then. > > But if you're using version ranges (or even LATEST) it might not work. > But > that's a bad pattern in any case. > > /Anders > > On Thu, Apr 22, 2021 at 6:38 PM Tamás Cservenák > wrote: > > > Howdy Tommy, > > > > I think you are on a thin ice with this setup: if your artifacts are in > > Central, why not publish them in future as well? > > > > Having your "own" repo, while it seems cool at first glance, is usually > NOT > > what you want, unless you can guarantee reliability, availability and > speed > > of that of Central (or let's say 1/3 of it). > >
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
I second this approach. It's much more simple, maintainble and you retain
the ability to monkeypatch production deployments. You can later chain it
into assembly plugin to produce an archive that contains your launch
scripts, dependencies, configurations, and perhaps even the JDK itself. If
youre against having launchscripts, you can write classpath into manifest
via archive plugin.
I doubt that uberjars should be used as dependencies at all considering
they usually suffer from split package issue. If yours doesnt, it probably
uses some special classloader, which makes runtime much more complex than
it needs to be.
On Sun, Apr 25, 2021, 12:45 Jim N wrote:
> there's nothing that really painlessly replaced the first
> maven fatjar since it became outmoded.
>
> that said, i use dependency plugin to dump a lib/ dir even for reactor
> builds, and then a shell script that uses that classpath syntax to load a
> directory at a time.
>
> this happens with maven exec anyways, just less fragile.
>
> sometimes shade chokes on a manifest glitch and in practice fixing that is
> less efficient than a robust lib/ dir
>
> in the parent-most pom if the levels go deeper, verbatim from the
> dependency plugin docs, is
> ```!xml
>
>
> maven-dependency-plugin
>
>
> install
>
> copy-dependencies
>
>
>
> ${project.build.directory}/lib
>
>
>
>
> ```
> in bin/ of the top level i have the tiniest specific bash runner, easily
> ported to windows as well.
>
> ```!bash
> #!/usr/bin/env bash
>
> set -fx
> JDIR=$(dirname $0)/../apprunner
> exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
> ${EXECMAIN:=apprunner.MyMain} "$@"
> ```
>
> often it's a helpful thing to keep these shell scripts handy to record
> variaous -XX and -D parameters in the comments or at run time.
>
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
there's nothing that really painlessly replaced the first
maven fatjar since it became outmoded.
that said, i use dependency plugin to dump a lib/ dir even for reactor
builds, and then a shell script that uses that classpath syntax to load a
directory at a time.
this happens with maven exec anyways, just less fragile.
sometimes shade chokes on a manifest glitch and in practice fixing that is
less efficient than a robust lib/ dir
in the parent-most pom if the levels go deeper, verbatim from the
dependency plugin docs, is
```!xml
maven-dependency-plugin
install
copy-dependencies
${project.build.directory}/lib
```
in bin/ of the top level i have the tiniest specific bash runner, easily
ported to windows as well.
```!bash
#!/usr/bin/env bash
set -fx
JDIR=$(dirname $0)/../apprunner
exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
${EXECMAIN:=apprunner.MyMain} "$@"
```
often it's a helpful thing to keep these shell scripts handy to record
variaous -XX and -D parameters in the comments or at run time.
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
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. -- Alexander Kriegisch https://scrum-master.de 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 > 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. >> >> -- >> 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
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
Those artifacts go to Maven Central in case of a release. Even for snapshots I need to "fret over" them, because if another Maven project depends on such an artifact, it gets unnecessary transitive dependencies. You can trust that I am not raising a non-issue here, but thanks for the comment. -- Alexander Kriegisch https://scrum-master.de Mantas Gridinas schrieb am 25.04.2021 13:25 (GMT +07:00): > 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 > 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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
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 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. > > -- > 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 > >
Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade
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 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
