jboss-openshift / cct_module Goto Github PK

jboss-container-images/openjdk#75

log show JAVA_ARGS in command line but runtime without JAVA_ARGS

https://github.com/jboss-openshift/cct_module/blob/master/jboss/container/java/run/bash/artifacts/opt/jboss/container/java/run/run-java.sh#L241

"cct_module" is just confusing and weird. I think we should rename it "CekitModules" or similar. We could also take the opportunity to move it to the jboss-container-images organisation, since all its consumers are there, although that's less of a big deal.

If we did that ,we could leave this repo in stasis for a while until we were absolutely sure all supported images were using the new URI. And we would then get rid of the long tail of open PRs to review, and we could not move over all the various deprecated legacy module paths.

Analysing my logs I found a message like "INFO exec java ..." with error level. After some investigation I found out that it's because of the log_info function implementation:

Is there a reason the library does this way or it's a defect? Thanks in advance.

I would like to look at a scheme where we do not commit auto-generated documentation into this repository, but instead populate a separate repository with auto-generated documentation and generate a website (github pages perhaps) from that. We could set up a CI to automate the process. Travis CI or whatever.

With the OpenJDK RHEL8/JDK11 image, on start up, one gets the following error

/usr/local/s2i/run: line 15: /opt/jboss/container/maven/default//scl-enable-maven: No such file or directory

The image uses the following modules at the top level (image):

  install:
  - name: jboss.container.openjdk.jdk
    version: "8"
  - name: jboss.container.java.s2i.bash
  - name: jboss.container.openjdk.jdk
    version: "11"
  - name: jboss.container.maven.35.bash
    version: "3.5"

Cekit (3.4.0) unravels this to the following full list

jboss.container.java.jvm.api     jboss.container.maven.35.bash       jboss.container.prometheus.bash
jboss.container.java.jvm.bash    jboss.container.maven.api           jboss.container.proxy.api
jboss.container.java.proxy.bash  jboss.container.maven.default.bash  jboss.container.s2i.core.api
jboss.container.java.run.bash    jboss.container.maven.s2i.api       jboss.container.s2i.core.bash
jboss.container.java.s2i.bash    jboss.container.maven.s2i.bash      jboss.container.user
jboss.container.jolokia.api      jboss.container.openjdk.jdk         jboss.container.util.logging.bash
jboss.container.jolokia.bash     jboss.container.prometheus.api

the script jboss/container/java/s2i/bash/artifacts/usr/local/s2i/run contains the following

# XXX: Not sure why we need to setup maven, but this was part of the old s2i-setup script, so...
source "${JBOSS_CONTAINER_MAVEN_DEFAULT_MODULE}/scl-enable-maven"

(that comment looks suspicious)

the var JBOSS_CONTAINER_MAVEN_DEFAULT_MODULE is not set in that script. It's defined as set in jboss/container/maven/default/bash/module.yaml, so it's set by the build process (in the Dockerfile) to /opt/jboss/container/maven/default/.