I think the more general problem is that they don‘t run on the module-path - in
the m2e case this because the modules are transitive deps and those are not
supported properly
Tom
Von meinem iPhone gesendet
> Am 04.11.2018 um 16:17 schrieb José Pereda <jose.per...@gluonhq.com>:
>
> I've just noticed that this issue happens not only with Maven but also with
> Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
> running gradle tasks from Eclipse.
>
> The same proposed workaround can be applied to the build file:
>
> run {
>
> systemProperty "java.library.path", "C:\tmp"
>
> }
>
>
>
>
> On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth <kevin.rushfo...@oracle.com>
> wrote:
>
>>
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>>
>> Yes, it seems like a workaround rather than a fix...
>>
>> -- Kevin
>>
>>
>>> On 10/21/2018 10:45 AM, Johan Vos wrote:
>>> Hi Tom,
>>>
>>> Nice workaround, but what do you think needs to be done to fix it? Can
>> the
>>> java.library.path somehow be changed in a plugin or so?
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>>>
>>> - Johan
>>>
>>> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <tom.schi...@bestsolution.at
>>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just wanted to make you aware that if you run a JavaFX-11 application
>>>> from within Eclipse it is very likely that you'll get an error like
>> this.
>>>>
>>>>> Exception in thread "WindowsNativeRunloopThread"
>>>> java.lang.NoSuchMethodError: <init>
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>>>> Method)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>>> Exception in thread "JavaFX Application Thread"
>>>> java.lang.NullPointerException
>>>>> at
>>>>
>> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
>>>> because Eclipse sets a java.library.path who also contains the
>>>> JVM-Directories used to launch your Eclipse IDE.
>>>>
>>>> The simple work-around is to add
>>>> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>>>> configuration.
>>>>
>>>> Small tiny question on the side: Wouldn't it make sense to version our
>>>> .dlls somehow to match the release eg glass-11.dll?
>>>>
>>>> Tom
>>>>
>>>> --
>>>> Tom Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>>>
>>
>>
>
> --
