Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen <alexander.nyssen@xxxxxxxxx>]

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>:

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
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 

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

--
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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail