State of maven artifacts

[Johan Vos]

Hi,

Have a look at the sample (maven/gradle) in
https://openjfx.io/openjfx-docs/

For maven, a pom.xml without any classifier is needed. This is because the
javafx module pom files have a javafx.pom as a parent, that will test the
current OS, and then use that as a classifier to download the correct
versions of the artifacts.

For gradle, the classifier needs to be in the build.gradle (e.g. see
https://openjfx.io/openjfx-docs/build.gradle) The logic in the sample shows
that the classifier can be detected though in the build.gradle.

- Johan


Op ma 1 okt. 2018 om 12:54 schreef Nir Lisker <nlisker at gmail.com>:

> Well, whatever the case is, it needs to be tested and documented. If we
> don't have that, we can't expect developers to use the library.
>
> I can run a series of tests with both Maven and Gradle (on Win10 with
> Eclipse).
>
> - Nir
>
> On Mon, Oct 1, 2018 at 12:43 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
> > I stopped using Maven years ago after switching to Gradle. So that could
> > be right.  I think there was an issue with Gradle processing transitive
> > dependencies with a classifier or something.  Thankfully Gradle makes it
> > easy to specify the right classifier.
> >
> > Scott
> >
> >
> > > On Sep 30, 2018, at 7:01 PM, Michael Ennen <mike.ennen at gmail.com>
> wrote:
> > >
> > > Scott,
> > >
> > > It seems that, for me at least, specifying the platform manually is not
> > necessary on
> > > Maven but is necessary on Gradle. Looking at the POMs themselves it
> > seems that
> > > the javafx-graphics, javafx-controls, etc. modules declare a dependency
> > on the
> > > platform specific artifacts:
> > >
> > > <dependency>
> > >     <groupId>org.openjfx</groupId>
> > >     <artifactId>javafx-base</artifactId>
> > >     <version>11</version>
> > >     <classifier>${javafx.platform}</classifier>
> > > </dependency>
> > >
> > > and declare as their parent:
> > >
> > > <parent>
> > >     <groupId>org.openjfx</groupId>
> > >     <artifactId>javafx</artifactId>
> > >     <version>11</version>
> > > </parent>
> > >
> > > and the POM for that parent has the platform-specific Maven profiles
> > built-in.
> > >
> > > So in other words the logic is already built in to the Maven POM and
> > therefore
> > > works out of the box with Maven but Gradle does not re-use the Maven
> > profile
> > > logic in the POM.
> > >
> > > Regards,
> > > Michael Ennen
> > >
> > > On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer <swpalmer at gmail.com
> > <mailto:swpalmer at gmail.com>> wrote:
> > > 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
> > <mailto: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
> <mailto:
> > 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
> > <mailto: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
> > <mailto: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
> > <mailto: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/ <
> > https://gluonhq.com/products/javafx/>
> > > >>>>> [2] https://openjfx.io/openjfx-docs/#introduction <
> > https://openjfx.io/openjfx-docs/#introduction>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > > >
> > > > --
> > > > Michael Ennen
> > >
> > >
> > >
> >
> >
>