Zitat von Kevin Rushforth :
I just tested it and it works fine for me. Are you sure the reason
it didn't run the tests in the other projects (graphics, etc) was
because they had been run successfully earlier and thus the tests
were "up-to-date"?
hmm .. not entirely certain: here's the scenar
I just tested it and it works fine for me. Are you sure the reason it
didn't run the tests in the other projects (graphics, etc) was because
they had been run successfully earlier and thus the tests were
"up-to-date"? If you want to force the tests to rerun even if nothing
has changed, you need
ahh .. yeah, that's working, thanks :) Except that now it continues
with web testing as first, and I don't know how to exclude that,
something like
gradlew --continue test -x :web:test
just stops again after the base failure ..
But don't bother - it's the end of the working day and I
I see. In that case, the following will run follow-on tests:
gradlew --continue test
That's what I usually do for a full test run.
-- Kevin
On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote:
thanks for the quick answer :)
Sounds like I wasn't clear enough, though (did mean unit tests): what
thanks for the quick answer :)
Sounds like I wasn't clear enough, though (did mean unit tests): what
I'm puzzled about is that the unit tests of a dependent project (f.i.
controls) is _not_ run if the base has test failures.
-- Jeanette
Zitat von Kevin Rushforth :
"gradlew test" is suff
"gradlew test" is sufficient to run the headless tests (e.g., the ones
in base, graphics, controls, etc). To run the headful tests, there are
two additional gradle options:
-PFULL_TEST=true
-PUSE_ROBOT=true
The first enables headless tests (which are in the systemTests project).
The second ad
The first enables headless tests (which are in the systemTests project)
s/headless/headful/
-- Kevin
On 10/8/2020 7:28 AM, Kevin Rushforth wrote:
"gradlew test" is sufficient to run the headless tests (e.g., the ones
in base, graphics, controls, etc). To run the headful tests, there are
I went ahead and created the JBS bug that you will need for this:
https://bugs.openjdk.java.net/browse/JDK-8244212
-- Kevin
On 4/30/2020 11:59 AM, Jesper Skov wrote:
I have created https://github.com/openjdk/jfx/pull/202 with a suggested
implementation.
Looking for feedback.
Cheers,
Jesper
I have created https://github.com/openjdk/jfx/pull/202 with a suggested
implementation.
Looking for feedback.
Cheers,
Jesper
On Fri, Apr 24, 2020 at 5:13 PM Jesper Skov wrote:
> Thanks, I will give it a shot.
>
> Jesper
>
>
> On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth <
> kevin.rushfo...@
Thanks, I will give it a shot.
Jesper
On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth
wrote:
> That's an interesting idea that might be worth pursuing. It would help
> mitigate what has been a long-standing pain point for developers who
> don't want to build media or web, but would like to run
That's an interesting idea that might be worth pursuing. It would help
mitigate what has been a long-standing pain point for developers who
don't want to build media or web, but would like to run them. I would
caution, though, that it is still not a substitute for building both
media and WebKit
I've found and corrected the problem in the plugin and submitted a pull request.
Cf. https://github.com/openjfx/javafx-gradle-plugin/pull/15
Best regards,
/Lennart Börjeson
> 3 dec. 2018 kl. 11:12 skrev Lennart Börjeson :
>
> Is this the right place to ask questions on the gradle plugin
> (o
11:53 AM
To: c...@bekwam.com; openjfx-dev@openjdk.java.net
Subject: Re: Gradle File Rename Error in 8u Dev Build
Two questions:
1) Are you using the gradle daemon?
If so, you might try disabling it.
2) Are you running any applications that might still have jfxrt.jar open?
If so, you should stop them be
Two questions:
1) Are you using the gradle daemon?
If so, you might try disabling it.
2) Are you running any applications that might still have jfxrt.jar open?
If so, you should stop them before rebuilding.
-- Kevin
On 11/8/2018 6:57 AM, c...@bekwam.com wrote:
Hi,
I was wondering if
The individual per-project javadoc tasks have always been disabled, so
this is not new.
-- Kevin
On 6/25/2018 4:27 PM, Nir Lisker wrote:
Hi,
When I run gradle javadoc (or for a specific module), all the javadoc tasks
are marked as SKIPPED. I don't remember this happening previously.
Task :
; :web:test" and in this case webkit dll will be picked up from your source
> code repo (not from JDK).
> >
> > Thanks,
> > Murali
> >
> > -----Original Message-
> > From: Murali Billa
> > Sent: Thursday, April 05, 2018 10:19 AM
> > To: Nir L
code repo (not from JDK).
Thanks,
Murali
-Original Message-
From: Murali Billa
Sent: Thursday, April 05, 2018 10:19 AM
To: Nir Lisker ; openjfx-dev@openjdk.java.net Mailing
Subject: RE: gradle :web:test fails
Hi Lisker,
Can you print the value of useragentString ? Looks like you ar
e webkit dll will be picked up from your source code repo (not
from JDK).
Thanks,
Murali
-Original Message-
From: Murali Billa
Sent: Thursday, April 05, 2018 10:19 AM
To: Nir Lisker ; openjfx-dev@openjdk.java.net Mailing
Subject: RE: gradle :web:test fails
Hi Lisker,
Can you
Hi Lisker,
Can you print the value of useragentString ? Looks like you are using
fxversion as 11 (you can print this value from
System.getProperty("javafx.runtime.version");) but the useragentstring does not
contain 11.
final WebView webView = new WebView();
final WebEngine webEngine = webV
As long as it is optional, this seems like a fine idea.
When we explored it before, there was some concern about checking in the
gradlew.jar file to the repo -- we would need to get additional
third-party legal approval -- so I would need to check on that before
this can be merged to the mainl
Great, thanks!
Aside: on windows 10, cmake 3.7 or later is needed to build webkit with
Visual Studio 2017 generators. However, cygwin only comes with cmake 3.6. I
had to install cmake 3.9 for windows ,uninstall the one provided by cygwin,
and install ruby (via cygwin)
Am 09.10.2017 3:03 nachm. sc
To answer your questions:
* Yes it is possible to build WebKit on any of the three platforms as
long as you install all of the prerequisite software. You need to pass
"-PCOMPILE_WEBKIT=true" to gradle.
* No, JDK 8u152 has not yet been released. It will be released on
Tuesday, Oct 17. What yo
I'm wondering if it possible to build Webkit on Windows anyway? Just by
build openJDK?
Also, according to [1] JDK 8u152 has been already released.
1. http://jdk.java.net/8/
2. http://openjdk.java.net/projects/jdk8u/
Regards
2017-09-26 22:59 GMT+02:00 Kevin Rushforth :
> I presume you aren't bui
I presume you aren't building WebKit? If not, then you will have a
mismatch between the Java .class files and the native library. Possible
solutions are:
1) Build WebKit yourself
2) Avoid running WebView tests
3) Wait for 3 weeks until JDK 8u152 is released (at which time the
.class files an
Now I'm having issues when running unit tests of the webkit module.
:web:test
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x69c6f73d,
pid=8240, tid=0x337c
#
# JRE version: Java(TM) SE Runtime Environmen
Hi all,
I solve this problem after stumbling over the following comments in the
*buildSrc/genVSproperties.bat* file:
*"The current officially supported Visual Studio version is 15.0 *
*Handling of 11.0 and 14.0 is excluded here"*
Thus, installing Visual Studio 2017 (VS 15.0) on the Windows 10 mac
I've filed: https://javafx-jira.kenai.com/browse/RT-37293
With a couple suggestions for fixes.
Scott
On Tue, May 27, 2014 at 1:54 PM, Kevin Rushforth
wrote:
>
>> *** I have updated to the 8u5-b13 tag as that is what I was patching.
>> Perhaps this is the step that puts things out of date? ***
*** I have updated to the 8u5-b13 tag as that is what I was patching.
Perhaps this is the step that puts things out of date? ***
Yes, that would be it, since it would not contain the fix for:
RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9
(same bug would affect building with 8u5)
I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/
*** I have updated to the 8u5-b13 tag as that is what I was patching.
Perhaps this is the step that puts things out of date? ***
If that's the case I can just hack the min build check as I already have.
Gradle 1.12 fails to build
BUILD_NATIVES was never implemented so I deleted mention of it from the
wiki. I have also updated the Mac section to include
MACOSX_MIN_VERSION. I could have swore this information was there but
apparently not.
Steve
On 2014-05-27, 12:22 PM, Scott Palmer wrote:
My build woes continued a bi
I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you
have an out-of-date repo.
-- Kevin
Kevin Rushforth wrote:
Hi Scott,
I don't think we can use gradle wrapper since it would require
checking a gradle jar file into our repo (there is IP / licensing
concern with that).
Hi Scott,
I don't think we can use gradle wrapper since it would require checking
a gradle jar file into our repo (there is IP / licensing concern with that).
Regarding your other issues:
1) The Mac issue is a known problem that I still plan to address for
8u20: https://javafx-jira.kenai.co
See
https://javafx-jira.kenai.com/browse/RT-34388
On May 27, 2014, at 9:29 AM, David Hill wrote:
> On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote:
>>
>> The root cause seems to be that I am missing the OS X 10.7 SDK:
>>
>> clang: warning: no such sysroot directory:
>> '/Applications/Xcode.
On 5/27/14, May 27, 12:22 PM, Scott Palmer wrote:
The root cause seems to be that I am missing the OS X 10.7 SDK:
clang: warning: no such sysroot directory:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
But I do have later versions for 10.
My build woes continued a bit...
I tweaked build.gradle such that the buildnum.min was 5.
Then the build failed trying to build :fxpackager:compileLauncher
>Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher'
I belive this is native code? The wiki says that native cod
This is great news. I would go with what you have (the unjaring) for
now of course.
Are there any changes you are waiting on in OpenJFX?
Steve
On 2014-05-08 12:31 PM, Johan Vos wrote:
Hi,
We're getting closer to building the JavaFX Android runtime in OpenJFX.
I'm trying to automate all step
On 5/8/14, May 8, 12:31 PM, Johan Vos wrote:
Hi,
We're getting closer to building the JavaFX Android runtime in OpenJFX.
I'm trying to automate all steps in the gradle build files, but my
knowledge is still very limited.
My current bottleneck: I would like to apply retrolambda to all class files
Great! There were people getting burned by this at EclipseCon. Luckily,
I remembered this bug and was able to help them but now we don't have to.
Steve
On 2014-03-21 4:15 PM, Kevin Rushforth wrote:
I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330
Changeset: http://hg.ope
On Mon, 2013-07-08 at 09:09 -0700, Richard Bair wrote:
Hi Richard,
> You are on Linux I'm guessing (educated guess). The open source linux
> implementation was I believe just barely pushed. Which repo are you
> building from (master or graphics)?
Ouch, sorry I didn't say that... Yes, working on
> I did a search and see JSObject.java in two places, web and graphics modules.
> Yikes.
A related jira issue is =>
https://javafx-jira.kenai.com/browse/RT-30622 Not able to resolve
JSObject.getWindow(this) in a java applet project
Caused by a mismatch between the JSObject code included in the
On Mon, Jul 8, 2013 at 10:09 AM, Richard Bair wrote:
>
> > 4. *** OpenJDK with just created open jfxrt.jar ***
> >
> > Well, you guessed this fails too... I wonder how the iOS people got
> > their code working at all... Is there any secret repository you guys are
> > using?
>
> Probably the same i
> Caused by: java.lang.NullPointerException
> at
> com.sun.javafx.font.PrismFontLoader.loadFont(PrismFontLoader.java:220)
> at javafx.scene.text.Font.(Font.java:318)
> at javafx.scene.text.Font.getDefault(Font.java:85)
> at javafx.scene.CssStyleHelper.(CssStyleHelper.java:13
42 matches
Mail list logo
