Re: Configuring plugins by composition rather than inheritance
Hello, I think that’s a long-standing restriction of mavens Pom-model, not sure it can easily be solved. Spring boot (and other frameworks) did not make the situation easier with their parent requirement (but then again there is not much alternatives). >From my experience it seems a good idea to get away from a strict „simple >company root“ requirement. (Due to release cycles it doesn’t do much for >unifying build jobs anyway). Maven could improve with importing build/plugin sections like BOMs. I haven’t seen much talk about that in recent 4.0 discussions, Having said that a consumer Pom goes a good distance to make the parents less relevant. (Especially licensing/orga matters) Gruß Bernd Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00): > In my current project i'm working we already have a parent POM that I > should be inheriting from, but when trying to integrate the spring boot I > come into an issue that I should inherit their super pom instead of using > our own. For dependencies its pretty simple - you use the import scope, > but > what about plugins? I'm seeing some stackoverflow posts about the sameish > issue from 11 years ago that the suggestion was to use tiles plugin. Was > there any movement regarding this in the mean time? > > As a workaround I currently have a dedicated springboot runtime module > that > includes a single entry point with respective annotations to start the > application, and it directly inherits the spring boot super pom while > importing our dependencies via the depencendy management block but having > a > submodule not inherit a parent module feels weird > Gruß Bernd — https://bernd.eckenfels.net - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Configuring plugins by composition rather than inheritance
Howdy, For importing plugins there was even some PoC like this: https://github.com/apache/maven/pull/1190 Also, planned for maven4 to (or already is, Guillaume?) support mixins. HTH T On Tue, Dec 5, 2023 at 12:51 PM Bernd Eckenfels wrote: > Hello, > > I think that’s a long-standing restriction of mavens Pom-model, not sure > it can easily be solved. Spring boot (and other frameworks) did not make > the situation easier with their parent requirement (but then again there is > not much alternatives). > > From my experience it seems a good idea to get away from a strict „simple > company root“ requirement. (Due to release cycles it doesn’t do much for > unifying build jobs anyway). > > Maven could improve with importing build/plugin sections like BOMs. I > haven’t seen much talk about that in recent 4.0 discussions, > > Having said that a consumer Pom goes a good distance to make the parents > less relevant. (Especially licensing/orga matters) > > Gruß > Bernd > > Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00): > > > In my current project i'm working we already have a parent POM that I > > should be inheriting from, but when trying to integrate the spring boot I > > come into an issue that I should inherit their super pom instead of using > > our own. For dependencies its pretty simple - you use the import scope, > > but > > what about plugins? I'm seeing some stackoverflow posts about the sameish > > issue from 11 years ago that the suggestion was to use tiles plugin. Was > > there any movement regarding this in the mean time? > > > > As a workaround I currently have a dedicated springboot runtime module > > that > > includes a single entry point with respective annotations to start the > > application, and it directly inherits the spring boot super pom while > > importing our dependencies via the depencendy management block but having > > a > > submodule not inherit a parent module feels weird > > > > > Gruß > Bernd > — > https://bernd.eckenfels.net > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Configuring plugins by composition rather than inheritance
For the record, Spring Boot has no hard requirement of using a 'parent' pom. It is just a bit simpler and in most of the examples online. But you can simply set the scope import in your dependencyManagement. This works. org.springframework.boot spring-boot-dependencies ${spring.boot.version} pom import Hope it helps Le mar. 5 déc. 2023 à 12:51, Bernd Eckenfels a écrit : > Hello, > > I think that’s a long-standing restriction of mavens Pom-model, not sure > it can easily be solved. Spring boot (and other frameworks) did not make > the situation easier with their parent requirement (but then again there is > not much alternatives). > > From my experience it seems a good idea to get away from a strict „simple > company root“ requirement. (Due to release cycles it doesn’t do much for > unifying build jobs anyway). > > Maven could improve with importing build/plugin sections like BOMs. I > haven’t seen much talk about that in recent 4.0 discussions, > > Having said that a consumer Pom goes a good distance to make the parents > less relevant. (Especially licensing/orga matters) > > Gruß > Bernd > > Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00): > > > In my current project i'm working we already have a parent POM that I > > should be inheriting from, but when trying to integrate the spring boot I > > come into an issue that I should inherit their super pom instead of using > > our own. For dependencies its pretty simple - you use the import scope, > > but > > what about plugins? I'm seeing some stackoverflow posts about the sameish > > issue from 11 years ago that the suggestion was to use tiles plugin. Was > > there any movement regarding this in the mean time? > > > > As a workaround I currently have a dedicated springboot runtime module > > that > > includes a single entry point with respective annotations to start the > > application, and it directly inherits the spring boot super pom while > > importing our dependencies via the depencendy management block but having > > a > > submodule not inherit a parent module feels weird > > > > > Gruß > Bernd > — > https://bernd.eckenfels.net > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Configuring plugins by composition rather than inheritance
This only imports Spring Boot dependencyManagement, and it looks like the thread starter would also like access to the plugins configured by spring-boot-parent. He’d have to duplicate Spring Boot's plugin configuration in his own project. Nils. > Op 5 dec 2023, om 15:11 heeft Francois Marot het > volgende geschreven: > > For the record, Spring Boot has no hard requirement of using a 'parent' > pom. It is just a bit simpler and in most of the examples online. > But you can simply set the scope import in your dependencyManagement. This > works. > > > > > > org.springframework.boot > > spring-boot-dependencies > > ${spring.boot.version} > > pom > > import > > > > > Hope it helps > > > > Le mar. 5 déc. 2023 à 12:51, Bernd Eckenfels a > écrit : > >> Hello, >> >> I think that’s a long-standing restriction of mavens Pom-model, not sure >> it can easily be solved. Spring boot (and other frameworks) did not make >> the situation easier with their parent requirement (but then again there is >> not much alternatives). >> >> From my experience it seems a good idea to get away from a strict „simple >> company root“ requirement. (Due to release cycles it doesn’t do much for >> unifying build jobs anyway). >> >> Maven could improve with importing build/plugin sections like BOMs. I >> haven’t seen much talk about that in recent 4.0 discussions, >> >> Having said that a consumer Pom goes a good distance to make the parents >> less relevant. (Especially licensing/orga matters) >> >> Gruß >> Bernd >> >> Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00): >> >>> In my current project i'm working we already have a parent POM that I >>> should be inheriting from, but when trying to integrate the spring boot I >>> come into an issue that I should inherit their super pom instead of using >>> our own. For dependencies its pretty simple - you use the import scope, >>> but >>> what about plugins? I'm seeing some stackoverflow posts about the sameish >>> issue from 11 years ago that the suggestion was to use tiles plugin. Was >>> there any movement regarding this in the mean time? >>> >>> As a workaround I currently have a dedicated springboot runtime module >>> that >>> includes a single entry point with respective annotations to start the >>> application, and it directly inherits the spring boot super pom while >>> importing our dependencies via the depencendy management block but having >>> a >>> submodule not inherit a parent module feels weird >>> >> >> >> Gruß >> Bernd >> — >> https://bernd.eckenfels.net >> >> - >> 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