8276170: Create Sources when publishing to Maven

[eduardsdv]

Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically.

---

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [ ] Change must be properly reviewed

Issue

• JDK-8276170: Create Sources when publishing to Maven

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/657/head:pull/657
$ git checkout pull/657

Update a local copy of the PR:
$ git checkout pull/657
$ git pull https://git.openjdk.java.net/jfx pull/657/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 657

View PR using the GUI difftool:
$ git pr show -t 657

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/657.diff

[bridgekeeper[bot]]

Hi @eduardsdv, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user eduardsdv" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[eduardsdv]

/covered

[bridgekeeper[bot]]

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[FlorianKirmaier]

I wonder how the sources for the official maven release are generated? https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/17/ The official release contains all the sources, but when we build it from source, these files are missing.

[mlbridge[bot]]

Webrevs

• 00: Full (0ade024f)

[kevinrushforth]

As discussed in the bug report, it isn't at all clear that we should do this.

@johanvos can make the call on this.

/reviewers 2

[openjdk[bot]]

@kevinrushforth The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

[eduardsdv]

It seems that no one needs it, so I am closing this PR.

[mipastgt]

It's a pitty that this review was never completed. Very demotivating.

[FlorianKirmaier]

I'm actually using it for my builds ... But sadly I'm not a reviewer.

[nlisker]

It requires only 1 reviewer with the tole of Reviewer. One of you can be the second reviewer.

[kevinrushforth]

In this case, there was no agreement that we should add this capability. As @johanvos said in this comment in the JBS bug report, it might have been better for the maven publishing task to not be in the build at all.

[FlorianKirmaier]

Honestly, the idea of removing the Maven build horrifies me. This would basically force me (and probably many others) to maintain a forked build script.

As long as people are willing to maintain the Gradle+MavenBuild it would be a shame if they wouldn't get the opportunity to do so.

I'm still wondering what is even the alternative, to the MavenBuild. Create manually pom files by hand? Only using JDK. with bundled JFX? (Which oracle kind of killed in the past)

So please give the other users to maintain this.

[johanvos]

I think there is some confusion, so let me clarify. My intention was never to remove or stop building the maven artifacts. Those are extremely important and heavily used, and we will keep them, and keep uploading new artifacts (including ea versions) to maven central. There are also no plans to stop the javafx maven and gradle plugins, so we continue maintaining those.

However, I think having the maven build logic (for building OpenJFX artifacts, not for building JavaFX apps with OpenJFX artifacts) inside the same file (build.gradle) as all the build logic for OpenJFX makes things overcomplicated. The build.gradle file in the OpenJFX repository is imho too complex and does too many things. Every line that is added inside this file makes the maintenance of OpenJFX harder.I  personally would like to have an approach similar to OpenJDK, which is more Makefile based and deals with module/platform/architecture specific things in a cleaner way. However, it would be a huge effort to move from the monolith build.gradle that we currently have towards a system like OpenJDK -- especially since we need to get all testing and all cornercases 100% correct -- so it's not on my personal short-term roadmap.

So what I regret is that I wanted to have the artifact build logic inside the monolithic build.gradle file. I believe that was a mistake that we have to fix, and in doing so we can improve the process (e.g. by adding the source builds). I should have commented on the PR, and I want to apologize (especially to @eduardsdv ) because I failed to do so. 

[eduardsdv]

Thanks for the clarification and I totally comprehend your point of view. The build file is really big. It was not easy to find the change set to build the sources, in a regular maven build it would be very easy.

But I would also like to see a solution for building the sources. How can they be created? How are they created for each release?

[jgneff]

I personally would like to have an approach similar to OpenJDK, which is more Makefile based and deals with module/platform/architecture specific things in a cleaner way.

Me too! I thought I was alone in wanting to move to Makefiles. The OpenJDK build is by far one of the easiest open-source build systems I've encountered. OpenJFX is by far one of the most difficult. Most of that difficulty is due to essential complexity: it just does so much on so many operating systems and hardware platforms. But there is a lot of accidental complexity in our current build system that could be removed, too.

However, it would be a huge effort to move from the monolith build.gradle that we currently have towards a system like OpenJDK -- especially since we need to get all testing and all cornercases 100% correct -- so it's not on my personal short-term roadmap.

We don't need to get any testing or corner cases correct at all. We just need reproducible builds.

Once we have reproducible builds, we can be bold and reckless in our changes to the build system. If the artifacts produced by the old build and the new build are bit-for-bit identical, we're done. Zero testing required.

[johanvos]

We're now using the github issue tracker to discuss reproducible builds, which is probably not the primary reason Github issues were created, so I think it's better to start this discussion on a mail thread :) After reading it twice, I agree with your analysis (no need to test corner cases IF we have reproducible builds) I think there is some overlap in the two goals. We'll need to test for bit-for-bit identical artifacts for all the cornercases. By cornercases, I mean for example JavaFX 64 bit on Pi 4 with Ubuntu. You can't build that with the same compiler/libc/gtk-libs/... as Raspberry Pi OS for the same Pi 4.

The majority of potential issues I see are on niche platforms with niche usecases. Creating reproducible builds for all these platforms sounds extremely difficult to me, but I'd like to be proven wrong. Especially the dependency on system libs and the low-level graphical drivers are non-trivial. We already had issues in differences for Linux 64 bit desktop when compiling using Ubuntu 18 versus Ubuntu 20 libs, and Linux/Ubuntu is about the simplest case I can think of. The myriad of embedded platforms make it harder. But we should probably continue the discussion on a mailthread :)

[mipastgt]

We're now using the github issue tracker to discuss reproducible builds, which is probably not the primary reason Github issues were created, so I think it's better to start this discussion on a mail thread :)

Or maybe use https://docs.github.com/en/discussions here.