I thought I replied to the list, and not just you. Probably easier to use the module name as artifactId, but it seems odd though and stands out against all the rest of dependencies naming using a dash delimiter.
Den tor. 5. jul. 2018, 19:02 skrev Johan Vos <johan....@gluonhq.com>: > The name is the same name as the module (in module-info.java). > I'm very open to discuss this though, so if you want to start a > discussion, send it to the list? I personally have no real preference for > naming, but it's better to change the name now instead of next year :) > > - Johan > > On Thu, Jul 5, 2018 at 6:27 PM Sverre Moe <sverre....@gmail.com> wrote: > >> Great work. >> >> One oddity. Shouldn't artifactId be javafx-controls, instead of >> javafx.controls? >> Never seen any dependencies that used punctuation as delimiter in >> artifactId. >> >> /Sverre >> >> Den tor. 5. jul. 2018 kl. 11:04 skrev Johan Vos <johan....@gluonhq.com>: >> >>> 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 >>> >>
