Re: JavaFX applications fail to build with Maven 3.9.7

On 5/29/24 12:19 AM, Joeri Sykora wrote: maven artifacts are generated when providing the following gradle property: -PMAVEN_PUBLISH=true I can't get that to work. Is there some other option I need to pass? $ bash gradlew -PMAVEN_PUBLISH=true publishToMavenLocal FAILURE: Build failed with an

Re: JavaFX applications fail to build with Maven 3.9.7

On 5/29/24 6:54 AM, Joeri Sykora wrote: FYI, version 23-ea+20 should contain the fixed parent pom. Works great! Thank you for the quick fix, Joeri. John

Re: JavaFX applications fail to build with Maven 3.9.7

It looks as if this issue was reported in 2021, 2022, and 2023. The difference now is that, as of Maven 3.9.7, the failure occurs immediately when it tries to download the JavaFX dependencies. 2021-12-27 JDK-8279380: Duplicate profile id in JavaFX maven POM

JavaFX applications fail to build with Maven 3.9.7

JavaFX applications fail to build with Maven 3.9.7, which was released on May 25. The Maven developers identified the JavaFX parent POM file as the source of the problem: Maven Central: org.openjfx:javafx:22.0.1 https://central.sonatype.com/artifact/org.openjfx/javafx/22.0.1 To see the

Re: Validation Support

On 3/9/24 10:30 AM, Marius Hanl wrote: However, I found this old email thread. Two answers which reflect what we said: https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010094.html Wow, good find! Thank you,

Re: Aw: Re: Validation Support

On 3/7/24 3:40 PM, Marius Hanl wrote: This design is mostly superior than e.g. Swing, where you can override things and easily break something if not too careful. Pretty sure that this were some lessons learned from the development of Swing. That's what I remember, too, but I can't find any

Re: The crisp fonts saga

On 12/17/23 12:49 PM, John Neffenger wrote: That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png Here you can really see the effect of the slight vertical-only hinting. I zoomed in on the images, and seeing no color

Re: The crisp fonts saga

On 12/12/23 6:10 AM, Mark Raynsford wrote: I've never been particularly satisfied with the font rendering in JavaFX. I looked over the images in your original message. Thank you for taking the time to run all of these experiments! I've included my comments below. I opened the images in

Re: The crisp fonts saga

On 12/16/23 3:30 AM, Mark Raynsford wrote: I have, yes. I actually considered properties for each of these, but I thought it more important to be able to specify them on a node-by-node basis. I would prefer not to have the tyranny of the project default replaced with a new tyranny of the app

Re: The crisp fonts saga

On 12/15/23 2:21 PM, Mark Raynsford wrote: 2. Add an -fx-font-hinting CSS attribute that, by default, will be set to false. Setting this value to true will enable hinting using whatever is the default (in other words, not setting FT_LOAD_NO_HINTING). Have you thought of a

Re: The crisp fonts saga

On 12/15/23 1:40 PM, Philip Race wrote: I will expand on it a bit but a number of the salient points have already been made by others. Thank you, Phil, for taking the time to write down the history. I truly appreciate it, and it's very helpful. Those of us outside of Oracle know the "what"

Re: The crisp fonts saga

On 12/13/23 10:15 PM, John Neffenger wrote: I find it helps to get the bigger picture. Below are the various camps as I've come to understand them over the years. An update to my previous categorization ... In 2018, Java Swing moved from the full-hinting group to the slight-hinting group

Re: The crisp fonts saga

On 12/14/23 4:39 AM, Mark Raynsford wrote: The key point is "keep text aligned to the pixel grid". The thing is: This isn't affected by hinting or the lack of it whatsoever, at least with the way text is implemented in Prism and Freetype, as far as I can tell. It seems to have influenced the

Re: The crisp fonts saga

On 12/12/23 6:10 AM, Mark Raynsford wrote: I've never been particularly satisfied with the font rendering in JavaFX. In particular, on Linux, the text always appears very soft and blurry compared to non-JavaFX applications on the same system. Here's the best source I've found for the history

