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

[patflynn]

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]

I believe this is due to there not being a default main class provided (the spring-petclinic doesn't seem to package an executable JAR and thus, we don't find a Main-Class attribute in the maven-jar-plugin). Therefore, Spring may be setting ${start-class} as the main class for maven-jar-plugin, but since start-class is not defined, it doesn't get resolved. I tried adding <start-class>org.springframework.samples.petclinic.PetClinicApplication</start-class> in the pom.xml properties and it seems to have worked.

Alternatively, one could explicitly pass in the main class to the jib-maven-plugin configuration.

[patflynn]

two things: 1) when we fail to discover it we should fail the build, not produce an entrypoing that still has the placeholder. 2) what could we do to make this automatic? Scan for `@SpringBootApplication`? That would probably slow things down. Is the spring boot build plugin doing something that we can inspect?

…

On Wed, Mar 14, 2018 at 4:04 PM Qingyang Chen ***@***.***> wrote: I believe this is due to there not being a default main class provided (the spring-petclinic doesn't seem to package an executable JAR and thus, we don't find a Main-Class attribute in the maven-jar-plugin). Therefore, Spring may be setting ${start-class} as the main class for maven-jar-plugin, but since start-class is not defined, it doesn't get resolved. I tried adding <start-class>org.springframework.samples.petclinic.PetClinicApplication</start-class> in the pom.xml properties and it seems to have worked. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#170 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHf5Ha_ruOSvA-MNS3jr7DBUksNLjMVtks5teXe2gaJpZM4SrBRg> .

[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.

[loosebazooka]

So 2 would look for a single main class? and fail if multiple are found?

[coollog]

@loosebazooka Yes

[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.