58 schrieb John Hendrikx:
It's not binary compatible, as changing the return type results in a
new method that compiled code won't be able to find.
See also "change result type (including void)" here:
https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_AP
It's not binary compatible, as changing the return type results in a new
method that compiled code won't be able to find.
See also "change result type (including void)" here:
https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods
--John
On 30/05/2022
On Fri, 27 May 2022 23:31:42 GMT, Kevin Rushforth wrote:
> I reviewed the public API changes, and this looks like a great addition to
> JavaFX bindings. I think there might be time to get this into JavaFX 19,
> presuming that there are no issues with the testing or implementation, so
> let's
ble")
> );
>
> // Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Vi
On Tue, 22 Mar 2022 20:17:36 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix wording
>
> Yes, I definitely want to be one of the reviewers. I'll need to
I've tried the attached code as well, and I've been unable to reproduce
it. I even modified the code a bit to clear and set the stylesheet every
frame, and it runs fine. Also used the debugger a bit to see what's
going on in CssStyleHelper#calculateValue but didn't see any obvious flaws.
If
Could you share the program that reproduces this, as I didn't find an
issue nor a sample program in the link you shared.
You mentioned an issue was closed? Which issue?
--John
On 18/05/2022 13:12, Davide Perini wrote:
Hi all,
someone else opened an issue in past on this problem.
I have the
On 11/04/2022 08:15, Daniel Peintner wrote:
All,
I run into a *strange* behaviour.
In my application I associate a file extension which works fine. Clicking
on the desktop opens the app and loads the file I clicked on.
This works fine for Windows and Mac on its own.
Assume a file named
On Wed, 9 Mar 2022 07:37:31 GMT, John Hendrikx wrote:
> I added a test case for `SpinnerSkin` that checks the arrow positioning.
>
> While adding the tests I discovered more problems with the positioning aside
> from the one mentioned in the JBS ticket.
>
> 1) Vertical spl
On Wed, 9 Mar 2022 07:48:53 GMT, John Hendrikx wrote:
>> I added a test case for `SpinnerSkin` that checks the arrow positioning.
>>
>> While adding the tests I discovered more problems with the positioning aside
>> from the one mentioned in the JBS ticket.
>&g
On Tue, 22 Mar 2022 17:06:12 GMT, yosbits wrote:
> The reason I think the Null Safe explanation is incorrect is because In the
> interest of fairness, I feel it would be better to have an example of using
> the Optional API when comparing the existing way of writing to the new way of
>
On Tue, 22 Mar 2022 12:38:43 GMT, yosbits wrote:
> This PR is considered a design change that delegates multiple
> responsibilities to the basic JavaFX class ObservableValue. The balance
> between implementation complexity and convenience seems to be a point of
> contention.
If you could do
On Tue, 22 Mar 2022 02:21:05 GMT, yosbits wrote:
> I think you are incorrect about the Null Safe explanation. Wouldn't using
> Optional solve this?
I'm not sure what you are trying to say, the fluent bindings offered by this
API are null safe. Using standard JavaFX you have to do additional
On Mon, 21 Mar 2022 21:49:33 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Small wording change in API of ObservableValue after proof reading
>
> modules/javafx.b
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Fri, 18 Mar 2022 11:12:55 GMT, Tom Schindl wrote:
>> John Hendrikx has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Reword flat map docs a bit and fixed a link
>> - Add missing javadoc tags
>&
On Sun, 20 Mar 2022 03:08:59 GMT, Nir Lisker wrote:
>> Both seem fine, I don't have any preference over one or the other.
>
> I struggled with finding a good description here
> [previously](https://github.com/openjdk/jfx/pull/675#discussion_r777801130).
> I think that mstr2 gave a good
On Mon, 21 Mar 2022 09:01:01 GMT, John Hendrikx wrote:
>> I read this comment after what I wrote about `flatMap`, so mstr2 also had
>> the idea of "More precisely", which is good :)
>>
>> I would suggested something similar to what I did there:
>>
>
On Sun, 20 Mar 2022 03:28:01 GMT, Nir Lisker wrote:
>> Yeah, agreed, it is a bit annoying to have to deal with the fact that these
>> classes are wrappers around an actual value and having to refer to them as
>> such to be "precise". I'm willing to make another pass at all of these to
>>
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On 17/03/2022 21:01, Michael Strauß wrote:
I'm working on an application that uses the JavaFX event system
extensively, and I'm finding it quite hard to use common code for
event handler registrations.
The problem is that the `EventTarget` interface contains no
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Thu, 17 Mar 2022 20:09:23 GMT, Michael Strauß wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Process review comments (2)
>
> modules/javafx.base/src/main/java/com/sun/javafx/bin
I haven't seen this one; the code in TableView in onChanged hasn't had
any updates 6 years.
I have my doubts this is a JavaFX problem as it seems the Compiler is
crashing here in a piece of native code. It's possible this problem is
only occuring on systems where the compiler decides it
On Thu, 10 Mar 2022 17:49:38 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
TLDR: Skip to the Github link below.
So, I've run into an issue where a Label with wrap text set to true is
only showing the first character of the text "as Kristoff (voice)" while
all other kinds of texts show up correct (there's 100's of examples that
all work, but only found one so far
On Thu, 10 Mar 2022 14:21:15 GMT, Nir Lisker wrote:
>> modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java
>> line 648:
>>
>>> 646:
>>> 647: /**
>>> 648: * Ensures nothing has been observed.
>>
>> "Ensures nothing has been observed since
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Tue, 8 Mar 2022 20:57:53 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix wrong test values
>
> modules/javafx.base/src/tes
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Tue, 8 Mar 2022 21:10:46 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix wrong test values
>
> modules/javafx.base/src/tes
for split horizontal it does normalize the width to that of the widest
> arrow, and so layout becomes:
>
> [ <- ] [ spinner ] [ -> ] --> [ <- ] [ spinner ]
> [ -> ]
>
> While I'm here I could fix this as well, and adjust the test case to match.
I added a test case for `SpinnerSkin` that checks the arrow positioning.
While adding the tests I discovered more problems with the positioning aside
from the one mentioned in the JBS ticket.
1) Vertical split arrow placement also forgot to take the padding into account
while placing the
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Sun, 16 Jan 2022 22:01:33 GMT, Nir Lisker wrote:
> * Most tests that I have seen in JavaFX use the assert overloads that include
> a message that explains what the value should be or what it means if the
> assertion failed. I don't know how much of a requirement it is. I can help
> write
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Thu, 20 Jan 2022 17:19:49 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix grammar mistakes and did some small rephrases
>
> modules/javafx.base/sr
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Sun, 16 Jan 2022 12:25:13 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix grammar mistakes and did some small rephrases
>
> modules/javafx.base/sr
On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote:
> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is
> set on a `ListView`.
>
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a
On Thu, 6 Jan 2022 16:25:33 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply changes suggested in review and updated copyright years to 2022
>
> modules/javafx.b
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote:
> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is
> set on a `ListView`.
>
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a
On Tue, 4 Jan 2022 03:28:57 GMT, Nir Lisker wrote:
> Unrelated to the review, will it makes sense in the future to make all
> bindings lazily register listeners like `LazyObjectBinding`, perhaps when we
> introduce `Subscription`?
That would need to be very well tested. There are some
On Wed, 5 Jan 2022 09:45:21 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java
>> line 193:
>>
>>> 191: *
>>> 192: * @return {@code true} when this binding currently has one or more
>>>
On Sun, 2 Jan 2022 20:18:02 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Upgrade tests to JUnit 5
>
> modules/javafx.base/src/main/java/javafx/beans/binding/
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
I tested this, and it seems to still not work quite right.
As far as I can see, it is not a memory leak, just slow performance when
subtracting many shapes from roughly the same location from another
shape. When the shapes are more spread out, it performs better.
I don't think it is a major
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Wed, 15 Dec 2021 11:36:23 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
// Fluent: type safe
> label.textProperty().bind(label.sceneProperty()
> .flatMap(Scene::windowProperty)
> .flatMap(Window::showingProperty)
> .orElse(false)
> .map(showing -> showing ? "Visible" : "Not Visible")
>
On Fri, 24 Sep 2021 20:05:01 GMT, John Hendrikx wrote:
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
This
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Mon, 22 Nov 2021 12:52:10 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add trivial assert to JUnit5Test
>> - Add explicit dependencies in build.grad
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Sat, 20 Nov 2021 15:54:06 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix white space error
>> - Allow apiguardian as dependency
>
>
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Thu, 18 Nov 2021 21:38:28 GMT, Kevin Rushforth wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>>
This is an implementation of the proposal in
https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
(@nlisker) have been working on. It's a complete implementation including good
test coverage.
This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Fri, 24 Sep 2021 20:45:23 GMT, Kevin Rushforth wrote:
> As mentioned in JBS, any new third-party libraries require prior third-party
> license approval. And we will need to work with you on sponsoring this (as
> you can't contribute any third-party code under the OCA).
>
> Speaking of
On Thu, 11 Nov 2021 15:11:32 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Readd junit declaration in allprojects and set junit version to 4.13.2
>
> buil
On Mon, 15 Nov 2021 16:42:04 GMT, Michael Strauß wrote:
> One comment about adding new JUnit 5 tests and migrating existing tests. I
> think there could be value in organizing the tests such that all of the JUnit
> 5 tests are grouped, rather than mixing tests in the same directory such that
I haven't taken a close look, but I've done some automated layout work
before. The baseline layout seems to be an interesting kind of problem
where controls can influence each other, where normally they are mostly
independent.
An iterative approach may be the only viable one, but it does
On Fri, 24 Sep 2021 20:50:51 GMT, John Hendrikx wrote:
>> gradle/verification-metadata.xml line 121:
>>
>>> 119: >> value="569b6977ee4603c965c1c46c3058fa6e969291b0160eb6964dd092cd89eadd94"
>>> origin="Generated by Grad
Although I think you have a valid use case, I don't think JavaFX should
facilitate this exact scenario; it is a high level concern that you want
to solve in a very low level mechanism. A similar scenario also applies
to uni-directional bindings, so I think it would have to apply there as
well.
On Sat, 30 Oct 2021 09:46:13 GMT, Jeanette Winzenburg
wrote:
>> I don't see an easy way to do that, and I'm not in favor of making private
>> implementation details package-public just to test some internal state. Of
>> course, mnemonic support should have been designed in a way that is more
On Sat, 30 Oct 2021 09:46:13 GMT, Jeanette Winzenburg
wrote:
>> I don't see an easy way to do that, and I'm not in favor of making private
>> implementation details package-public just to test some internal state. Of
>> course, mnemonic support should have been designed in a way that is more
On Fri, 29 Oct 2021 20:54:04 GMT, Michael Strauß wrote:
>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java
>> line 188:
>>
>>> 186: int i = 0;
>>> 187:
>>> 188: // Parse the input string and stop after the first mnemonic.
>>
>>
The fix is in progress here: https://github.com/openjdk/jfx/pull/647
On 29/10/2021 22:12, John Hendrikx wrote:
Looking a bit further, and I noticed this code has recently been
rewritten. The old code used StringBuffer and wasn't that easy to read,
but the new code although easier to read seems
On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strauß wrote:
>> This PR fixes an issue with mnemonic parsing by removing the restriction
>> that a mnemonic symbol must be a letter. Now, it can be any character except
>> whitespace.
>
> Michael Strauß has updated the pull request incrementally with
On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strauß wrote:
>> This PR fixes an issue with mnemonic parsing by removing the restriction
>> that a mnemonic symbol must be a letter. Now, it can be any character except
>> whitespace.
>
> Michael Strauß has updated the pull request incrementally with
a significant change in how things used to work which the
tests didn't catch at all.
--John
On 29/10/2021 21:45, John Hendrikx wrote:
Hm, I can confirm it appears under the "e", also under Windows, but I
suspect the platform will make no difference.
I tested a bit further, and I found the
Hm, I can confirm it appears under the "e", also under Windows, but I
suspect the platform will make no difference.
I tested a bit further, and I found the following:
1) The mnemonic key seems to be "m", and it appears under the "e"
because it deleted two more underscores (index is off by 2).
On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote:
>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
>> still work. Also added a single JUnit 5 tests, and confirmed it works.
>>
>> I've updated the Eclipse project file for the ba
On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote:
>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
>> still work. Also added a single JUnit 5 tests, and confirmed it works.
>>
>> I've updated the Eclipse project file for the ba
, John Hendrikx wrote:
I just wanted to draw some attention to a recent proof of concept I made
in this pull request: https://github.com/openjdk/jfx/pull/434
It is based on the work I did in
https://github.com/hjohn/hs.jfx.eventstream which is in part based on
work done in ReactFX by Tomas Mikula
ports/openjdk-jfx/pull/110
<https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx wrote:
On 02/09/2021 11:57, Nir Lisker w
t
bindings in the future?
On Tue, Oct 5, 2021 at 1:34 PM John Hendrikx mailto:hj...@xs4all.nl>> wrote:
I've created https://bugs.openjdk.java.net/browse/JDK-8274771
Please have a look.
--John
On 04/10/2021 17:51, Nir Lisker wrote:
> I think that a PR can be created. The
.
As for the Optional methods, I'll have a look in my code base and see if
the places I would like to use them at will become irrelevant anyway with
the fluent bindings. I'm fine with proceeding with the current names of the
proposed methods.
On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx wrote
and I contend are far better
known within the Java community than reactive programming. Therefore the
terms map and flatMap should be quite well understood by now.
--John
On Wed, Mar 24, 2021 at 10:49 PM John Hendrikx wrote:
I just wanted to draw some attention to a recent proof of concept
On 04/10/2021 17:51, Nir Lisker wrote:
I think that a PR can be created. The only point we need to decide is
about the subscription models we talked about above. ReactFX uses
something different for each, you use the same. That can determine if we
need different classes for each binding type.
e:
I have not looked at the code yet but why does this have to be part of
OpenJFX and can not be implemented as an external library?
Tom
Am 05.08.21 um 00:25 schrieb John Hendrikx:
Perhaps:
Fluent bindings for ObservableValue
https://github.com/openjdk/jfx/pull/434
It was received well
On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8185886
>>
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than
>> Arrays to improve listener removal speed.
>>
>> This was due to the removal of listeners in TableView
On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8185886
>>
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than
>> Arrays to improve listener removal speed.
>>
>> This was due to the removal of listeners in TableView
Please see:
https://bugs.openjdk.java.net/browse/JDK-8089024
This is a bug which seems to apply transparency twice when a Node has a
clip set. I managed to create a small test program that shows the
problem very clearly, see this image (on Windows):
I'm seeing some really weird issues with Transparent Stages on Windows
when their framerate (both stability and speed) is compared with normal
decorated/undecorated stages.
The transparent stages seem to obey different rules when it comes to
timely firing AnimationTimers.
Where a decorated
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Sat, 25 Sep 2021 13:13:03 GMT, Kevin Rushforth wrote:
> The gradle verification task failed (see the test results from GitHub
> Actiona). It looks like it still needs the hamcrest jars. Go ahead and add
> them back in (and remove the exclusion for them).
Yeah, I noticed, I couldn't get rid
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
Posting this to gauge the interest in adding JUnit 5 as a test
dependency to JavaFX, enabling writing tests with this new version of
JUnit while still supporting all JUnit 4 tests.
A draft PR has been submitted here: https://github.com/openjdk/jfx/pull/633
And an issue has been filed here:
On Fri, 24 Sep 2021 20:49:00 GMT, John Hendrikx wrote:
>> gradle/verification-metadata.xml line 273:
>>
>>> 271: >> version="1.3">
>>> 272:
>>> 273: >> value="66fdef91e9739348df7a096aa384a
On Fri, 24 Sep 2021 20:36:30 GMT, Kevin Rushforth wrote:
>> John Hendrikx has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
> modules/j
On Fri, 24 Sep 2021 20:48:26 GMT, John Hendrikx wrote:
>> gradle/verification-metadata.xml line 247:
>>
>>> 245: >> value="e08028131375b357d1d28734e9a4fb4216da84b240641cb3ef7e7c7d628223fc"
>>> origin="Generated by Gradle"/>
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has updated the pull request incrementa
On Fri, 24 Sep 2021 20:31:14 GMT, Kevin Rushforth wrote:
>> John Hendrikx has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
> gradle/v
On Fri, 24 Sep 2021 20:05:01 GMT, John Hendrikx wrote:
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module
> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
> still work. Also added a single JUnit 5 tests, and confirmed it works.
>
> I've updated the Eclipse project file for the base module only.
John Hendrikx has refreshed the contents of this
I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests
still work. Also added a single JUnit 5 tests, and confirmed it works.
I've updated the Eclipse project file for the base module only.
-
Commit messages:
- Add JUnit 5
Changes:
1 - 100 of 254 matches
Mail list logo