Re: The crisp fonts saga

On 12/13/23 3:29 AM, Mark Raynsford wrote: I would love to live in a world where everyone has such a high resolution display that we can turn off AA entirely, but we don't live in that one yet. Anti-aliasing is still widely in use, but the various operating systems and application frameworks

[jfx21u] Integrated: 8317370: JavaFX runtime version is wrong at runtime

On Tue, 21 Nov 2023 20:19:04 GMT, John Neffenger wrote: > Backport 16169240667876633895b27464eb90033abb6166 > > Please review this backport of openjdk/jfx#1253 to JavaFX 21. Please give me > a day or two to test it again before starting your review. This pull request has now bee

Re: [jfx21u] RFR: 8317370: JavaFX runtime version is wrong at runtime

On Tue, 21 Nov 2023 20:19:04 GMT, John Neffenger wrote: > Backport 16169240667876633895b27464eb90033abb6166 > > Please review this backport of openjdk/jfx#1253 to JavaFX 21. Please give me > a day or two to test it again before starting your review. I ran the builds and unit te

[jfx21u] RFR: 8317370: JavaFX runtime version is wrong at runtime

Backport 16169240667876633895b27464eb90033abb6166 Please review this backport of openjdk/jfx#1253 to JavaFX 21. Please give me a day or two to test it again before starting your review. - Commit messages: - Backport 16169240667876633895b27464eb90033abb6166 Changes:

Re: CFV: New OpenJFX Committer: Martin Fox

Vote: YES John On 11/16/23 7:54 AM, Kevin Rushforth wrote: I hereby nominate Martin Fox [1] to OpenJFX Committer.

Re: CFV: New OpenJFX Committer: Florian Kirmaier

Vote: YES John On 11/16/23 7:38 AM, Kevin Rushforth wrote: I hereby nominate Florian Kirmaier [1] to OpenJFX Committer.

Integrated: 8317370: JavaFX runtime version is wrong at runtime

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger wrote: > Please review these changes to the build timestamp and to the JavaFX runtime > version available in the system properties. This pull request has now been integrated. Changeset: 16169240 Author: John Neffenger URL:

Re: RFR: 8317370: JavaFX runtime version is wrong at runtime [v2]

> Please review these changes to the build timestamp and to the JavaFX runtime > version available in the system properties. John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Update the documentation in UPDATING-VERS

Re: RFR: 8317370: JavaFX runtime version is wrong at runtime

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger wrote: > Please review these changes to the build timestamp and to the JavaFX runtime > version available in the system properties. Thanks, Kevin. I'll fix that. To all reviewers: I added tests of the method [VersionInfo.setupSystemProp

Re: RFR: 8317370: JavaFX runtime version is wrong at runtime

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger wrote: > Please review these changes to the build timestamp and to the JavaFX runtime > version available in the system properties. @FlorianKirmaier Florian, I would appreciate any comments you might have, too, or even a formal review

Re: RFR: 8317370: JavaFX runtime version is wrong at runtime

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger wrote: > Please review these changes to the build timestamp and to the JavaFX runtime > version available in the system properties. This pull request makes three changes: 1. The ISO 8601 extended format of the build date and time is no

RFR: 8317370: JavaFX runtime version is wrong at runtime

Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties. - Commit messages: - 8317370: JavaFX runtime version is wrong at runtime Changes: https://git.openjdk.org/jfx/pull/1253/files Webrev:

Re: RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

On Fri, 29 Sep 2023 10:40:52 GMT, Florian Kirmaier wrote: > The format of the timestamp has changed to ISO 8601. This contains the “:” > Character. > A copy of the dll is saved at /.openjfx/cache/" + jfxVersion + "/" + > arch . > On Windows, the character ‘:’ is invalid in files, causing

Re: RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

