Distribute via Maven repo about corretto-8 HOT 4 CLOSED

I have been looking for similar examples of the JRE as a Maven package but haven't seen them so far.

The things I was interested in are:

1. Do you expect this JRE to be used only for runtime or also for test?
2. How does a customer validate the JRE and the JDK used for build match?
3. Do you have an example package and project or a prototype showing how this would work?
4. Why do you suggest hosting the package in an Amazon repository rather than a public repository like Maven Central?

from corretto-8.

Do you expect this JRE to be used only for runtime or also for test?

Only for runtime.

How does a customer validate the JRE and the JDK used for build match?

Don't understand. Who is "customer" ?
The point of embedding a JRE with the product shipped to the customer is so that customer (end user) doesn't have to deal with any prerequisites. Therefore he doesn't "validate" anything. He doesn't even (need to) know that there's a Java runtime in the software he's using.

Do you have an example package and project or a prototype showing how this would work?

Well, what happens at the moment is that we manually download the JRE from Oracle in tgz or zip format. We then remove certain things we're allowed to remove according to their license, such as JavaFX. This is done to make the footprint smaller. Then we upload to our internal Maven Repo in zip format. This whole download-from-Oracle-and-upload-to-internal-repo is manual and error prone.

We use a naming scheme for the Maven coordinates which is consistent and which embeds information like OS, CPU arch, bitness and features we've removed from the JRE distribution (e.g "MinusJavaFX"). It doesn't matter exactly what this naming scheme looks like as long as information can be derived from it in a consistent manner.

Our build farm is Linux only, yet it builds packages for Windows, MacOSX and Linux. The build farm looks into the Maven Repo to find the correct JRE to embed. The actual process of "embedding" is custom as there's no standard in the market for it. It of course has to play with whatever application launcher you're using.

The point here is to have the JRE (or even the JDK) in a Maven Repo to begin with. That would greatly simplify our process. How you go about the actual embedding process will always be custom, I think, so not something Corretto is expected to help with.

Why do you suggest hosting the package in an Amazon repository rather than a public repository like Maven Central?

Doesn't matter as long there's a certain trust that the binaries in the repo (i.e. the JRE) doesn't contain virus, etc. In this respect I would probably favor a special/dedicated Corretto Maven Repo (by Amazon) over Maven Central as I'm not sure what Sonatype's process is for verifying uploaded binaries. This being said, this may solely be my ignorance. Perhaps Maven Central is just as safe as anything Amazon-hosted?

from corretto-8.

We do something similar for our netbeans and our eclipse products. We create maven artifacts for our local repo and download them with the maven dependency plugin. The jre is then shipped together with the product and the customer does not need to worry about the jre (and we don't have to worry aboout JAVA_HOME etc.)
Netbeans and Eclipse RCP both allow settings to take the jre from a folder within the client installation.

from corretto-8.

At this point, we're not planning to deliver Maven artifacts. There isn't a standard pattern and different people may want to redistribute different things. The example given above discusses cutting things out of the JREs, so the contents of one of these packages is not clear.

from corretto-8.