Tom,
Comments below.
On 21/08/2014 10:37 PM, Tom Schindl
wrote:
You are right in that it is an install time problem as well - i think
from a p2 point of view tp-resolution & install a fairly equal - i think
it is the same p2-API-call!
Yes, from our work with Oomph I know for a fact that the same
underlying p2 resolution mechanisms are at work.
The problem at runtime is:
a) javafx is not part of any EE so if you have a package import of
javafx OSGi will not wire your bundle because nobody at runtime
exposes a javafx-package, for javax the EE does that
I see what you mean. It seems related to this question
http://stackoverflow.com/questions/16753429/test-apache-felix-with-java-8-and-javafx
where the answer suggests org.osgi.framework.system.packages.extra
can play a role. But that seems problematic because it's so
global. Furthermore, I'm not sure one could declare such a thing
and not cause problems trying to run on Java 1.6, which still ought
to work. Other alternatives are also suggested
http://stackoverflow.com/questions/13240822/using-javafx-2-2-in-osgi-bundle,
but I'm sure you've done more research than I!
It all seems inconsistently different from how javax is handled, but
it's clear that javafx is handled differently in terms of bootstrap
visibility for the JRE, so I suppose some inconsistency is
unavoidable...
b) javafx is part of the ExtClasspath but Equinox does NOT look up
classes from there so in case you think you can get away with out
doing any package impports, Equinox will tell you that no javafx
classes are available
Exactly. In fact for Felix you do always need the package imports
for any non-java.* package dependencies, as I found out enabling
EMF's core runtime bundles to work properly as pure Felix bundles
during the Luna release.
So why fixing the runtime and tp/install problem differently (if you can
find a solution) if one - the current one - fixes all of them?
Being curious, I used the wonders of open source to look at
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx.
I see that it's literally creating a mirror image of the package
structure for javafx (among other things, presumably runtime
implementation support packages), and then simply exports those
packages (along with version numbers you've assigned):
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx/META-INF/MANIFEST.MF
How does this mechanism help the classes actually load at runtime?
Perhaps it's none of my business, but I'm curious... (BTW, I wonder
if package-info.java might be a better placeholder file in this
dummy/mirror structure?)
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?
Tom
On 21.08.14 22:20, Ed Merks wrote:
Tom,
It is my impression that this is also an install time resolution issue,
not just a TP resolution issue. Of course there is also the runtime
resolution issue: at that time there is a real JRE that must provide
resolutions to be able to load actual classes. So yes, that's
definitely a third and fundamental issue not to be mixed up with the
other two. At install time, you don't really know which JRE will be
available, so some fake units are (apparently) needed. When resolving
the TP, one ought to know which JRE is available, because there are JREs
registered with JDT that have such information (and there's even a
default), but (apparently) fake JREs are needed for that too. In any
case, at runtime, it better all just work with classpath magic because
there is definitely exactly one JRE available and it better be able to
load real classes that really work. Indeed it's easy to mix all these
things up, because each of these things better work in some consistent
and coherent sensible way. After all, if it works at runtime, but you
can't install the unit, or can't provision a target platform to develop
it, you'll never get to the stage of actually running it...
Cheers,
Ed
On 21/08/2014 9:43 PM, Tom Schindl wrote:
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@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
|
