Add configuration to expose Inferred mainClass to container ENV

[eisig]

Is It possible to expose Inferred mainClass as container ENV? I want to use the Inferred mainClass in my own entrypoint, so I don't have to config the main class in the pom.

[loosebazooka]

Can you explain this a little more, perhaps with an example so we can understand the issue better?

[eisig]

I use the entrypoint from the base image, where we add some common options and start the app:
java $MY_OPTIONS -cp /app/resources:/app/classes:/app/libs/* $MAIN_CLASS
I need to defined the properties start-class every project .

   <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>1.1.1</version>
                <configuration>
                    <from>
                        <image>${container.from}</image>
                    </from>
                    <to>
                        <image>${container.from}</image>
                    </to>
                    <container>
                        <entrypoint>INHERIT</entrypoint>
                        <environment>
                            <MAIN_ClASS>${start-class}</MAIN_ClASS>
                        </environment>
                    </container>
                </configuration>
            </plugin>

But the jib already can infer the main class. So It would be more convenient to add an option to export it to the container.

1. refer as special value like INHERIT: <MAIN_ClASS>JIB_MAIN_CLASS</MAIN_ClASS>`
2. or add a configuration
3. or just add predefined ENV

[rajetta]

I think this is a valid use case. @briandealwis @eisig can you add notes on why it is closed? Do you have a workaround?

[briandealwis]

@rajetta could you please describe your situation? We have discussed about exposing some of Jib's computed information.

[rajetta]

@briandealwis My situation is similar to @eisig. Currently, we use fabric8 and parent project with an entrypoint shell script , which runs the Springboot jar file. The jar file is inferred based on the project name. Migrating it to jib, this is what I have in the child project. If I can infer the mainClass, then I can move it to the parent project.

    <extraDirectories>
            <paths>${project.basedir}/src/main/jib</paths>
            <permissions>
                    <permission>
                            <file>/java_entrypoint.sh</file>
                            <mode>755</mode> 
                    </permission>
            </permissions>
    </extraDirectories>
    <container>
            <entrypoint>
                    <arg>/java_entrypoint.sh </arg>
                    <arg>com.oracle.acs.usermgmt.UserMgmtApplication</arg>
<!-- this is what I want to avoid. java_entrypoint.sh needs this Main class name to start the app.  -->
            </entrypoint>
    </container>

[briandealwis]

@eisig Can you sketch out what your entrypoint script is doing? Just so we can understand why existing mechanisms are insufficient. We're contemplating adding support for surefire-style @{property} resolving (e.g., @{jib.container.mainClass}).

[eisig]

My situation is Similar to @rajetta. Adding @{jib.container.mainClass} is sufficient for this situation.
At the end of my entrypoint script well call
exec java $MY_OPTIONS -cp $MY_CLASS_PATH $MAIN_CLASS

I closed this issue because I still need some features that should not be implemented in jib, so I wrote my own maven plugin to set up some maven properties.
Most of our projects are multi-moudle, we need to decide whether we need to skip jib according to some conditions. For example, whether it is a war package, whether there is a main class, whether ci.yaml has a specified configuration.

I add this to our projects common parent pom

       <plugin>
               <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <configuration>
                    <skip>${jib.skip}</skip>
                    <from>
                        <image>${jib.from}</image>
                    </from>
                    <to>
                        <image>${docker.prefix}/${project.name}:${docker.tag}</image>
                    </to>
                    <container>
                        <entrypoint>INHERIT</entrypoint>
                        <environment>
                            <MAIN_CLASS>${start-class}</MAIN_CLASS>
                            <APP_NAME>${project.name}</APP_NAME>
                        </environment>
                    </container>
                </configuration>
            </plugin>

I will set jib.skip, jib.from, start-class in that plugin.

[ccjeaty]

@eisig Can you sketch out what your entrypoint script is doing? Just so we can understand why existing mechanisms are insufficient. We're contemplating adding support for surefire-style @{property} resolving (e.g., @{jib.container.mainClass}).

think about this. i want to use wait-for-it to control container startup order. how can i do?

[chanseokoh]

I think #894 subsumes this issue: #894 (comment)

Closing.

[chanseokoh]

@eisig @ccjeaty @rajetta @tomikmar @davidk81

We just released Jib 3.1.1, and note that #894 is closed. Check out the resolution there: #894 (comment)