JavaFX 11 maven snapshots - empty jars
Kevin Rushforth
kevin.rushforth at oracle.com
Fri Jul 13 15:39:56 UTC 2018
> 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 <mailto: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 <mailto: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
More information about the openjfx-dev
mailing list