Maven JavaFx native libraries and OSGi

[Roman Kennke]

> Just in case the people who could answer this one tuned out because of all
> the other Maven stuff in the previous email, I'm just bumping this one:
> 
> 
> > Co-bundling jfx+jre will be an interesting addition to this whole problem.
> > Where will the dlls live then and will that mean just cause I have java
> > installed, I'll have the jfxrt.jar automatically on my classpath and it
> > will then have access to the dlls? If so all of this will be academic, we
> > won't need a maven dependency, anymore than we need one for java.util or
> > java.swing, etc. Can anyone elaborate on this and also the expected
> > timeframe for co-bundling?
> >
> 
> I'm particularly interested in the timeframe for the co-bundling? I've
> heard vague rumours ranging from first quarter next year to somewhere in
> 2013.

I still don't understand why this would be necessary in the first place.
A JavaFX as library, available as Maven artifact/dependency (ideally via
Maven central for maximum availability), with the dll/so embedded in the
JAR, with proper versioning, seems to be the best option to me. This
way, as a developer (or release manager or whatever) I have most control
over which version of what goes into an application, i.e. JRE version X
with JavaFX version Y. Imagine that I need JavaFX version Y which is
cobundled with JRE version Z which has a bug that makes it impossible
for me to use, but the JavaFX that is cobundled with JRE version X
doesn't yet have a feature that's introduced in JavaFX Y. And no, that's
not contrived.

Keeping it separate also has the additional advantage that there's less
(or no) chance that dependencies on internal stuff in the JRE creep into
the JavaFX code (as has happened with Swing and many other cobundled
former-external libs before).

Regards, Roman