Hi Tom,Hi,
From a e(fx)clipse point of view we will load the javafx libraries from
the JRE you are running on and JavaFX is a singleton like anything you
get from the JRE as well (you can not load multiple version of javafx at
once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you
run on JRE 1.8 you get JavaFX8 classes.
I was not challenging the fact its a singleton (I also think it has to be one), I was just wondering how that is related to the version constraints specified in the package exports (see comments below).
If you require Java8 features you need *your* bundle to require a an EE
for JavaSE-1.8 (in reality this might not be enough because what you'd
really want to spec is that you want OpenJDK/OracleJDK 1.8!).
Our fake bundle will never define an EE itself.
Please also note that because JavaFX is NOT JSRed they are adding
methods and features inside Java8 releases as well so an EE (e.g. in
8u40 you get a Dialog-API, ...).
That was what I meant with 'would not the bundle's BREE be the right indicator for its required JavaFX version'. I agree, the fact that its not JSRed will obviously not make it a 100% fit either, but neither will version constraints on the package imports (if they only indicate when a package was made available first). The more I think about it, the more I get the impression that a proper solution would probably require something like a BREE definition for JavaFX (or an extension of the current BREEs to this extend).
Anyway, what will definitely be needed is something like we now have in terms of Execution Environment Descriptors, so one can confirm that the code base only makes use of those JavaFX features it is actually intended to do.
The versioned package exports only tell you in which JavaFX release the
package was exposed the first time - I know this is not proper use of
OSGi-Versions and maybe we should have omitted them completely but that
would be a breaking change for anyone out there having versioned package
imports on the other had simply updateing them to javafx 8.0 seems
invalid as well.
I assumed a different usage of the version constraints and thus could not understand how consistency is ensured, but now that got clear. Actually, I don't have a strong opinion on that (yet). I just saw that a couple of problems occurred from something similar in the context of the javax.annotation orbit bundle (which also exports packages with a version constraint; thus preventing clients to be resolved against the respective packages now provided by a the JRE itself; see https://bugs.eclipse.org/bugs/show_bug.cgi?id=424274), but I assume we will not run into similar problems here unless JavaFX is placed on any of the default classpaths.
In case there's consensus from people here that our version package
exports are so wrong that this blocks integration I'm willing to break
people and require them to update their applications to use unversion
package imports.
Tom
Cheers Alexander On 07.09.14 11:57, Alexander Nyßen wrote: Let me add another question to this discussion: As JavaFX 8 is now
around (in addition to JavaFX 2.2), what will be the strategy to deal
with the different JavaFX versions?
Up to now it seems the org.eclipse.javafx bundle exports the javafx
packages with version constraints. As its a singleton, there will only
be one org.eclipse.javafx bundle in an Eclipse installation, and for
clients (with package imports) the available JavaFX version will thus
depend on that bundle's package exports. However, org.eclipse.javafx is
just a dummy bundle, so the version of the actually loaded JavaFX
classes will IMHO depend on the JRE that was used to start the
application (or whatever strategy the org.eclipse.fx.osgi fragment uses
to locate them).
How can you ensure that stays consistent? Doesn't it mean you will have
to remove the version constraints from the org.eclipse.javafx bundle as
soon as you are going to support multiple JavaFX versions (so the
version will be decided at runtime when org.eclipse.fx.osgi loads the
classes)? And wouldn't that imply that clients could also not specify
version constraints on their package imports, because these could
otherwise not be resolved? If this was the case, then would not the
bundle's BREE be the right indicator for its required JavaFX version
(as its done for all other JRE provided classes; of course implicating
some support for JavaFX within the Execution Environment Descriptors)?
Or does it mean for Mars there will only be an org.eclipse.javafx bundle
that is bound to BREE 1.8 and exposes JavaFX 8 only (and there will be
no support for JavaFX 2.2 and BREE 1.7)?
Cheers
Alexander
Am 22.08.2014 um 09:17 schrieb Alexander Nyßen
<Alexander.Nyssen@xxxxxxxxx <mailto:Alexander.Nyssen@xxxxxxxxx>>:
Tom,
I suppose all this means that no bundle with javafx dependencies can
resolve or run without this specific org.eclipse.fx.javafx bundle being
present. Again, it's none of my personal business, but if this is
indeed the only solution, would Orbit be a better host for such a thing?
org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.
what I infer from your detailed elaboration (thanks for bringing light
into the darkness) is that it would make no sense at all to separate
org.eclipse.fx.javafx from org.eclipse.fx.osgi, because without the
org.eclipse.fx.osgi fragment the org.eclipse.javafx bundle would be
useless at runtime.
Nevertheless, couldn't it be an option to have both within Orbit? From
a (simrel) participant client's perspective this could make things
easier (but probably only if these bundle would then also be provided
by some +0 component).
Tom
Cheers
Alexander
[1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de <http://www.itemis.de/>
alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael
Neuhaus
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
|
