+1 for getting it the "normal" way..
Sven
Tom Eugelink <t...@tbee.org> schrieb am Mo., 26. März 2018, 10:59:
> I totally assumed that, when JavaFX is separated out, it will distributed
> as an artifact on Maven central (or similar) so it can be included like a
> dependency. Feels like a no brainer?
>
>
> On 26-3-2018 10:50, Johan Vos wrote:
> > Hi,
> >
> > I want to start a discussion on distributing JavaFX as an SDK versus
> > distributing its modules via the traditional build and distribution
> > mechanisms.
> >
> > Personally, I think relying on an SDK is too much a barrier. It requires
> > users to manually download software from the exact right place, and
> > "install" it on the exact right target. If a version changes, you have to
> > manage that manually.
> >
> > That is how JavaFX was distributed before it was bundled with the JDK, so
> > it makes sense to provide that option (although me and others will
> probably
> > never use that).
> >
> > Today however, when a developer has a dependency on a library or
> framework
> > (including property files and native code), he uses his build tools (e.g.
> > maven/gradle) to manage the download/install//update of those
> > libaries/frameworks.
> > If you rely on Spring, Apache Commons, slf4j,... you don't download those
> > SDK's but you point to the group-name-version triplet in your pom.xml or
> > build.gradle file. I don't see why JavaFX would be different here.
> >
> > When someone is new to JavaFX, or is considering JavaFX, I think chances
> on
> > success will be much bigger if that person simply needs to add e.g.
> > dependencies {
> > compile: 'javafx:javax.graphics:11.0.0'
> > }
> > to his build.gradle and then rely on gradle (or maven) and
> jcenter/sonatype
> > to make sure the correct version with all its dependencies are installed
> > (in a maven/gradle local cache)
> >
> > - Johan
>
>
>
