search

AdoptOpenJDK / TSC

The AdoptOpenJDK Technical Steering Committee - Also acts as the knowledge portal for the Adopt OpenJDK GitHub projects
71 stars 33 forks source link

Add JavaFX to the build farm and distribute results via adoptopenjdk website #27

Closed tellison closed 4 years ago

tellison commented 6 years ago

This is a proposal to build and distribute JavaFX at adoptopenjdk.

The JavaFX code is hosted at https://github.com/javafxports/openjdk-jfx

If accepted, we would give developers of that code access to Jenkins to create build jobs that produce a JavaFX SDK, similar to the Java SDK, and distribute it from the adoptopenjdk website.

Please indicate whether you think this is in keeping with the goals of adoptopenjdk. Other issues will be created in the appropriate places to cover the infrastructure and website updates etc.

/cc: @johanvos @tiainen

karianna commented 5 years ago

There are two things at play here:

1.) Do we need to build from source?: We have for ITW because the Adopt community took over the project, and we do for our OpenJDK binaries because we need to add our version details and perhaps other patches going forward. OpenJFX is a little different because there is already an OpenJFX community (led by Gluon) that produces known good binaries for Java 11+ (8 is another matter)

2.) Do we use Travis or Jenkins?: I’m OK with both but I feel our releases should come from Jenkins because it’s actually our auditable, completely open/transparent pipeline. Travis doesn’t have the same level (as far as I can tell).

sxa I'm probably ok with either option, but if we're not going to be building from source I need to stop wasting any time on it :slightly_smiling_face: gdams I think we'll need to deffo build from source on 8 because the only place that builds it right now is https://chriswhocodes.com/ hopefully with 11 and 12 we can use https://gluonhq.com/products/javafx/ sxa https://adoptopenjdk.net/migration.html never mentioned any intention to provide support for it on 8 (edited) gdams hmm yes good spot annoyingly 8 is the easiest to do, I've got a macOS installer with JavaFX bundled in on openjdk8 working fine but 11 and 12 are harder to bundle martijnverburg OpenJFX on 8 is an interesting one. Oracle sill support their closed source JavaFX for Java 8, but no one is updating OpenJFX for 8 so we’d have to slap a ‘let the buyer beware’ sticker on Adopt 8 builds with it as an option in the installer gdams by default I'm not installing it in the mac installers (edited) martijnverburg Good call - needs to be an opt-in gdams yup in the same way we do ITW I guess

karianna commented 5 years ago

So I think we build 8 from source and supply it to users as an optional part of any installer on a ‘let the buyer beware’ basis

For 11 plus we simply link in official binary from OpenJFX community (once we iron out a perceived issue with bundling Open JFX as opposed to having it installed separately)

johanvos commented 5 years ago

Is it an option to have the OpenJFX lib directory as sort of an ext-lib along with the JDK lib directory? That would be more or less similar to the ext/jfxrt.jar location from 8. I think we do want to require that developers need to have e.g. "--add-modules javafx.controls". If the modules are built-in in one distribution but not in another, this will create a very chaotic situation (which was actually the case with 8, as JavaFX was included in the Oracle JDK but not in the OpenJDK distribution).

tellison commented 5 years ago

@karianna wrote:

So I think we build 8 from source and supply it to users as an optional part of any installer on a ‘let the buyer beware’ basis

I don't think this is a healthy approach. AdoptOpenJDK distributes binaries based upon actively maintained source projects. It is not good practice to include code where there may be bugs and vulnerabilities of which we are unaware. The buyer is trusting us (project maintainers) to exercise good judgement and only distribute high quality code.

Karianna also wrote:

1.) Do we need to build from source? ... OpenJFX is a little different because there is already an OpenJFX community (led by Gluon) that produces known good binaries

Worth a TSC discussion. I think it boils down to whether we consider JavaFX an integral part of the OpenJDK builds we are producing, where we would want to select and build the appropriate source code, or a "bring alongside" capability that is a extension of the core runtime which further expands the scope of the AdoptOpenJDK project as a distributor of other, non-core "stuff".

jerboaa commented 5 years ago

