'could not find or load ${start-class}' when trying this with spring boot pet clinic

to reproduce: try out: $ git clone https://github.com/spring-projects/spring-petclinic.git $ cd spring-petclinic $ ./mvnw spring-boot:run

modify pom.xml to include

       <plugin>
            <groupId>com.google.cloud.tools</groupId>
            <artifactId>jib-maven-plugin</artifactId>
            <version>0.1.4</version>
            <configuration>
                <registry>gcr.io</registry>
                <repository>your project/app/repository>
            </configuration>
        </plugin>

mvnw compile jib:build docker pull and run

see: ‘could not find or load ${start-class}’

[coollog]

1. For this, we could either check if the main class we detect is a valid Java class qualifier (something like ([a-z]+\.?)+), or check explicitly for any ${...} in it (indicating some unresolved Maven property).

2. From https://spring.io/guides/gs/spring-boot/, It looks like Spring Boot Maven plugin searches for the class to run as the main class by looking for a class with public static void main(), although it seems that defining a start-class property is the recommended way (https://www.mkyong.com/spring-boot/spring-boot-which-main-class-to-start/, https://stackoverflow.com/questions/23217002/how-do-i-tell-spring-boot-which-main-class-to-use-for-the-executable-jar/31040641). We could potentially also try looking for a class with public static void main() and use that as the default main class.

[coollog]

There is still the problem of when to do the main method search.

If we do the search after inferring from the jar plugin, this issue still happens since Spring boot is actually setting the jar plugin’s main class to ${start-class}.

If we do the search before the jar plugin, we may have the user experience a difference between running their jar and running the jibbed image.

We might still need logic to detect if the main class is a valid java class.