Include processing4-javafx in Gradle packaging

[micycle1]

@Stefterv

I think you should consider bundling processing4-javafx with the processing core gradle artifact (as I do in https://github.com/micycle1/processing-core-4/)

Otherwise one cannot use the FX2D renderer.

Also, why must I as a user declare the https://jogamp.org/ repository for jogl? Shouldn't this artifact's gradle do that?

[Stefterv]

Hi @micycle1!

I will, do you think it would also work as a seperate package? I'm more inclined to head in that direction.

Re: the jogamp repo, completely agree, I hadn't found a way to do that but have to admit I didn't look to deep into it either

[Stefterv]

Reading the Sonatype Documentation:
https://central.sonatype.org/publish/requirements/#a-complete-example-pom
"We discourage the usage of <repositories> and <pluginRepositories>, instead publish any required components to the Central Repository. This applies for your own components as well as for 3rd party artifacts." I'm not sure what would happen if we try to publish with the repositories linked but maybe we would need to upload the JOGL artifacts too

[micycle1]

A separate package is probably best, but if it's then added as dependency to core, circularity is introduced (since fx package uses PSurface etc).

(Alternatively, let user specify when they want FX and don't add as dependency to core).

[micycle1]

"Discourage" would imply it works, but not according their best practice.

[Stefterv]

Looking at this again, if we include the Processing JavaFX classes into core, people outside of Processing can bring their own JavaFX and it'll work correct? Would that conflict for people who have the JavaFX library installed for Processing?

[micycle1]

Looking at this again, if we include the Processing JavaFX classes into core, people outside of Processing can bring their own JavaFX and it'll work correct? Would that conflict for people who have the JavaFX library installed for Processing?

"their own" - - do mean version number?

As an aside, In maven there's an <optional> tag for dependencies that seems appropriate here. Worth investigating the gradle equivalent.

If the package/classpath remains the same, ai suppose it would be ambiguous in the processing IDE as to which purfacefx to use.