Karianna also wrote:

1.) Do we need to build from source? ... OpenJFX is a little different because there is already an OpenJFX community (led by Gluon) that produces known good binaries

Worth a TSC discussion. I think it boils down to whether we consider JavaFX an integral part of the OpenJDK builds we are producing, where we would want to select and build the appropriate source code, or a "bring alongside" capability that is a extension of the core runtime which further expands the scope of the AdoptOpenJDK project as a distributor of other, non-core "stuff".

Right. Integral part needs defining, IMHO. To me it seems that bridge has been crossed with including IcedTea Web. Strictly speaking that wouldn't be an integral part of OpenJDK either, would it? Either way, this seems OK to me for AdoptOpenJDK builds. When OpenJDK Project Builds were discussed one argument for a distinction between them and AdoptOpenJDK builds was precisely this added integration work which AdoptOpenJDK should be OK to include. Some food for thought, anyway.

With that said, +1 to not including something which isn't being maintained.

karianna commented 5 years ago

The community has been asked for OpenJFX 8 maintainers - will feedback here in 24-48 hours

tellison commented 5 years ago

Severin wrote:

Right. Integral part needs defining, IMHO. To me it seems that bridge has been crossed with including IcedTea Web. Strictly speaking that wouldn't be an integral part of OpenJDK either, would it?

I agree. It's not a fundamental part of the platform but because it is sufficiently well used by those people used to Oracle Java 8, and we have a group willing to maintain the codebase here, it makes sense for AdoptOpenJDK to include it as an optional install for AdoptOpenJDK 8. We have already agreed that it would be a separate download for AdoptOpenJDK 11 because it is not broadly used at that version level.

Either way, this seems OK to me for AdoptOpenJDK builds. When OpenJDK Project Builds were discussed one argument for a distinction between them and AdoptOpenJDK builds was precisely this added integration work which AdoptOpenJDK should be OK to include. Some food for thought, anyway.

Good, and again we agree with the distinction in 'scope' of the two (upstream and AdoptOpenJDK) binary distributions. I'm just advocating that we think carefully about what gets included, even optionally, in AdoptOpenJDK.

With that said, +1 to not including something which isn't being maintained.

I suggest that simply being maintained is in fact a 'below minimum' criteria. :-)

karianna commented 5 years ago

FYI - OpenJFX was released up to 8u202 (final Oracle public release)

As mentioned in this message [1], the last release of OpenJFX 8 was 
8u202 in January 2019, in conjunction with the last Oracle-led OpenJDK 
release of the same. You can see the 8u202-ga tag [2] in the openjfx 8u 
repo.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023039.html
jerboaa commented 5 years ago

To summarize a bit:

hn-te commented 5 years ago

