Maven jfxtras-test-support Test Scope

[samypr100]

Hello,

TL;DR, When pulling down JFX Extras as a library into an existing project, jfxtras-test-support is not marked with test scope on the module's maven dependencies. Can we change the scope or is there a particular reason this is not the case?

Currently the classpath is getting polluted with junit, hamcrest, mockito, assertj etc. as compile scope via the maven compiler plugin or equivalent in gradle. This causes the output jar to contain all test dependencies as compiled dependencies. This problem seems to have been introduced in 7bbf725310c0cb3fc09c740081cc57961676b38f

When using a modular build, there's also still:

requires transitive jfxtras.test_support;

that forces you to include all dependencies in the classpath. This makes <excludes> not help since the module will not be readable if it's excluded, failing the build.

Any insights appreciated.

Thanks!

[tbee]

Is it possible to define a test scope on modules? Because AFAIK it is not.

The whole setup with testing and modules is a bit of a problem. I've tried making test-support not a module, but than other things fail. I'm open to suggestions.

[tbee]

Ok. I've done some cleanup work the last weeks, and now I'm revisiting this topic and it seems to work now. Hang on.

[tbee]

Talked to soon, it still is a mess.

So if I leave the test-support module at runtime, everything is peachy. But if I add an additional module-info.java in src/main/test to add the test-support module only for test (and change the scope in Maven), many test fail because getResources is not finding things anymore (it is looking in test-classes instead of classes).

[samypr100]

I've added a Draft PR of what I meant, thank you for looking at it 👍 . Most test run for me (oh boy took a while). Some tests fail with output like

node=appointment=2014-01-01T00:00-2014-01-02T00:00;sumary=null, H expected:<966.375> but was:<1006.125>

Which might be environmental. Other tests pass entirely such as jfx-commons.

[tbee]

I've reacted to your PR; it is the same as what I have in my branch, but it abuses a non module dependency as a module. But I can't think of anything else either.

And yes, UI testing is quite sensitive.

[samypr100]

I'm assuming this issue might be resolved since 5041358f404ef68df2b18c7c4680df384f8df454 ?

[tbee]

I've traded one bad for another, but I think this is the lesser one. I'll attempt to release a r2-SNAPSHOT today so you can test it.

[tbee]

11-r2-SNAPSHOT is released to sonatype, you can give it a try

[samypr100]

@tbee Tried it, working great! Dependencies are clean when pulling and using the library

[tbee]

Great, I've pushed out 11-r2