Expose classpath, main class, and other variables for reference from an explicit entrypoint

[briandealwis]

Following on to #579 where it would be useful to be able to somehow reference the computed classpath from within an entrypoint definition.

For example, on Gradle:

jib {
  container {
    entrypoint = ['/opt/startup.sh', '-classpath', classpath.join(':'), '-jvmflags', '"' + jvmFlags.join(' ') + '"']
  }
}

Would we want users to be able to change the classpath?
Should we expose the computed main-class?

[remmeier]

in Gradle the correct behavior would be to set custom Configuration, e.g.

configurations {
    something
}

dependencies{
  something '...'
}

jib.configuration = configurations.something.

or with source sets like:

jib.sourceset = ...

The configuration can then be customized, inherited from other configurations, etc.

but have not seen something suggesting for this to currently be possibe. In GradleLayerConfigurations things is hardcoded to go for the main source set and its classpath. For our use case we would like to change that completely, not just extending it because the image is only a "by-product" of something else and currently we are forced to setup an additional project next to it to build the image.

[briandealwis]

As I understand them, @remmeier, source-sets are for collecting groups of Java source files, whereas this PR is at least to simplify adding other jars or directories, for things like JVM agents, to the classpath in the container image. Which is not to say that supporting source-sets are not applicable. I'm a relative newbie to Gradle, so would you mind describing what you want to do, and why you want to do it that way?

[loosebazooka]

@remmeier .. to further what @briandealwis said: we are just allowing further customization of the classpath part of the final entrypoint we generate for the container image.

[remmeier]

@briandealwis : sourceSets is not just about sources. It is also backed by configurations that specify how to compile and run the sources, like "test" sourcesets having "testCompile" and "testRuntime" configurations. Together they make up the application. That is what is used to do the packaging in Jib as far as I have seen in the GradleLayerConfigurations. So it would be a good step to make that configurable. This way one can influence what JARs get packaged and added to the classpath. That is probably sufficient for 95% of the classpath manipulation use cases.

Then there are of course other JVM things like adding agents, etc. That is something not covered by the sourcesets/configurations. JavaExecSpec might be a good inspiration for that area. Or may even make use of it.

[chanseokoh]

@remmeier to further clarify @briandealwis' and @loosebazooka's point, this issue is about the potential capability for the users to add arbitrary paths to the runtime classpath of the image. These additional paths may not be the project-level or build-time Gradle classpath/dependencies or the path for Gradle sources. They may be completely independent of Gradle (such as /volume/dynamic). Looks like you are describing a different feature request. If so, could you create a new issue describing all the details? (Some of us are not Gradle experts, especially in idiomatic/best-practice usage).