JavaFX 11 maven snapshots - empty jars

[Kevin Rushforth]

 > 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