Hi Ed,
I was not aware of the existence of such a mechanism. Actually, the org.eclipse.javafx bundle provided by e(fx)clipse is nothing more than such a fake bundle, which provides exactly the javafx packages (so others can resolve against it).
While I do not want to deny e(fx)clipse any responsibility, maybe it would be a good idea to think about how we could handle these kind of things in a more common way. Cheers Alexander Guys,
Isn't it a fundamental problem that the fake "a.jre" and "a.jre.se" units in the repo are only for Java 1.6? I.e., should there be units for 1.7 and 1.8? After all, how do javax packages new to 1.7 or 1.8 (if there are any) become visible for package imports in bundles?
I've never understood where these fake units come from and in which repos they should exist. For example, in https://bugs.eclipse.org/bugs/show_bug.cgi?id=431259 it's clear that orbit doesn't contain these units so you can't provision a target platform purely from the Orbit repo even if you only need things form Orbit in your TP.
If you're curious, look in download.eclipse.org/releases/luna/201406250900/content.jar and search for "<unit id='a.jre" where you'll see how it defines all the javax packages.
Perhaps the problem is even more complex and that even with such fake units, the packages still wouldn't be available on the classpath, but I don't understand how this is supposed to work unless there is a fake "a.jre" unit that explicitly lists "javafx"...
Regards, Ed
On 21/08/2014 6:03 PM, Tom Schindl wrote:
a) Does it Help --------------- Yes it does help IMHO.
Take for example the GEF4 people they have never ever thought about how JavaFX gets on the classpath they just use it like they use any other thing that is part of the JDK, with the small difference that they import javafx-packages in their MANIFEST.MF.
And there's more to JavaFX-SWT embedding than just getting FXCanvas on the classpath? e.g. I guess most people embedding JavaFX into SWT with the help of e(fx)clipse don't know that they need to call Platform.setImplicitExit(false)
b) Can an EPP package use JavaFX -------------------------------- Sure it can. I'm building an EPP like distro at http://efxclipse.bestsolution.at/install.html using the p2-director to install e(fx)clipse into a plain Eclipse SDK (+some WST, m2e, ...), p2 is clever enough to understand that there's an AdapterHook bundle is about to be installed and corrects the config.ini.
c) On repackaging + Equinox classloader loading ext --------------------------------------------------- It is a bad idea to rebundle anything from JDK because e.g. FXCanvas calls out to *internal* JavaFX APIs so while your application will work with JDK8u20 nobody on the world guarantees that it will still work with JDK8u40 unless you use the the jar that resides in your JDK.
You can do that with Equinox-Specific MANIFEST-Entries but that still leaves you with the heavy change of modifying the Equinox Classloader Hierarchy - I hoped Tom Watson fixes that Equinox specific thing with the Equinox rewrite but apparently it was not done.
Tom
On 21.08.14 16:11, Doug Schaefer wrote:
I guess this raises another question. What about the other way. e(fx)clipse doesn't get in the way, but does it help either? i.e. With e(fx)clipse on the release train, would it be possible to have an Eclipse EPP package use JavaFX?
All the magic required to get this actually running really confirms what many people are telling me, that JavaFX is ready for prime time. I love the direction, but there are a lot of hurdles to actually use it in product. In our testing at QNX we did change the classloader hierarchy to include ext, and we bundle-ified the swt-javafx jar. Worked but not sure we can do that in the Eclipse context.
Thanks, Doug. ________________________________________ From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Tom Schindl [tom.schindl@xxxxxxxxxxxxxxx] Sent: Thursday, August 21, 2014 3:37 AM To: cross-project-issues-dev@xxxxxxxxxxx Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
We are still using OSGi-AdapterHooks but so do others on the release train as well but we are not modify any classpath nor do we modify the classloader strategy of Equinox so I can't see how we can affect others inside the IDE.
As far as I can tell there's no other option than Adapter-Hooks to get JavaFX embedded in the Eclipse IDE because the swt-javafx bridge is not on ANY classpath.
For JavaFX8 in OSGi without adapter-hooks you'd have to modify the Equinox-Classloader hierarchy to include the extension-classpath which most likely breaks many other things and would still not fix your swt-javafx embedding.
Other IDEs built on top of Eclipse (e.g. STS) have already adopted our AdapterHook and so do others like GEF4 and hopefully many others as well.
To sum up, I can't see how having e(fx)clipse on the release train (and maybe in a download package) can affect others using JavaFX beside takeing the burden to understand how much such an integration has to work in every detail.
Tom
On 21.08.14 09:23, Max Rydahl Andersen wrote:
On 20 Aug 2014, at 10:46, Tom Schindl wrote:
Hi,
e(fx)clipse would like to join the Mars release as a +3 component because we depend on Xtext who is +2.
Our current plan is to contribute e(fx)clipse 2.0 because this is the first time we are joining (I need to make myself familiar with the process) I'm not sure we manage to contribute to M1 in time.
I'm curious - Did you find a way to use javafx without doing tweaks on the classpath/eclipse.ini that potentially affect others using javafx ?
/max http://about.me/maxandersen _______________________________________________ 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@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@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@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@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
|