> 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.rushfo...@oracle.com <mailto:kevin.rushfo...@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.hr...@gmail.com <mailto:steve.hr...@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
