>I don't think that will help, as the artifacts for the different platforms are not created inside the same gradle process. We don't do cross-compiling, so for each compileTarget a different machine and a different build process is used. >Hence, I think we have to deal with separate publications anyhow, right?
Yes, that would be correct. Scott's suggestion could work (and is what I would suggest in this situation) but would require more moving parts for a full build, which may be too complicated. On Sun, Jul 8, 2018 at 5:38 AM Johan Vos <johan....@gluonhq.com> wrote: > I don't think that will help, as the artifacts for the different platforms > are not created inside the same gradle process. We don't do > cross-compiling, so for each compileTarget a different machine and a > different build process is used. > Hence, I think we have to deal with separate publications anyhow, right? > > - Johan > > On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami <ket1...@gmail.com> wrote: > >> 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> <+49%20341%2092603047> >> >> >>> > E: gerd.mueller-schr...@hexagon.com >>> > >>> > Hexagon Geospatial >>> > Wittenberger Straße 15B >>> <https://maps.google.com/?q=Wittenberger+Stra%C3%9Fe+15B+%0D%0A+04129+Leipzig,+Germany&entry=gmail&source=g> >>> >>> <https://maps.google.com/?q=Wittenberger+Stra%C3%9Fe+15B+%0D%0A+04129+Leipzig,+Germany&entry=gmail&source=g>> >>> 04129 Leipzig, Germany >>> <https://maps.google.com/?q=Wittenberger+Stra%C3%9Fe+15B+%0D%0A+04129+Leipzig,+Germany&entry=gmail&source=g> >>> > 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 >> > -- ~Kenzie Togami
