CircleCI-Public / cimg-openjdk

The CircleCI OpenJDK (Java) Docker Convenience Image.
https://circleci.com/developer/images/image/cimg/openjdk
MIT License
18 stars 25 forks source link

Java LTS Plus Latest versions #83

Closed nhojpatrick closed 2 years ago

nhojpatrick commented 3 years ago

Have both Java 1.8, 11 and 16 installed, some projects might need this more and more as they transition from Java 1.8, to 11 and beyond.

Not sure if worked correctly, and another image stream might be useful to have 1.8, 11 and the latest currently 16, maybe also with 17-ea. When when 17 LTS is released, it would have 17 added and 18-ea.

FelicianoTech commented 3 years ago

Hi @nhojpatrick,

I have a comment and a question. For the comment, when we make changes to Convenience Images we don't alter existing images. Thus changes directly to a Dockerfile is usually incorrect. You can look at the readme for more information on this.

As for my question, can you please elaborate on what your actual request is? I want to make sure I understand. I'm thinking maybe, you're looking to have an LTS tag available for OpenJDK images? Instead of specifying a specific image?

nhojpatrick commented 3 years ago

Hi @nhojpatrick,

I have a comment and a question. For the comment, when we make changes to Convenience Images we don't alter existing images. Thus changes directly to a Dockerfile is usually incorrect. You can look at the readme for more information on this.

As for my question, can you please elaborate on what your actual request is? I want to make sure I understand. I'm thinking maybe, you're looking to have an LTS tag available for OpenJDK images? Instead of specifying a specific image?

I want to make extra symlinks and without changing the Dockerfile I'm not sure how to do that, as being discussed in https://github.com/CircleCI-Public/cimg-openjdk/pull/81

My end goals is something like;

1) static locations for tooling like maven toolchain so it doesn't need to be altered for minor releases. e.g. the path /dir/openjdk-11 links to jdk 11.0.10, and when upgrade to jdk 11.0.100 the symlink still works so a toolchain won't need upgrade per jdk release as current is needed.

2) java 8 is available again as it's still a LTS version

3) LTS image has Java 8, Java 11 and Java 17, so builds can build on x and test on y. i.e. to aid moving from Java 8 to 17.

4) LTS Plus image has Java 8, Java 11, Java 17 and the latest Java x ea release, same as point 3 but could also check code compiles against latest early access release too.

FelicianoTech commented 3 years ago

I'm not understanding.

  1. Within an image, the locations are static. They don't move. You can always use $JAVA_HOME and that points to where the JDK is, in every image.
  2. OpenJDK v8 has always been available on CircleCI. It didn't go anywhere. You can use cimg/openjdk:8.0 to get the latest version we offer,
  3. This sounds like you're referring to more than one JDK version in a single image. We don't support that.
nhojpatrick commented 2 years ago

I'm not understanding.

  1. Within an image, the locations are static. They don't move. You can always use $JAVA_HOME and that points to where the JDK is, in every image.
  2. OpenJDK v8 has always been available on CircleCI. It didn't go anywhere. You can use cimg/openjdk:8.0 to get the latest version we offer,
  3. This sounds like you're referring to more than one JDK version in a single image. We don't support that.

So point 1, yes $JAVA_HOME might be available, but Maven ToolChain can't use it. See https://maven.apache.org/ref/3.8.4/maven-core/toolchains.html So having a static location within the point version helps. See these commits as examples of what i need to manually update, each time a new image is released;

Regarding point 2, your right i'm still seeing new images, but looking at the commits, pr and trying to understand your scripts it appeared like you stopped supporting java 8.

Regarding point 3, so with java 9 and it's multi release jar support, i want to cross compile and tests without having to publish or cache jars between jobs.