State of maven artifacts

Nir Lisker nlisker at gmail.com
Mon Oct 1 10:53:55 UTC 2018


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
> >
> >
> >
>
>


More information about the openjfx-dev mailing list