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.me...@gmail.com > <mailto:ed.me...@gmail.com>>: > >> 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-boun...@eclipse.org >>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> >>>> [cross-project-issues-dev-boun...@eclipse.org >>>> <mailto:cross-project-issues-dev-boun...@eclipse.org>] on behalf of >>>> Tom Schindl [tom.schi...@bestsolution.at >>>> <mailto:tom.schi...@bestsolution.at>] >>>> Sent: Thursday, August 21, 2014 3:37 AM >>>> To: cross-project-issues-dev@eclipse.org >>>> <mailto:cross-project-issues-dev@eclipse.org> >>>> 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@eclipse.org >>>>> 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@eclipse.org >>>> <mailto:cross-project-issues-dev@eclipse.org> >>>> 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@eclipse.org >>>> 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@eclipse.org >>> <mailto:cross-project-issues-dev@eclipse.org> >>> 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@eclipse.org >> <mailto:cross-project-issues-dev@eclipse.org> >> 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.nys...@itemis.de <mailto:alexander.nys...@itemis.de> > > 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@eclipse.org > 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