Any further updates around OpenJFX integration? Last couple of comments indicated that OpenJFX 8 integration would depend on finding OpenJFX 8 maintainers(I'm guessing none were established/found?). It appears this discussion has stalled. Many consumers of AdoptOpenJDK really just want an answer in what direction that AdoptOpenJDK maintainers are going with this so that we can plan accordingly. As I understand now, JavaFX/OpenJFX likely will not be included with AdoptOpenJDK 8 since OpenJFX 8 is not being maintained anymore. And sounds like the AdoptOpenJDK 11 installer may include the Gluon community build of OpenJFX 11(Does not as of 11.0.5 release on 10/21), but consumers of AdoptOpenJDK 11 also could just use that build directly from Gluon's site as well.

fireandfuel commented 5 years ago

It would be awesome if AdoptOpenJDK would build and distribute the latest versions of OpenJFX 11. Gluon only distribute an old version of its "JavaFX SDK" (11.0.2) freely. The latest version 11.0.5 is not available for download. It's like falling into a Java 11 rabbit hole when you don't want to stick to the latest version of OpenJDK and OpenJFX as JavaFX developer.

johanvos commented 5 years ago

I don't see this is a rabbit hole. We are very open about it. We distribute our 11.0.5 builds to our JavaFX 11 LTS customers. Those customers pay for the development of JavaFX. If you don't want this, you can easily use the latest version for free.

Let me make it clear again by repeating this: Those [Gluon JavaFX 11 LTS] customers pay for the development of JavaFX.

fireandfuel commented 5 years ago

OpenJFX is still open source, doesn't it?

So everyone should be free to build and distribute it, even an older version, like 11.0.X. That's exactly what Azul Systems does with Zulu Community SDK FX 11.0.X (OpenJDK build with integrated OpenJFX). I honor that Gluon leads the development of OpenJFX, but it doesn't mean that it has to be the ONLY distributor of OpenJFX 11.0.X builds, especially because they are not free for everyone to use.

It's not suitable for everyone to use the latest version for free, because they don't want to switch from OpenJDK 11 to the latest version to have a consistent platform for some time until the next LTS release. Or is it possible to use the JavaFX SDK 13 with OpenJDK 11?

sanrol commented 4 years ago

OpenJFX is still open source - fact!

The GPL says everyone should access to the sourcecode and everyone should build/distribute it. I think it's important for a desktop technology like OpenJFX that it can be easily distributed and used. The integration into adoptopenjdk would be welcome.

hendrikebbers commented 4 years ago

I think we need to look at 2 different topics:

Integration of JavaFX 8

Since no one takes care of the JavaFX 8 branch since Oracles released it for the last time (8u202) Adopt will not integrate it in the Java 8 LTS builds. No security fixes will be merged to the JavaFX 8 branch and this could end in an unsecured Java 8 distribution.

Integration of JavaFX 11+

Here Gluon does a very good job. The artefacts are published to maven central and can be used by everyone. Since you can add JavaFX as a dependency to your application (and deliver it as part of a build) I do not think that JavaFX should be added to a Java 11+ distribution. As @johanvos already mentioned gluon provides non LTS versions for JavaFX every 6 month. While this happens I do not see to do anything here. While the adopt community is not working on JavaFX we can simply not provide any updated (security fixes, ...) builds for 11 LTS if Gluon stops to work on it.

aahlenst commented 4 years ago

@hendrikebbers Thanks for the summary. I think two additional topics should be addressed:

don-vip commented 4 years ago

Since you can add JavaFX as a dependency to your application (and deliver it as part of a build) I do not think that JavaFX should be added to a Java 11+ distribution.

There's a big caveat here. JavaFX has huge native dependencies, making the redistribution very difficult for projects like JOSM who still offer the possibility to distribute a simple jar file over WebStart. For the sake of simplicity, we really want to see AdoptOpenJDK installers with included OpenJFX for the related platform before encouraging our users to switch from Oracle to AdoptOpenJDK.

hendrikebbers commented 4 years ago

The problem with Azul and Bellsoft is that they develop the LTS releases for 8 in closes repositories.

sanrol commented 4 years ago

Hendrik points out the problems.

Integration of JavaFX 8: (normaly JRE is bundled with JavaFX or not?)

Integration of JavaFX LTS 11+:

Example Azul-Download "JDK + FX" Infos: Bundled Patch Releases of ZuluFX Zulu 11.35 (11.0.5) with OpenJFX 11 API is based on Zulu 11.35.15 (11.0.5+10) and incorporates additional security and non-security changes for OpenJFX 11.

Sounds like JavaFX 11 is up to date.

Maybe from the official OpenJFX Project Repository is here: https://github.com/openjdk/jfx.

aahlenst commented 4 years ago

As it stands, it is highly unlikely for AdoptOpenJDK to bundle or distribute OpenJFX. For why that is, what it would take to change it, and what the alternatives are, please see our FAQ on OpenJFX.

sxa commented 4 years ago

Related: https://github.com/AdoptOpenJDK/openjdk-build/issues/245 https://github.com/AdoptOpenJDK/openjdk-build/issues/577 https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/797 https://github.com/AdoptOpenJDK/openjdk-website/pull/697 https://github.com/AdoptOpenJDK/openjdk-installer/pull/129

don-vip commented 4 years ago

Then we will recommend to use Zulu or Liberica instead of AdoptOpenJDK. We prefer a simple solution for end users rather to asking them to download runtimes separately.