State of maven artifacts

[Scott Palmer]

I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven (profiles?) or Gradle.

That’s what worked for me anyway.

Scott

> On Sep 26, 2018, at 6:19 AM, Michael Ennen <mike.ennen at gmail.com> wrote:
> 
> And just to reiterate and confirm for anyone trying to get a handle on using
> the Maven artifacts - it is *NOT* necessary to manually specify the platform
> classifier when using maven or gradle (nor add the automatic tricks to your
> own project) because the JavaFX artifacts will automatically detect the
> platform you are building on and pull in the correct artifacts, right?
> 
> Thanks for your work in this area Johan.
> 
> On Wed, Sep 26, 2018 at 12:31 AM Johan Vos <johan at lodgon.com> wrote:
> 
>> The problem with that is that there is no cross-platform version of the
>> jars itself. The windows-jar for the graphics module contains different
>> Java classes than the linux jar, for example.
>> The top-level API's are the same of course, hence the logical Java module
>> is the same, but different physical jars are really needed.
>> I realise this may be strange at compile time, where you only care about
>> the top-level API's. Therefore, people added nice "tricks" to both a
>> pom.xml and build.gradle system to automatically detect the current (host)
>> operating system, and making sure the correct artifacts are then used.
>> 
>> What I really wanted to avoid is that developers had to manually add their
>> platform (e.g. "win") in the build files, as this would break
>> cross-platform development (imagine you're in a team with a win and a linux
>> user, and they constantly change the pom.xml or build.gradle file for
>> this...).
>> 
>> I think the current solution deals pretty well with the current situations,
>> where there are different concepts in gradle/maven/sonatype and in the Java
>> module system.
>> 
>> - Johan
>> 
>> 
>> 
>> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker <nlisker at gmail.com>:
>> 
>>> Thanks Sam, that solved it. For some reason I was thinking that if you
>>> don't specify the platform it downloads a version with all native
>>> dependencies for cross compilation.
>>> 
>>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <sam.carlberg at gmail.com>
>>> wrote:
>>> 
>>>> The libraries are in artifacts with platform-specific classifiers. The
>>>> artifacts with no classifiers that you currently depend on are
>> completely
>>>> empty.
>>>> 
>>>> You need to depend on "org.openjfx:javafx-base:11:$platform", where the
>>>> platform is one of "win", "mac", or "linux".
>>>> 
>>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker <nlisker at gmail.com> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I haven't kept up with all of the Maven artifacts discussion. The
>>> website
>>>>> mentioned in 2 places that there are maven artifacts, but does not
>>> mention
>>>>> their ID's, group etc. These are the downloads page [1] and the
>> getting
>>>>> started page [2] (later you can see an example pom, but that doesn't
>>>>> count).
>>>>> 
>>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
>> finds
>>>>> the artifacts. It should be written in the above pages if this is
>>> correct.
>>>>> 
>>>>> On the usability side it's worse. I'm using Eclipse and during
>>> compilation
>>>>> I'm getting error messages that JavaFX classes like BooleanProperty
>>> can't
>>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem?
>>>>> 
>>>>> If I use the SDKs, can I point Gradle and Maven to them if it will
>> solve
>>>>> the problem?
>>>>> 
>>>>> - Nir
>>>>> 
>>>>> [1] https://gluonhq.com/products/javafx/
>>>>> [2] https://openjfx.io/openjfx-docs/#introduction
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Michael Ennen