You also need the native resources to go with it. All the DLLs or .so files or
what have you. That would imply yet another classifier. E.g. "win-x86",
"win-x64", etc. (OS X would typically only be 64-bit, or use a "fat" binary)
But what is the end goal? If it is just getting the jar for build
Thank you for this explanation, it was very easy to follow!
> (As an aside, with Maven I never check in my intellij project files, and tend
> to get my developers to open the POM file directly - the POM file becomes the
> source of truth and is IDE agnostic).
Ideally we'd do the same with Grad
Chiming in; I indeed would recommend sticking to a version naming scheme that
is compatible with Maven, like Daniel says. But there is an behavior in Maven
snapshots that may be of interest.
In Maven a snapshot can be updated as often as you like, but a release can be
generated only once, so
And one other thing I forgot to mention on this topic, the practice of
having platform specific jars that contain both the non-platform specific
stuff (usually 90%+) and the platform specific stuff does not fit that well
into Maven repo deployment.
Maven would prefer to have something like
- j
On Fri, Jul 26, 2013 at 3:47 PM, Richard Bair wrote:
I'm assuming here you're talking about publishing real builds (at least
> OpenJFX ones) and not on a local developers machine ('cause there'd be no
> advantage to that alone). But maybe you can help me understand another part
> of this problem,
eTargets {" , exactly as it is done for the "jfxrt" task for
> instance.
>
> Cheers,
> Rob
>
>
> -Ursprüngliche Nachricht-
> Von: [email protected] [mailto:
> [email protected]] Im Auftrag von Richard Bair
> Gesendet: Frei
lileTargets {" ,
exactly as it is done for the "jfxrt" task for instance.
Cheers,
Rob
-Ursprüngliche Nachricht-
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Richard Bair
Gesendet: Freitag, 26. Juli 2013 06:39
An: Daniel Zwolenski
> I've enabled that property and I now get a bunch of errors (100+), some
> random samples:
I just ran it both on open and closed builds and am not seeing any errors. I'm
on the latest graphics team repo. Are you building from master? (Not that it
should matter). You had a build working before
I've enabled that property and I now get a bunch of errors (100+), some
random samples:
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/web/src/main/java/javafx/scene/web/HTMLEditor.java:31:
error: package com.sun.javafx.scene.web.skin does not exist
import com.sun.javafx.scene.
You gotta set the BUILD_JAVADOC flag. Look in gradle.properties.template -- all
the different flags are pretty well documented there.
For sources, somebody else posted a message about wanting to do that, and I
think that's great. Just need to get a patch to the gradle build to create a
source z
For the Maven deploy I need a JAR of the JavaDoc and another containing the
sources. That's the rules.
How do I build these with the Gradle build? I tried:
> gradle javadoc
and can't see any JavaDoc anywhere in the build directory?
Admittedly I am running this on the 78 backport code, not the J
11 matches
Mail list logo
