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 Am 21.08.2014 um 21:43 schrieb Tom Schindl <tom.schi...@bestsolution.at>: > 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 -- 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
