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
