State of maven artifacts

[Scott Palmer]

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