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>: > 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-boun...@eclipse.org >>> [cross-project-issues-dev-boun...@eclipse.org] on behalf of Tom Schindl >>> [tom.schi...@bestsolution.at] >>> Sent: Thursday, August 21, 2014 3:37 AM >>> To: 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 >>> 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 >> 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 -- 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 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
