| Hi Tom,
I was only referring to the org.eclipse.javafx bundle of e(fx)clipse, which - as far as I understood - is basically there to deal with the target resolving, while the org.eclipse.fx.osgi seems to perform the runtime resolving, right? I am no expert, but as far as the target resolving is concerned, there seemed to be an analogy. Maybe I'm wrong, I'm no expert on this...
Cheers Alexander Hi, You guys are mixing things! What Ed describes is only there for p2 so that it can resolve target platforms who are NOT mapped against a JRE but can only be used when a final EE (e.g. JavaSE-1.7 EE) exposes the package at runtime - this is true for javax stuff which is part of the Boot-Classpath & JSRed and so exported by the System bundle! For javafx this is NOT the case: a) it is not part of an EE defined by OSGi because it is not JSRed b) it is not found on the Boot-Classpath hence it will never by loaded by Equinox in a default config The bundles provided by e(fx)clipse satisfies both p2 & runtime OSGi if someone thinks there's a better solution which fixes all the problem of integrating JavaFX in Equinox-OSGi (without causing trouble for any other bundle) I'm happy to learn. So please don't mix target-platform dev time resolution and runtime resolution in Equinox and even resolving does not help you still have the classpath problem. Tom On 21.08.14 21:08, Alexander Nyßen wrote: 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
Am 21.08.2014 um 18:49 schrieb Ed Merks <ed.merks@xxxxxxxxx
<mailto:ed.merks@xxxxxxxxx>>:
Guys,
Isn't it a fundamental problem that the fake "a.jre" and "a.jre.se
<http://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
<http://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
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
[cross-project-issues-dev-bounces@xxxxxxxxxxx
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>] on behalf of
Tom Schindl [tom.schindl@xxxxxxxxxxxxxxx
<mailto:tom.schindl@xxxxxxxxxxxxxxx>]
Sent: Thursday, August 21, 2014 3:37 AM
To: cross-project-issues-dev@xxxxxxxxxxx
<mailto: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
<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
_______________________________________________
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
<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
_______________________________________________
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
|
