Flyway db migrate first for Dependent Jar - Spring boot

I have a spring boot base project built as a jar. This jar base-0.0.1-SNAPSHOT.jar file has flyway migration scripts in db/migration/*.sql

This base-0.0.1-SNAPSHOT.jar is added as dependency in impl-0.0.1-SNAPSHOT-boot.jar . Again, this impl boot jar is having flyway migration in db/migration/*.sql.

The base jar's flyway migration creates the table and the impl boot jar alters the same table created by base jar.

In this scenario I need base jar's flyway scripts to be run first and then impl boot jar has to be followed,

Migration scripts in base jar

> db/migration/v1__create.sql,
db/migration/v2__create.sql

Migration scripts in impl jar

> db/migration/v3__create.sql

While mvn clean install of impl jar, I am getting this error

> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'flywayInitializer' defined in class path
> resource
> [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]:
> Invocation of init method failed; nested exception is
> org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateException:
> Migration V3__create.sql failed
> ------------------------------- SQL State : 42S02 Error Code : 42102
> Message : Table "BASE_TABLE" not found; SQL statement:

I have added migration scripts in the base jar package, but still the base jar's flyway scripts are not executed.

How to execute the base package flyway script first and then impl boot jar's next during mvn build of impl boot jar.?

Update 1:

The base jar is packaged as part of another spring boot application by below plugin,

> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>jar</goal>
> </goals>
> <phase>package</phase>
> <configuration>
> <classifier>com</classifier>
> <includes>
> <include>/entities/*</include>
> <include>/services/</include>
>
> <include>${basedir}/src/main/resources/db/migration/</include>
> </includes>
> </configuration>
> </execution>
> </executions> </plugin>

The pom.xml of impl jar has

> <dependency> <groupId>com.group</groupId>
> <artifactId>base</artifactId> <version>0.0.1-SNAPSHOT</version>
> <classifier>com</classifier> </dependency>

In Both the poms there is nothing related to flyway migration configuration mentioned. By default it used default flyway configuration.

I assume that the "base" project jar artifact itself is not a spring boot application by itself, I mean it is not created with spring-boot-maven-plugin, because if otherwise it can't be included as a dependency in the impl-boot module (because spring boot application is not really a jar - so it doesn't work)

Based on that assumption, flyway scans your jars and "classes" folder and looks for migrations purely in runtime. This means that there should be any difference between migrations from base and impl - as longs as they're in the classpath in the predefined places.
If base's migrations are not found, then the following is possible (out of my head, I might be missing something but hopefully it will provide some direction for investigation ):

1. Base jar is not packaged properly, open up the artifact in Winrar/Winzip and make sure that the migrations are indeed in accordance to the required layout.
2. The jar is not packaged properly into the spring boot application. Dependent Jars in the application are usually found in BOOT-INF/lib folder so make sure it really appears there.
3. Flyway migration locations are messed up. Spring boot can contain various flyway definitions in application.properties / application.yml, see here, especially property spring.flyway.locations.
4. Maybe the schemas of the database are messed up, in general flyway migrations should not contain the schema name, but this generally depends on many other factor so I mention it only as a general direction
5. Last but not the least, you can place a breakpoint in the code that actually executes the migrations: See here and see what migrations have been resolved by debugging