Hi Johan, > It is very inconvenient, so if you know an easy way to get all snapshot version to be equal, I would love to hear that.
I think that the varying snapshots versions probably occur because a separate publication is set up for each `compileTarget`: https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564 I haven't used the Gradle maven-publish plugin yet but I think it could work if you instead iterate over each target where the artifacts are generated, which is the only place it's used anyways: compileTargets { t -> artifact project.tasks."moduleEmptyPublicationJar$t.capital" artifact project.tasks."modularPublicationJar$t.capital" { classifier "$t.name" } } On Fri, Jul 6, 2018 at 5:34 AM Johan Vos <johan....@gluonhq.com> wrote: > That is a known issue indeed, but I think it should be fixed in Gradle. We > can't easily upload all platforms using the same snapshot version, unless > I'm missing something? > > We ran into this before, when working with nd4j SNAPSHOT versions on > gradle. We "fixed" it by applying own plugin code, e.g. > > https://github.com/javafxports/javafxmobile-plugin/blob/master/src/main/groovy/org/javafxports/jfxmobile/plugin/JFXMobileConvention.groovy#L61 > > It is very inconvenient, so if you know an easy way to get all snapshot > version to be equal, I would love to hear that. But still, if other > libraries don't follow that approach (e.g. nd4j) it still means gradle > can't be used (unless you apply the "snapshotlocal" fix as in the above > link). > > I really hope this can be fixed, as I loved gradle (less typing), but this > issue is the reason I had to revert to maven. > > - Johan > > On Thu, Jul 5, 2018 at 10:43 PM MUELLER-SCHRAMM Gerd < > gerd.mueller-schr...@hexagon.com> wrote: > > > Hi Johan, > > > > Gradle doesn't ignore the classifier but there is no Windows- and > > Linux-version for the latest snapshot "20180702.224902-3". Gradle always > > checks for the latest snapshot, adds the classifier and tries to download > > this. The classifier 'mac' works with gradle. So all platform versions of > > JFX need the same snapshot version. > > > > Best regards, > > Gerd > > > > Gerd Müller-Schramm > > Software Developer, GeoMedia Smart Client Kommunal > > T: +49 341 92 60 30 47 <+49%20341%2092603047> > > E: gerd.mueller-schr...@hexagon.com > > > > Hexagon Geospatial > > Wittenberger Straße 15B > > 04129 Leipzig, Germany > > hexagongeospatial.com > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On > Behalf > > Of Johan Vos > > Sent: Donnerstag, 5. Juli 2018 11:03 > > To: openjfx-dev@openjdk.java.net List <openjfx-dev@openjdk.java.net> > > Subject: JavaFX 11 snapshots in maven sonatype > > > > A first batch of snapshots for the JavaFX 11 modules is now in the maven > > sonatype snapshot repository (see > > https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ > > although you probably don't want to work with these artifacts directly > but > > use build tools like maven or gradle to do that) > > > > This is work based on the not-yet-merged PR#83: > > https://github.com/javafxports/openjdk-jfx/pull/83 > > > > Basically, you need to specify which modules you need (transitive > > dependency management will be handled by maven as the modules contain a > > pom.xml with the same dependencies as the module-info.java), e.g. > > > > > > <dependency> > > <groupId>org.openjfx</groupId> > > <artifactId>javafx.controls</artifactId> > > <version>11.0.0-SNAPSHOT</version> > > </dependency> > > > > > > I have a few samples that show how you can use those artifacts in your > > maven project: > > https://github.com/johanvos/javafx11samples (note that this is a > temporary > > repository) > > the topics/javafx3d directory contains a number of standalone samples > that > > can be executed via mvn clean install exec:java > > > > Note that some of the samples create a build.gradle as well, but I never > > managed to get gradle working with the combination of classifiers and > > SNAPSHOT versions (it's actually the reason why I went back from gradle > to > > maven in other projects -- e.g. dl4j related). > > > > If someone else can somehow fix the build.gradle, that would be great of > > course. > > > > Before PR#83 is merged, it would be nice to have a few reports from > people > > using the snapshots. > > > > - Johan > > > > > -- ~Kenzie Togami
