ative code is messy IMO.
> JMOD files are supposed to solve that - they should be the preferred way to
> include JavaFX in a build, but installing the JavaFX SDK is a pain when we
> use dependency management for everything else.
>
> Scott
>
> > On Sep 10, 2021, at 9:10 AM,
dency management for everything else.
Scott
> On Sep 10, 2021, at 9:10 AM, Abhinay Agarwal wrote:
>
> JavaFX 17 Maven artifacts currently fail to compile modular JavaFX
> application. The non-modular application still works.
>
> To explain what's going on, let have a
bhinay Agarwal
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: JavaFX 17 Maven Artifacts
>
> Thanks allot for the detailed explanation!
>
> Than I wait until a final solution will be available. My plan was to upgrade
> all projects after the jdk 17 release to the newest jav
Hi Clemens,
If you have any thoughts/suggestions, please let us know.
-Abhinay
From: clemens.lantha...@itarchitects.at
Sent: Friday, September 10, 2021 6:46 PM
To: Abhinay Agarwal
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX 17 Maven Artifacts
Thanks
Thanks allot for the detailed explanation!
Than I wait until a final solution will be available. My plan was to upgrade
all projects after the jdk 17 release to the newest javafx version.
> On 10. Sep 2021, at 15:11, Abhinay Agarwal wrote:
>
> JavaFX 17 Maven artifacts currentl
JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application.
The non-modular application still works.
To explain what's going on, let have a look at JavaFX and its Maven
distribution since version 11:
1. JavaFX is distributed in non-platform (empty) and platform spe
JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application.
The non-modular application still work.
To explain what's going on, let have a look at JavaFX and its Maven
distribution since version 11:
1. JavaFX is distributed in non-platform (empty) and platform spe
the box with Maven but Gradle does not re-use the Maven
> > profile
> > > logic in the POM.
> > >
> > > Regards,
> > > Michael Ennen
> > >
> > > On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer > <mailto:swpal...@gmail.com>> wrote:
> > > I
25, 2018, 5:18 PM Nir Lisker wrote:
>
>> Hi,
>>
>> I haven't kept up with all of the Maven artifacts discussion. The website
>> mentioned in 2 places that there are maven artifacts, but does not mention
>> their ID's, group etc. These are the downloads page
linux".
On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote:
> Hi,
>
> I haven't kept up with all of the Maven artifacts discussion. The website
> mentioned in 2 places that there are maven artifacts, but does not mention
> their ID's, group etc. These are the downloads
Hi,
I haven't kept up with all of the Maven artifacts discussion. The website
mentioned in 2 places that there are maven artifacts, but does not mention
their ID's, group etc. These are the downloads page [1] and the getting
started page [2] (later you can see an example pom, but th
What you suggest would not be possible without considerable refactoring
of the modules with native code, since the Java module system does not
allow modules to be split across jars.
-- Kevin
On 8/27/2018 12:02 PM, Sam Carlberg wrote:
It would be moving the platform-independent classes (ie th
It would be moving the platform-independent classes (ie the public API)
into the empty jars, leaving the platform-specific classes and binaries
where they are in the platform JARs. The service loader mechanism seems
suitable for tying the APi and platform modules together at runtime.
I don't think
The platform-specific code is a general Java issue that needs to be solved
one day. Your suggestion basically comes down to moving the classfiles from
the platform-specific jars into the empty jars, right?
A problem with this is that currently, the jars are platform-dependent as
well (e.g. no OpenG
As I see it, providing only platform-specific artifacts makes it difficult
or impossible for third-party JavaFX libraries or frameworks to depend on
the JavaFX API and pass it along to consumers. Libraries don't care about
the platform-specific code - that's up the final application to determine -
As discussed before, there will be at least 2 ways developers can work with
JavaFX 11 and beyond:
1. use the standalone SDK, with platform-specifc distributions
2. use artifacts on (remote) repositories
For the second option, we have to distinguish between build systems (e.g.
maven/gradle) and rep
16 matches
Mail list logo