On Sun, 1 Oct 2023 11:48:07 GMT, Florian Kirmaier wrote: > After I ran into Windows issues, I assumed this was a regression that > affected everyone. @FlorianKirmaier You were quite right! Thank you for finding this issue and for quickly fixing its worst effect. I introduced this error in

Re: RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

On Fri, 29 Sep 2023 17:14:50 GMT, Kevin Rushforth wrote: >> The format of the timestamp has changed to ISO 8601. This contains the “:” >> Character. >> A copy of the dll is saved at /.openjfx/cache/" + jfxVersion + "/" + >> arch . >> On Windows, the character ‘:’ is invalid in files, causing

Re: RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

On Fri, 29 Sep 2023 10:40:52 GMT, Florian Kirmaier wrote: > The format of the timestamp has changed to ISO 8601. This contains the “:” > Character. > A copy of the dll is saved at /.openjfx/cache/" + jfxVersion + "/" + > arch . > On Windows, the character ‘:’ is invalid in files, causing

Re: RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

On Fri, 29 Sep 2023 13:19:51 GMT, Florian Kirmaier wrote: >> The format of the timestamp has changed to ISO 8601. This contains the “:” >> Character. >> A copy of the dll is saved at /.openjfx/cache/" + jfxVersion + "/" + >> arch . >> On Windows, the character ‘:’ is invalid in files, causing

Re: RFR: 8313321 : Set minimum python version in WebKit cmake scripts [v2]

On Mon, 14 Aug 2023 16:17:29 GMT, Hima Bindu Meda wrote: >> Minimum version of python ,to run webkit build , on linux is set to 3.6 and >> for other platforms, minimum version of python is set to 3.8. >> >> Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull

Integrated: 8307316: Let JavaFX be built on unknown architectures

On Wed, 3 May 2023 16:02:34 GMT, John Neffenger wrote: > Please review these changes to the Gradle build files and the dependency > verification file. The initial version of this pull request extends the > permitted build platforms for Linux to the Java architectures `arm`, &

Re: RFR: 8307316: Let JavaFX be built on unknown architectures [v3]

verification file > for the `i386` architecture. The Debian names for these architectures are > `armhf`, `i386`, `ppc64el`, and `s390x`. John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Me

Re: RFR: 8307316: Let JavaFX be built on unknown architectures [v2]

