If you deploy it as a release, Sonatype won't allow overwriting, right? So its
behavior is different from a snapshot and you can't overwrite it each night.
Maybe frequently releasing EA builds is acceptable for Gradle, and Maven can
still use snapshots?
Or can Gradle be told to use a specific snapshot (20180702.224902-3), if the
latest fails somehow?
On 7-7-2018 11:28, Johan Vos wrote:
As another possible "solution" for this, we can avoid using SNAPSHOTS by
using releases instead. This would also make sense in aligning the maven
artifacts with the standalone Java SDK, by using the same build number
(e.g. javafx.graphics:11.0.0-ea18).
This will make it much easier for gradle projects.
The drawbacks I see are mainly semantic. The sonatype release repository is
for releases, and 11.0.0-ea18 is, well, an early-access release. But since
it is tagged, it can easily be traced down to an exact state of the code
repository, so I think it makes sense.
- Johan
On Fri, Jul 6, 2018 at 2:33 PM 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
