Re: Offloading projects cli flag into profile
Ah, rereading the message it does feel it's unclear.
Basically, I would like to execute a plugin goal only on particular modules
which it is present on. The current way I do it fails the build because the
spring-boot plugin is not present on all the modules. But you did push me
towards the right direction - I can configure the plugin to get executed in
packaging phase via executions declaration on those modules. That way I do
not need to invoke that phase again only for the particular spring boot
entrypoints.
Cheers!
On Thu, Mar 21, 2024 at 8:11 PM Francois Marot
wrote:
> Hello Mantas,
>
> I think you did not explain what you are trying to achieve. Or at least I
> did not really understand.
> Are you trying to lower the build time ?
> If yes, then I would advise to use a Maven property for the configuration
> in the root pom
> Then most of your build could be run with -DskipRepackage=true and only
> some could use -DskipRepackage=false
>
>
>
>
> org.springframework.boot
> spring-boot-maven-plugin
> x.y.z
>
>
> repackage
>
> repackage
>
>
> ${skipRepackage}
>
>
>
>
>
>
> François
>
>
> Le jeu. 21 mars 2024 à 13:43, Mantas Gridinas a
> écrit :
>
> > I have several spring boot applications in my reactor that need to be
> > repackaged before deployment. Only those spring boot modules have
> reference
> > to the spring boot plugin.
> >
> > My current approach is to build the entire reactor (via install goal),
> and
> > later run repackaging goal only on particular spring boot modules like
> > follows
> >
> > mvn install
> > mvn package spring-boot:repackage --projects
> > springboot1,springboot2,springboot3
> >
> > Can the projects list be offloaded into profile configuration? I have a
> > feeling the spring boot entrypoints will only proliferate in the future
> and
> > would rather modify that list via pom rather than the multiple
> > pipelines/cicd applications. I suppose workaround would be to manage a
> > second pom which only lists those modules but then things might get hairy
> > with parent references.
> >
>
--
// Mantas
Re: Offloading projects cli flag into profile
Hello Mantas,
I think you did not explain what you are trying to achieve. Or at least I
did not really understand.
Are you trying to lower the build time ?
If yes, then I would advise to use a Maven property for the configuration
in the root pom
Then most of your build could be run with -DskipRepackage=true and only
some could use -DskipRepackage=false
org.springframework.boot
spring-boot-maven-plugin
x.y.z
repackage
repackage
${skipRepackage}
François
Le jeu. 21 mars 2024 à 13:43, Mantas Gridinas a
écrit :
> I have several spring boot applications in my reactor that need to be
> repackaged before deployment. Only those spring boot modules have reference
> to the spring boot plugin.
>
> My current approach is to build the entire reactor (via install goal), and
> later run repackaging goal only on particular spring boot modules like
> follows
>
> mvn install
> mvn package spring-boot:repackage --projects
> springboot1,springboot2,springboot3
>
> Can the projects list be offloaded into profile configuration? I have a
> feeling the spring boot entrypoints will only proliferate in the future and
> would rather modify that list via pom rather than the multiple
> pipelines/cicd applications. I suppose workaround would be to manage a
> second pom which only lists those modules but then things might get hairy
> with parent references.
>
Offloading projects cli flag into profile
I have several spring boot applications in my reactor that need to be repackaged before deployment. Only those spring boot modules have reference to the spring boot plugin. My current approach is to build the entire reactor (via install goal), and later run repackaging goal only on particular spring boot modules like follows mvn install mvn package spring-boot:repackage --projects springboot1,springboot2,springboot3 Can the projects list be offloaded into profile configuration? I have a feeling the spring boot entrypoints will only proliferate in the future and would rather modify that list via pom rather than the multiple pipelines/cicd applications. I suppose workaround would be to manage a second pom which only lists those modules but then things might get hairy with parent references.
