JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Hi Steve,

I think we really want a solution that allows for as many use cases as
possible. If the current proposal is not working with Eclipse, we need to
fix it. I wonder if we want to create a javafx gradle plugin? We already
have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
general, a JavaFX gradle plugin that facilitates development of JavaFX on
any platform might be good.

I'm not sure that is a solution for all cases, as you don't want to force
people to work with gradle. Hence, a maven plugin might be worth
considering as well.

It is not a JavaFX specific issue though. We will see an increasing number
of related issues, where artifacts contain (platform-dependent) native
code. Previously, the Java SDK that you installed contained all
platform-specific libraries you needed. Moving these to separate projects
also moves the platform-specific libraries to the repositories, and require
the build tools to take care of this.
IMHO, this is something that needs to be discussed with a wider audience. I
want to discuss this at the OpenJDK Workshop (
http://openjdk.java.net/workshop).

- Johan

On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda <steve.hruda at gmail.com> wrote:

> Okay, I understand.
>
> If the empty jar will be the final solution, then I think I will find a
> workaround at our Gradle's build to avoid loading of such empty jars.
>
>
> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
> kevin.rushforth at oracle.com>:
>
> >
> > > Is there a plan to split the really platform dependent stuff (natives)
> > from the platform independent Code?
> >
> > Not any time soon. And that would cause it's own set of problems.
> >
> > In particular I would not be in favor of a solution that leaked new
> > "module names" for what is (and should remain) an implementation detail.
> >
> > -- Kevin
> >
> >
> > On 7/13/2018 8:25 AM, Steve Hruda wrote:
> >
> > Johan,
> > hmm but is that not quite the same in case of the classifier? Because I
> > also have to define a property or static value in case of the classifier.
> >
> > Kevin,
> > The same name could b e a problem.
> > "Module names, like package names, must not conflict. The recommended way
> > to name a module is to use the reverse-domain-name pattern that has long
> > been recommended for naming packages. "
> >
> > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations
> >
> > But something like a "javafx.controls.dummy" could help.
> >
> > Is there a plan to split the really platform dependent stuff (natives)
> > from the platform independent Code?
> >
> > Which would causein the end that the javafx.controls.jar would not be
> > empty?
> >
> > Maybe in that case it makes sense that the empty jar uses the module name
> > javafx.controls and the platform dependent uses e.g.
> javafx.controls.windows
> >
> > Regards,
> > Steve
> >
> >
> > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth <
> > kevin.rushforth at oracle.com>:
> >
> >> Would it help Eclipse if instead of an empty jar, the jar contained just
> >> the module-info.class file? Or will that then cause problems because of
> >> two .jar files with the same module name?
> >>
> >> -- Kevin
> >>
> >>
> >> On 7/13/2018 7:37 AM, Johan Vos wrote:
> >> > Hi Steve,
> >> >
> >> > Yes, that has been considered, but I'm more than happy to re-open the
> >> > discussion.
> >> >
> >> > The problem with javafx-controls-${javafx.platform} as the artifactId
> is
> >> > that in that case, the gradle developer is in all cases required to
> add
> >> the
> >> > platform suffix to the dependency, which makes it very hard to manage
> >> > JavaFX projects via version control, as the dependency file will
> >> hard-code
> >> > contain e.g. javafx-controls-linux, where other developers would use
> >> > javafx-controls-windows
> >> >
> >> > - Johan
> >> >
> >> >
> >> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda <steve.hruda at gmail.com>
> >> wrote:
> >> >
> >> >> Hi,
> >> >> Johan asked me to move the empty jar discussion to the mailing list.
> >> >>
> >> >> As I mentioned at GitHub, we did some tests with the published
> >> SNAPSHOT's
> >> >> and we had to force an exclude of the empty jars at the dependecies.
> >> >> Otherwise e.g. Eclipse shows a warning that the module name is
> instable
> >> >> because of the "auto-generated" module name in case of the empty
> jars.
> >> >>
> >> >> Thanks at Joeri for explaining the reason. I understand now the
> reason
> >> for
> >> >> the empty jar.
> >> >>
> >>
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
> >> >>
> >> >> I never tried it and I know that it doesn't fit to the familar
> >> handling of
> >> >> platform dependent jars...
> >> >>
> >> >> Have you thought about it to use the platform variable at the
> >> artifactId?
> >> >> Something like:
> >> >> <artifactId>javafx-controls-${javafx.platform}</artifactId>
> >> >>
> >> >> Best Regards,
> >> >> Steve
> >> >>
> >>
> >>
> >
> > --
> > Mit freundlichen Grüßen
> > Steve Hruda
> >
> >
> >
>
> --
> Mit freundlichen Grüßen
> Steve Hruda
>