On Tue, 13 Jun 2023 14:39:57 GMT, John Neffenger wrote: >> Please review these changes to the Gradle build files and the dependency >> verification file. The initial version of this pull request extends the >> permitted build platforms for Linux to the Java architectures `

Re: Problem with OpenJFX on Windows/Cygwin/SDKMAN Environment

On 7/2/23 9:21 AM, Eric Bresie wrote: * What went wrong: A problem occurred evaluating root project 'jfx'. > Missing or incorrect path to 'java': '\home\\.sdkman\candidates\java\current\bin\java.exe'. Perhaps bad JDK_HOME? /home/   /.sdkman/candidates/java/current You might need to use the

Integrated: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

On Tue, 30 Mar 2021 16:20:21 GMT, John Neffenger wrote: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, > and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For > example, the following commands create a reproducible build: > &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15]

On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15]

On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a

Re: RFR: 8307316: Let JavaFX be built on unknown architectures [v2]

On Mon, 22 May 2023 21:24:18 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into allow-armhf-i386-ppc64el-

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

On Fri, 28 Apr 2023 01:24:51 GMT, John Neffenger wrote: >> I solved the build failure occurring on Windows by downgrading to Visual >> Studio 2022 [Build Tools version 17.1.0][1], dated February 15, 2022, from >> the prior version 17.5.4 that I was using. I opened a

Re: RFR: 8307316: Let JavaFX be built on unknown architectures [v2]

verification file > for the `i386` architecture. The Debian names for these architectures are > `armhf`, `i386`, `ppc64el`, and `s390x`. John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Me

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: RFR: 8307316: Let JavaFX be built on unknown architectures

On Wed, 3 May 2023 16:02:34 GMT, John Neffenger wrote: > Please review these changes to the Gradle build files and the dependency > verification file. The initial version of this pull request extends the > permitted build platforms for Linux to the Java architectures `arm`, &

Re: RFR: 8307316: Let JavaFX be built on unknown architectures

On Wed, 3 May 2023 16:02:34 GMT, John Neffenger wrote: > Please review these changes to the Gradle build files and the dependency > verification file. The initial version of this pull request extends the > permitted build platforms for Linux to the Java architectures `arm`, &

RFR: 8307316: Let JavaFX be built on unknown architectures

Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for

Re: Developer documentation

On 5/12/23 12:02 PM, John Hendrikx wrote: The build documentation may be a good candidate to place there as well. I'm all for it. Some of us were in agreement on moving at least the build instructions back in November 2022. See the following thread on the mailing list from a pull request

Re: Allow OpenJFX to be built on unknown architectures

I opened the following bug report for this issue: JDK-8307316 : Let JavaFX be built on unknown architectures John On 3/30/23 10:34 AM, Glavo wrote: Did I successfully send this email to the mailing list? On Wed, Mar 29, 2023 at 10:18 PM Glavo

Re: Bug using binary stylesheets: Loading relative @font-face paths are converted to absolute ones

On 3/30/23 2:01 AM, Armin Schrenk wrote: binary stylesheets is a more hidden feature of javafx, so before filing a bug ticket i'm writing to this mailing list. Just a note that I've opened the following bug report for the problem: JDK-8307082 Build path is recorded in JavaFX Controls module

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

On Wed, 26 Apr 2023 03:59:36 GMT, John Neffenger wrote: > I created bug reports to track each of the remaining potential problems: I forgot the original remaining problem! It's listed as item 4 under **Fixes** in the description at the top of this pull request and now descri

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

On Fri, 7 Apr 2023 06:22:05 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v14]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: Support pluggable image loading via javax.imageio

On 4/17/23 2:10 PM, Michael Strauß wrote: I've been working on a proposal that doesn't add any new API to JavaFX, but instead plugs into the existing `javax.imageio` API, allowing applications to use third-party libraries like TwelveMonkeys [0] to load a wide variety of image formats. Looks

Re: CFV: New OpenJFX Committer: Karthik P K

Vote: YES On 4/12/23 9:14 AM, Kevin Rushforth wrote: I hereby nominate Karthik P K [1] to OpenJFX Committer.

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

On Fri, 7 Apr 2023 06:22:05 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

On Fri, 7 Apr 2023 06:22:05 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-non

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v12]

On Tue, 4 Apr 2023 15:46:20 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v12]

On Tue, 4 Apr 2023 23:27:38 GMT, Kevin Rushforth wrote: > I started doing some testing today. Thank you, Kevin. I'm almost done with another round of my own testing and will post my results, too. > 2. The format of `VersionInfo.BUILD_TIMESTAMP`, which is used in constructing > the

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v12]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v11]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: Allow OpenJFX to be built on unknown architectures

On 3/30/23 11:17 AM, Glavo wrote: I compiled OpenJFX for RISC-V and MIPS64el platforms with reference to your patch, thereby porting our JavaFX applications to these platforms, and it worked well. A better patch, then, would be to remove the platform test entirely so that there are no

Re: Allow OpenJFX to be built on unknown architectures

On 3/30/23 10:44 AM, Kevin Rushforth wrote: No, I didn't see this. Yes, this seems a reasonable request. Actually, I was going to submit a pull request to get my patch for this change integrated (after the reproducible builds PR is merged). I've tested JavaFX on all six architectures for

Re: Bug using binary stylesheets: Loading relative @font-face paths are converted to absolute ones

On 3/30/23 2:01 AM, Armin Schrenk wrote: Is this intended behaviour? I'm guessing it's a bug. The class you mention, Css2Bin, also stores the absolute path of its .css input file in the corresponding .bss output file, which is then included in the JavaFX Controls module. That causes the

Re: CFV: New OpenJFX Committer: Hima Bindu Meda

Vote: YES John On 2/1/23 5:45 AM, Kevin Rushforth wrote: I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer.

Re: CFV: New OpenJFX Committer: Jay Bhaskar

Vote: YES John On 2/1/23 5:45 AM, Kevin Rushforth wrote: I hereby nominate Jay Bhaskar [1] to OpenJFX Committer.

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Wed, 11 Jan 2023 23:00:22 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 17 commits: >> >> - Add '--date' argument for deterministic JMOD files &g

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v10]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-no

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v9]

On Wed, 11 Jan 2023 23:04:15 GMT, Kevin Rushforth wrote: > I'll need a bit more time to run CI test builds again. I'm thinking it might > be better to get this in early in JavaFX 21 rather than late in JavaFX 20 > anyway. I agree, especially considering the change required for JDK 17 GA.

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Tue, 3 Jan 2023 06:37:14 GMT, John Neffenger wrote: > I just discovered that the `--date` argument for the `jmod` tool was > back-ported to JDK 17, so I didn't need to wait for JDK 19 after all! Oh well. Actually, it turns out I did have to wait for JDK 19 after all. Before re

Re: Windows build fails at MediaCapabilities.cpp(323): error C2327

modules\javafx.web\src\main\native\Source\WebCore\Modules/mediacapabilities/MediaCapabilities.cpp(323): error C2327: 'WebCore::MediaCapabilities::m_encodingTasks': is not a type name, static, or enumerator Looking into it a bit more, it looks as if the compiler is failing to pick up the

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v9]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]

On Thu, 5 Jan 2023 20:24:41 GMT, Johan Vos wrote: >> Retrieve libav sources from github. >> Fix JDK-8282386 > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Use new naming convention when working with libav files downloaded

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Thu, 5 Jan 2023 22:16:24 GMT, Johan Vos wrote: > Great. I'll review tomorrow. Thanks, Johan. I'll rerun my failing Linux build once your pull request #989 is integrated. (Thank you for doing that!) Are you seeing the [error I'm getting on Windows][1] with the [full production release

Re: libav.org is not resolving

I've been unable to get the GitHub archive working as a replacement. I think the problem is due to the lack of the file name in the URL, which our Gradle build file expects: https://github.com/libav/libav/archive/v12.1.tar.gz ==> content-disposition: attachment; filename=libav-12.1.tar.gz

Re: CFV: New OpenJFX Committer: John Hendrikx

Vote: YES On 1/3/23 7:17 AM, Kevin Rushforth wrote: I hereby nominate John Hendrikx [1] to OpenJFX Committer.

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nonde

Windows build fails at MediaCapabilities.cpp(323): error C2327

After fixing the error with Cygwin Python 3.9 (see previous message), I'm now getting the compiler error shown below. I haven't seen this before. == FAILED: Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/

Cygwin Python 3.9 breaks Windows WebKit build

The latest Python version 3.9 available on Cygwin breaks the WebKit build on Windows. The previous version, Python 3.8, works fine. The bug is reported to Python in the GitHub issue below, but the Python developers expect any fix to come from the Cygwin Python maintainers: Windows-style

libav.org is not resolving

The domain 'libav.org' is not resolving for at least a week now, causing the build to fail when '-PBUILD_LIBAV_STUBS=true' (see below). The domain itself is good until 2024: Creation Date: 2011-01-19T23:35:14Z Registry Expiry Date: 2024-01-19T23:35:14Z If the problem persists, we could

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7]

On Tue, 6 Dec 2022 18:32:19 GMT, Johan Vos wrote: > I have no magic solution though for doing this completely outside the current > build system. @johanvos There is one magic solution for post-processing files outside of the build: the `strip-nondeterminism` program I mentioned at the top of

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7]

On Tue, 6 Dec 2022 18:32:19 GMT, Johan Vos wrote: > Speaking of which, that is my main worry about this PR: we are increasing our > dependency on Gradle by adding logic inside the build.gradle file. You mean the 17-line `setFileTimestamps` method? I see that as the main issue, as all the

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7]

On Sat, 7 May 2022 04:17:13 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3]

On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Withdrawn: 8266396: Save VSCMD_DEBUG output in Windows build

On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote: > The Windows build calls a series of batch files to get the Visual Studio > paths and environment variables. The batch files are a black box: any > messages they print are discarded. If anything goes wrong, the only signs are

Discussion: Reproducible builds

This message continues the conversation I started with Johan in a random GitHub issue. :-) I'm posting it to the mailing list so that anyone can join the discussion with other questions or comments. We're now using the github issue tracker to discuss reproducible builds, which is probably

Re: Warnings

On 12/4/22 8:22 AM, John Hendrikx wrote: - Avoiding indirect access to static methods and fields    class A { static final int ONE = 1; }    class B { }        class C extends B {     int one = ONE;  // unqualified access to A.ONE   } Did you mean the following?

Re: RFR: 8276170: Create Sources when publishing to Maven

On Fri, 2 Dec 2022 15:52:59 GMT, Johan Vos wrote: > 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

Re: CFV: New OpenJFX Committer: Andy Goryachev

Vote: YES On 11/3/22 10:05 AM, Kevin Rushforth wrote: I hereby nominate Andy Goryachev [1] to OpenJFX Committer.

Re: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3]

On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Re: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3]

On Tue, 1 Nov 2022 12:33:13 GMT, Marius Hanl wrote: > I would like to give this PR a bump. I still think this is a nice and safe > improvement. Thanks, Marius. I appreciate the time you gave for a thorough review. Nonetheless, it may have served its purpose. Searching for WINSDK_DIR on Google

Re: Platform independent deployment

On 10/21/22 2:36 AM, Thomas Reinhardt wrote: And after a little digging I think half of the artifacts should not have been platform dependent in the first place: Indeed. See the last paragraph of the following pull request comment: jgneff commented on Nov 22, 2021

Re: [External] : Re: Missing 'vcruntime.h'

On 8/15/22 10:18 PM, Nir Lisker wrote: I also have entries there that don't exist. I suspect they have to do with building WebKit. Turns out they don't hurt. Right, they don't hurt. They're not for WebKit, though, and I found they over-complicate the sample as a starting-point for editing. It

Re: [External] : Re: Missing 'vcruntime.h'

On 8/15/22 12:32 AM, Nir Lisker wrote: (I have '%SystemRoot%\system32' which is exported to Cygwin correctly). That works, too. I have to admit, my troubles on Windows at the time were self-inflicted. I was trying to reduce my PATH to its minimum (shown formatted below), but I left off

Re: [External] : Re: Missing 'vcruntime.h'

On 8/13/22 7:29 AM, Nir Lisker wrote: I figured out that that error (which appeared during compilation of native decora shaders) came from a missing entry in windows.tools.properties: While working on pull request openjdk/jfx#488, I found the sample 'windows_tools.properties' file in the

Re: JavaFx Linux vs Glibc

On 8/2/22 2:28 PM, Johan Vos wrote: The problem with this is that there is no GCC 11.2 (which is required per the build.properties) that comes with Ubuntu 20.04. Thanks, Johan. You've mentioned that before, but I feel like I'm missing some information. What is in the JavaFX build that

Re: JavaFx Linux vs Glibc

On 8/2/22 9:50 AM, Thiago Milczarek Sayão wrote: I have built it on a Ubuntu 22.04 VM and tried to run on 20.04. If you want to keep your current build process, try building on Ubuntu 18.04, which is still receiving updates until next year. Ubuntu Updates GLIBC 16.04

  1   2   >