On Wed, 26 May 2021 16:36:24 GMT, Michael Strauß wrote:
>> This PR adds support for loading images from [inline data
>> URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely
>> supported by web browsers. This enables developers to package small images
>> in CSS files,
Perhaps an example will help from my machine.
I'm running on a 4k screen at 150% scaling. These are the values:
outputScaleX = 1.5
outputScaleY = 1.5
platformScaleX = 1.5
platformScaleY = 1.5
width = 2560
height = 1440
visibleWidth = 2560
visibleHeight = 1400
platformWidth = 3840
platformHeight
On Tue, 9 Feb 2021 20:43:08 GMT, John Hendrikx wrote:
>> hmm ... might appear convenient (in very controlled contexts) but looks like
>> a precondition violation: the sender of the change must not be null
>> (concededly not explicitly spec'ed but logically implied, IMO)
&g
rt the aforementioned classes. The complete change
> should update these two classes to add their own listeners instead.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Apply changes from review comments
-
On Tue, 9 Feb 2021 10:31:57 GMT, Jeanette Winzenburg
wrote:
>> My concern is about having a similar way of doing something. It would keep
>> the code uniform. We have been following the earlier pattern under a cleanup
>> task [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364).
rt the aforementioned classes. The complete change
> should update these two classes to add their own listeners instead.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Add missed null checks to fix test failure
-
On Wed, 10 Feb 2021 15:24:07 GMT, Jeanette Winzenburg
wrote:
>> thanks for the info :)
>
>> I could extract the methods instead if you donot like me passing in `null`
>> for the `ObservableValue`, it would then look like:
>>
>> ```
>> sceneChanged(null, node.getScene()); // register
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. The PR itself
I've created a bit of helper code I've been using to detect Nodes that
have been removed from a Scene that are not getting garbage collected.
It takes a Scene as input, and will then monitor all Nodes that are
added and removed to compile a list of Nodes that are no longer part of
the Scene
Hah, managed to reproduce it in a small sample program. Filed bug:
https://bugs.openjdk.java.net/browse/JDK-8264330
--John
On 28/03/2021 14:03, John Hendrikx wrote:
I've created a bit of helper code I've been using to detect Nodes that
have been removed from a Scene that are not getting
Small fix to clear a reference to a removed node left by Scene$MouseHandler.
-
Commit messages:
- 8264330: Scene MouseHandler is referencing removed nodes
Changes: https://git.openjdk.java.net/jfx/pull/448/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=448=00
Issue:
On Wed, 31 Mar 2021 05:36:06 GMT, John Hendrikx wrote:
> Small fix to clear a reference to a removed node left by Scene$MouseHandler.
This pull request has now been integrated.
Changeset: 015dad07
Author: John Hendrikx
Committer: Kevin Rushforth
URL: https://git.openjdk.java.net/
On Wed, 31 Mar 2021 13:07:06 GMT, Kevin Rushforth wrote:
>> Small fix to clear a reference to a removed node left by Scene$MouseHandler.
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line
> 1019:
>
>> 1017: pane = null;
>> 1018:
>> 1019:
greatly from
it. It is however kept to a minimum.
I'd be happy to spend more time and work on this. Perhaps it would be
possible to collaborate on this?
--John
- Nir
[1]
https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issu
I've found that building controls in such a way to limit the
addition/removal of child Nodes as much as possible (for example by
making them invisible/unmanaged instead of adding/removing) has a huge
impact on performance.
If you are seeing a lot of CSS churn, this could be one of the causes.
On Wed, 31 Mar 2021 13:11:23 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix review comments
>
> modules/javafx.graphics/src/main/java/javafx/scene/Sc
> Small fix to clear a reference to a removed node left by Scene$MouseHandler.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Fix review comments
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/448/fi
On Wed, 31 Mar 2021 21:16:29 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line
>> 1019:
>>
>>> 1017: pane = null;
>>> 1018:
>>> 1019: System.gc();
>>
>> It
> Small fix to clear a reference to a removed node left by Scene$MouseHandler.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Add test compile dependency on :base for :graphics
-
Changes:
- all: ht
On Wed, 31 Mar 2021 21:43:02 GMT, Kevin Rushforth wrote:
> Did you find that it worked without the addition of the dependency to
> `build.gradle`? You didn't commit that change. I guess we'll see what the
> GitHub actions build shows.
I forgot to add the change I did in build.gradle, it
Not a solution to the problem (the color fringes on Mac apparently are
using almost fully saturated subpixels which seems like a serious
issue), but I see color fringes on most screens so I always just turn
this type of rendering off. It obviously depends on the pixel density
though as higher
On Mon, 2 Mar 2020 08:31:47 GMT, dannygonzalez
wrote:
>> Hmm .. personally, I would consider changing such a basic (and probably
>> highly optimized) implementation used all over the framework is a very high
>> risk change that at the worst outcome would detoriate internal and external
>>
On Thu, 16 Apr 2020 06:34:39 GMT, yosbits
wrote:
>> @hjohn
>> I haven't quantified exactly where all the listeners are coming from but the
>> Node class for example has various listeners on it.
>>
>> The following changeset (which added an extra listener on the Node class)
>> impacted
On Thu, 16 Apr 2020 07:11:58 GMT, John Hendrikx wrote:
>> The patch proposed here does not share the case where the listener deletion
>> performance becomes a bottleneck.
>>
>> I think that it is necessary to reproduce it by testing first, but
>>
>> If
On Thu, 16 Apr 2020 08:24:16 GMT, dannygonzalez
wrote:
>> The listeners added by `Node` are apparently internally required for
>> internal properties `TreeShowing` and `TreeVisible`, and are used to take
>> various decisions like whether to play/pause animations. There is also a
>> couple
On Thu, 16 Apr 2020 09:45:20 GMT, dannygonzalez
wrote:
>> @dannygonzalez Could you perhaps debug your application and take a look at
>> how large the following array is: a random node -> `scene` -> `value` ->
>> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just
>>
On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez
wrote:
>> I've tested this pull request locally a few times, and the performance
>> improvement is quite significant. A test with 20.000 nested stack panes
>> resulted in these average times:
>>
>> - Add all 51 ms
>> - Remove all 25 ms
>>
>>
On Fri, 17 Apr 2020 08:48:35 GMT, dannygonzalez
wrote:
>> @dannygonzalez I added a proof of concept here if you want to play with it:
>> https://github.com/openjdk/jfx/pull/185
>
> @hjohn Thanks for looking into this. It looks like your changes do improve
> the issue with the JavaFX thread
On Wed, 26 Aug 2020 17:44:20 GMT, yosbits
wrote:
>> So far, there are two alternative fixes for the bad performance issue while
>> scrolling TableView/TreeTableViews:
>>
>> - this one #108, that tries to improve the performance of excessive number
>> of `removeListener` calls
>> - the WIP
from it being a good companion to
`Val` (and less typing), I don't see a reason to implement `Var`.
--John
On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx mailto:hj...@xs4all.nl>> wrote:
On 02/04/2021 08:47, Nir Lisker wrote:
> Hi John,
>
> I've had my eyes set
On Tue, 16 Feb 2021 18:59:30 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>>
>> The initial year needs to be preserved. Please restore as
rt the aforementioned classes. The complete change
> should update these two classes to add their own listeners instead.
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Fix initial year in SubScene
-
On Fri, 5 Feb 2021 14:46:49 GMT, Ambarish Rapte wrote:
>> John Hendrikx has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Add missing TreeShowingExpressionTest which also tests SubScene
>> - Also dispo
On Fri, 5 Feb 2021 14:43:25 GMT, Ambarish Rapte wrote:
>> John Hendrikx has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Add missing TreeShowingExpressionTest which also tests SubScene
>> - Also dispo
On Fri, 17 Apr 2020 08:06:23 GMT, John Hendrikx wrote:
> This is a PoC for performance testing.
>
> It contains commented out code in PopupWindow and ProgressIndicatorSkin and
> two tests are failing because of that.
>
> This code avoids registering two listeners (on S
I don't know if this is useful or not, but I've pretty succesfully
combined a JavaFX UI with the MPV video player (also VLC), without
resorting to any kind of frame copying.
It basically involves finding the HWND id (or Window id on Linux) of
a JavaFX Stage, then telling MPV / VLC to render
until something
revalidates the property, so any changes made after the bidirectional
binding is established to this property will not be copied to the other
property (although the other way around will work).
--John
On 28/08/2021 22:14, John Hendrikx wrote:
Was it taken into account that when
Was it taken into account that when you register an invalidation listener:
property1.setValue(property2.getValue());
property1.addListener(binding);
property2.addListener(binding);
... that if property2 is currently invalid it will not send any further
invalidations?
On Fri, 14 May 2021 22:30:16 GMT, Michael Strauß wrote:
>> The internal BidirectionalBinding class implements bidirectional bindings
>> for JavaFX properties. The design intent of this class is to provide
>> specializations for primitive value types to prevent boxing conversions (cf.
>>
uot;Setting p2 to " + p1.get());
p2.set(p1.get());
}
else {
System.out.println("Setting p1 to " + p2.get());
p1.set(p2.get());
}
}
finally {
updating = false;
}
}
}
}
--John
On 28/08/2021 22:14, John Hendrikx
On 31/08/2021 17:52, Nir Lisker wrote:
Hi,
This is a continuation of the discussion that stemmed from changing
bidirectional bindings to use invalidation listeners instead of change
listeners [1].
The relevant issue in JBS is [2].
I have looked at removing the eager evaluation when
On 29/08/2021 01:34, Nir Lisker wrote:
This actually isn't an issue because adding an invalidation listener
revalidates the property as well (I'm not sure why, but I noticed this
before while working on fluent bindings).
There is an open issue on this:
On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strauß wrote:
> This PR fixes a bug that was introduced in #454.
>
> Since this fix might impact the performance considerations in the original
> PR, I ran a performance benchmark against the previous `ChangeListener`-based
> implementation, which
This ran for me until 15058 iterations, then the whole system froze for
a few seconds and the program threw an exception (without a stacktrace).
Windows 10, javafx.runtime.version: 16+8
This looks like some native resource getting exhausted (especially since
the whole system froze for a
In what order would you want them?
Windows itself isn't all that reliable either -- it will randomly
reorder my screens sometimes when resuming from sleep depending on how
quickly all the monitors respond. Currently my primary monitor is screen
2 according to Windows.
Using the bounds you
pproach
as it keeps the API that we're commiting to small and allows the highest
flexibility for future extensions.
If an agreement can be reached on the initial API, I can rework the PoC
and also add the unit tests (I'll need to convert the JUnit 5 tests I
have to JUnit 4).
--John
- Ni
On 15/09/2021 02:28, Nir Lisker wrote:
Sorry, I'm not quite sure what you mean by this. Could you elaborate?
The methods orElse and orElseGet are present in the PoC, and I think
they're highly useful to have to deal with nulls.
The methods that you call orElse and orElseGet
.map(x2 -> {
switch(x2.getY()) {
case ...
}
});
Or perhaps x is the correct property already, then it be:
windowsTitleProperty.bind(x.map(y -> {
switch(y) {
case ...
}
});
--John
On Mon, Sep 13, 2021 at 3:05 AM John Hendrikx wrote:
On 12
.
--John
[1]
https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote:
On 15/09/2021 02:28, Nir Lisker wrote:
Sorry, I'm not quite sure what you mean by this. Could you elaborate?
The methods orElse and orElseGet
I would like to provide some junit tests in a PR.
These are written in a nested style for easy readability. For example:
private StringProperty property = new SimpleStringProperty("A");
@Nested
class When_map_Called {
@Nested
class WithNull {
@Test
month release cycle is such that
features go in when ready, rather than necessarily being tied to a
specific release.
-- Kevin
On 8/4/2021 3:25 PM, John Hendrikx wrote:
Perhaps:
Fluent bindings for ObservableValue
https://github.com/openjdk/jfx/pull/434
It was received well I think
On 02/09/2021 11:57, Nir Lisker wrote:
So in order
to make sure that a new interested invalidation listener does not miss
the fact that a property was *already* invalid, the easiest solution
might have been to revalidate it upon registration of a new listener
But why does an
Perhaps:
Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434
It was received well I think, and there was some interest from Nir
Lisker to work on a proposal.
--John
On 30/07/2021 14:56, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention
On 04/08/2021 19:05, Ty Young wrote:
* A late "showing" property for when the application has been shown to
the user and all first viewing UI components have had their sizes
calculated and are being displayed, if it doesn't exist already and I'm
completely blind.
Do you mean a property
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:
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: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: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
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: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 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
> 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
, 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
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
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
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
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
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
.
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
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.
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
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
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):
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")
>
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 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
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
> 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
>
>
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
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.
>>
>>
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.
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: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'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
> 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 Fri, 24 Sep 2021 20:50:51 GMT, John Hendrikx wrote:
>> gradle/verification-metadata.xml line 121:
>>
>>> 119: >> value="569b6977ee4603c965c1c46c3058fa6e969291b0160eb6964dd092cd89eadd94"
>>> origin="Generated by Grad
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
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
101 - 200 of 254 matches
Mail list logo
