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 <francois.ma...@gmail.com>
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
>
> <pluginManagement>
> <plugins>
> <plugin>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-maven-plugin</artifactId>
> <version>x.y.z</version>
>
> <execution>
> <id>repackage</id>
> <goals>
> <goal>repackage</goal>
> </goals>
> <configuration>
> <skip>${skipRepackage}</skip>
> </configuration>
> </execution>
> </plugin>
> </plugins>
> </pluginManagement>
>
> François
>
>
> Le jeu. 21 mars 2024 à 13:43, Mantas Gridinas <mgridi...@gmail.com> 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
