For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number
double value) and our code expects -1.0. Based on doc we should be using
CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using
CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will
was introduced with fix
[JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) which uses
MockListObserver in tests. Fix is analogous to previous eclipse build problems
(f.i. [JDK-8265513](https://bugs.openjdk.java.net/browse/JDK-8265513)):
add-exports to allow access to base' test
On 5/11/21 10:27 AM, Johan Vos wrote:
I'm still +1 to keep Gradle for OpenJFX.
The OpenJFX build is shockingly complicated. It's not just a Gradle
build. It's a Gradle, Groovy Custom Task, Apache Maven, Apache Ant, GNU
Make, CMake, Ninja, ANTLR, JUnit, GNU GCC, XCode, Visual Studio,
On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote:
> As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip
> bundle for javadoc offline processing. This missing entry is causing a build
> failure on my system (which will soon propagate to our CI builds).
This pull
On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote:
> As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip
> bundle for javadoc offline processing. This missing entry is causing a build
> failure on my system (which will soon propagate to our CI builds).
Marked as
Hi John,
Regardless of the issues some of us have now, I believe the verification is
a good thing to add, so thank you for that enhancement. Security often
comes with a price, and if removing caches is all that it takes, I'm happy.
Unrelated to that, I'm worried about the maintenance cost of
On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote:
> As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip
> bundle for javadoc offline processing. This missing entry is causing a build
> failure on my system (which will soon propagate to our CI builds).
Looks good
On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote:
> This pull request fixes gradle verification failures when building JavaFX
> with a Windows 32-bit JDK.
This pull request has now been integrated.
Changeset: 3ac6bf0c
Author:Joeri Sykora
Committer: Kevin Rushforth
URL:
On 5/11/21 5:24 AM, Jeanette Winzenburg wrote:
deleting the caches did work, at last ;)
That's also what I had to do after similar errors. I thought there might
be some bumps in the road when I proposed adding the Gradle dependency
verification, but I hope we can retain enough of it to make
On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote:
> This pull request fixes gradle verification failures when building JavaFX
> with a Windows 32-bit JDK.
Marked as reviewed by kcr (Lead).
That's up to you. If you think it would help, go ahead.
-
PR:
On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote:
> This pull request fixes gradle verification failures when building JavaFX
> with a Windows 32-bit JDK.
I was wondering if the
[README](https://github.com/openjdk/jfx/blob/master/gradle/README.txt) should
be updated to include windows
This pull request fixes gradle verification failures when building JavaFX with
a Windows 32-bit JDK.
-
Commit messages:
- fix gradle verification for windows x86
Changes: https://git.openjdk.java.net/jfx/pull/494/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=494=00
deleting the caches did work, at last ;)
To summarize:
./gradlew --refresh-dependencies
got rid of the initial error (problems with dependencies around lucene
libs), but then barked about junit
cd MyProfile/.gradle
rm -rf caches native
made it work gain (hopefully permanent ;)
Thanks
(I did a reply instead of a reply-all)
Hi,
I had that on one of my Linux systems too, after the fix for JDK-8264010.
My first system went fine after I ran with
./gradlew --refresh-dependencies
and I understood this worked for others as well.
On the second system, that didn't work and I ended
On Tue, May 11, 2021 at 1:41 PM Kevin Rushforth
wrote:
> I see that Ajit answered already with option #1 and that you are going
> to try option #2. We might want to document this on the "Building
> JavaFX" Wiki page.
>
> To expand on this a bit, what I think must have happened is that the
>
Assume it has to do with some of this..
https://docs.gradle.org/current/userguide/dependency_verification.html
Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)
> On May 11, 2021 at 6:41:05 AM CDT, Kevin Rushforth
> mailto:kevin.rushfo...@oracle.com)> wrote:
> I see that Ajit answered
I see that Ajit answered already with option #1 and that you are going
to try option #2. We might want to document this on the "Building
JavaFX" Wiki page.
To expand on this a bit, what I think must have happened is that the
contents of the pom files changed some time in the
We've had a couple other reports about this. The solutions that you can
try (should only be needed one time) are:
1. gradle --refresh-dependencies ...
2. Remove the gradle cache before building:
cd $USERPROFILE/.gradle
rm -rf caches native
gradle ...
If this doesn't work, I will
Thanks Johan, Ajit
--refresh-dependencies did it .. nearly ;)
now the error is down to:
* What went wrong:
Execution failed for task ':base:compileTestJava'.
Dependency verification failed for configuration ':base:testCompileClasspath'
One artifact failed verification: junit-4.8.2.pom
Hi Jeanette,
I had faced this on my local system last week.
Although the root cause is unknown - "gradle --refresh-dependencies”
command had helped to get rid of this error.
I did not pursue it as this error is not seen in our CI builds.
Regards,
Ajit
> On 11-May-2021, at 2:58 PM,
Just sync'ed my local repository with upstream .. now can't build with
gradle, the error:
* Where:
Build file
'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle'
line: 4249
* What went wrong:
A problem occurred evaluating root project 'jfx-fork'.
Dependency
21 matches
Mail list logo
