Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
What can I do to bring this discussion forward? Should I open a bug against JDT, PDT, or cross-projects? It seems that up to now GEF is the only JavaFX consumer at Eclipse (or at least in the release train), which explains why there does not seem to be a lot of interest (yet). Nevertheless, an accepted convention on how to properly deal with JavaFX dependencies (package imports vs. BREE) and additional tool support that (augmenting what e(fx)clipse already provides) would allow clients to version-constrain their JavaFX dependencies (and to validate that their implementation obeys these constraints), would probably be very much valued by all who want to use JavaFX in an OSGi/Eclipse setting... Cheers Alexander Am 09.09.2014 um 18:33 schrieb Alexander Nyßen alexander.nys...@itemis.de: As already said, I also got the impression that the bundle's BREE could be the way to go. Having considered the ExecutionEnvironment guidelines at http://wiki.eclipse.org/Execution_Environments, and especially the section on 'XML and other optional JRE pieces', I think it pretty much burns down to the question of whether we want to/are able to regard JavaFX as an optional JRE piece or not. That is, the way we currently access JavaFX trough e(fx)clipse pretty much resembles what the ExecutionEnvironment guide describes as the recommended handling of an optional JRE piece. However, as already laid out, I have the impression that the special constraints that hold for the org.eclipse.javafx bundle (which does not bundle any classes itself but only serves as a placeholder) will probably require some different handling compared to the org.w3c.dom bundle that is named as an example in the guide. In addition, only a client bundle's BREE will probably be able to capture its exact JavaFX version requirements, as the different JavaFX versions cannot be differentiated on the level of packages alone (even if the org.eclipse.javafx bundle would not use the version constraints on its package-exports like it currently does). On the other hand, as JavaFX is not JSRed (as indicated by Tom), we will probably end up with quite a few new EEs to handle that properly... Cheers Alexander Am 08.09.2014 um 18:31 schrieb Doug Schaefer dschae...@qnx.com: I think I keep asking this question, but isn't there a way to define a new execution environment to describe the environment that enables JavaFX on Java 8? I thought that's what they were for. Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Tom Schindl Sent: Monday, September 8, 2014 4:09 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release Hi, From a e(fx)clipse point of view we will load the javafx libraries from the JRE you are running on and JavaFX is a singleton like anything you get from the JRE as well (you can not load multiple version of javafx at once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you run on JRE 1.8 you get JavaFX8 classes. If you require Java8 features you need *your* bundle to require a an EE for JavaSE-1.8 (in reality this might not be enough because what you'd really want to spec is that you want OpenJDK/OracleJDK 1.8!). Our fake bundle will never define an EE itself. Please also note that because JavaFX is NOT JSRed they are adding methods and features inside Java8 releases as well so an EE (e.g. in 8u40 you get a Dialog-API, ...). The versioned package exports only tell you in which JavaFX release the package was exposed the first time - I know this is not proper use of OSGi-Versions and maybe we should have omitted them completely but that would be a breaking change for anyone out there having versioned package imports on the other had simply updateing them to javafx 8.0 seems invalid as well. In case there's consensus from people here that our version package exports are so wrong that this blocks integration I'm willing to break people and require them to update their applications to use unversion package imports. Tom On 07.09.14 11:57, Alexander Nyßen wrote: Let me add another question to this discussion: As JavaFX 8 is now around (in addition to JavaFX 2.2), what will be the strategy to deal with the different JavaFX versions? Up to now it seems the org.eclipse.javafx bundle exports the javafx packages with version constraints. As its a singleton, there will only be one org.eclipse.javafx bundle in an Eclipse installation, and for clients (with package imports) the available JavaFX version will thus depend on that bundle's package exports. However, org.eclipse.javafx is just a dummy bundle, so the version of the actually loaded JavaFX classes will IMHO depend on the JRE that was used to start the application (or whatever strategy the org.eclipse.fx.osgi fragment uses to locate
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
As already said, I also got the impression that the bundle's BREE could be the way to go. Having considered the ExecutionEnvironment guidelines at http://wiki.eclipse.org/Execution_Environments, and especially the section on 'XML and other optional JRE pieces', I think it pretty much burns down to the question of whether we want to/are able to regard JavaFX as an optional JRE piece or not. That is, the way we currently access JavaFX trough e(fx)clipse pretty much resembles what the ExecutionEnvironment guide describes as the recommended handling of an optional JRE piece. However, as already laid out, I have the impression that the special constraints that hold for the org.eclipse.javafx bundle (which does not bundle any classes itself but only serves as a placeholder) will probably require some different handling compared to the org.w3c.dom bundle that is named as an example in the guide. In addition, only a client bundle's BREE will probably be able to capture its exact JavaFX version requirements, as the different JavaFX versions cannot be differentiated on the level of packages alone (even if the org.eclipse.javafx bundle would not use the version constraints on its package-exports like it currently does). On the other hand, as JavaFX is not JSRed (as indicated by Tom), we will probably end up with quite a few new EEs to handle that properly... Cheers Alexander Am 08.09.2014 um 18:31 schrieb Doug Schaefer dschae...@qnx.com: I think I keep asking this question, but isn't there a way to define a new execution environment to describe the environment that enables JavaFX on Java 8? I thought that's what they were for. Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Tom Schindl Sent: Monday, September 8, 2014 4:09 AM To: cross-project-issues-dev@eclipse.org Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release Hi, From a e(fx)clipse point of view we will load the javafx libraries from the JRE you are running on and JavaFX is a singleton like anything you get from the JRE as well (you can not load multiple version of javafx at once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you run on JRE 1.8 you get JavaFX8 classes. If you require Java8 features you need *your* bundle to require a an EE for JavaSE-1.8 (in reality this might not be enough because what you'd really want to spec is that you want OpenJDK/OracleJDK 1.8!). Our fake bundle will never define an EE itself. Please also note that because JavaFX is NOT JSRed they are adding methods and features inside Java8 releases as well so an EE (e.g. in 8u40 you get a Dialog-API, ...). The versioned package exports only tell you in which JavaFX release the package was exposed the first time - I know this is not proper use of OSGi-Versions and maybe we should have omitted them completely but that would be a breaking change for anyone out there having versioned package imports on the other had simply updateing them to javafx 8.0 seems invalid as well. In case there's consensus from people here that our version package exports are so wrong that this blocks integration I'm willing to break people and require them to update their applications to use unversion package imports. Tom On 07.09.14 11:57, Alexander Nyßen wrote: Let me add another question to this discussion: As JavaFX 8 is now around (in addition to JavaFX 2.2), what will be the strategy to deal with the different JavaFX versions? Up to now it seems the org.eclipse.javafx bundle exports the javafx packages with version constraints. As its a singleton, there will only be one org.eclipse.javafx bundle in an Eclipse installation, and for clients (with package imports) the available JavaFX version will thus depend on that bundle's package exports. However, org.eclipse.javafx is just a dummy bundle, so the version of the actually loaded JavaFX classes will IMHO depend on the JRE that was used to start the application (or whatever strategy the org.eclipse.fx.osgi fragment uses to locate them). How can you ensure that stays consistent? Doesn't it mean you will have to remove the version constraints from the org.eclipse.javafx bundle as soon as you are going to support multiple JavaFX versions (so the version will be decided at runtime when org.eclipse.fx.osgi loads the classes)? And wouldn't that imply that clients could also not specify version constraints on their package imports, because these could otherwise not be resolved? If this was the case, then would not the bundle's BREE be the right indicator for its required JavaFX version (as its done for all other JRE provided classes; of course implicating some support for JavaFX within the Execution Environment Descriptors)? Or does it mean for Mars there will only be an org.eclipse.javafx bundle that is bound to BREE 1.8 and exposes JavaFX
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
Let me add another question to this discussion: As JavaFX 8 is now around (in addition to JavaFX 2.2), what will be the strategy to deal with the different JavaFX versions? Up to now it seems the org.eclipse.javafx bundle exports the javafx packages with version constraints. As its a singleton, there will only be one org.eclipse.javafx bundle in an Eclipse installation, and for clients (with package imports) the available JavaFX version will thus depend on that bundle's package exports. However, org.eclipse.javafx is just a dummy bundle, so the version of the actually loaded JavaFX classes will IMHO depend on the JRE that was used to start the application (or whatever strategy the org.eclipse.fx.osgi fragment uses to locate them). How can you ensure that stays consistent? Doesn't it mean you will have to remove the version constraints from the org.eclipse.javafx bundle as soon as you are going to support multiple JavaFX versions (so the version will be decided at runtime when org.eclipse.fx.osgi loads the classes)? And wouldn't that imply that clients could also not specify version constraints on their package imports, because these could otherwise not be resolved? If this was the case, then would not the bundle's BREE be the right indicator for its required JavaFX version (as its done for all other JRE provided classes; of course implicating some support for JavaFX within the Execution Environment Descriptors)? Or does it mean for Mars there will only be an org.eclipse.javafx bundle that is bound to BREE 1.8 and exposes JavaFX 8 only (and there will be no support for JavaFX 2.2 and BREE 1.7)? Cheers Alexander Am 22.08.2014 um 09:17 schrieb Alexander Nyßen alexander.nys...@itemis.de: Tom, 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? org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime. what I infer from your detailed elaboration (thanks for bringing light into the darkness) is that it would make no sense at all to separate org.eclipse.fx.javafx from org.eclipse.fx.osgi, because without the org.eclipse.fx.osgi fragment the org.eclipse.javafx bundle would be useless at runtime. Nevertheless, couldn't it be an option to have both within Orbit? From a (simrel) participant client's perspective this could make things easier (but probably only if these bundle would then also be provided by some +0 component). Tom Cheers Alexander [1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java ___ 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 ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
Hi Wayne, I create a release entry, we'll fill it with content (release plan) in the days to come. Tom [1]https://projects.eclipse.org/projects/technology.efxclipse/releases/2.0.0 On 20.08.14 16:20, Wayne Beaton wrote: You need to create a release record in the PMI: https://projects.eclipse.org/projects/technology.efxclipse/create-release Wayne On 20/08/14 04:46 AM, 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. Tom ___ 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 -- Wayne Beaton @waynebeaton The Eclipse Foundation EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
Perfect. Thanks, Wayne On 21/08/14 03:12 AM, Tom Schindl wrote: Hi Wayne, I create a release entry, we'll fill it with content (release plan) in the days to come. Tom [1]https://projects.eclipse.org/projects/technology.efxclipse/releases/2.0.0 On 20.08.14 16:20, Wayne Beaton wrote: You need to create a release record in the PMI: https://projects.eclipse.org/projects/technology.efxclipse/create-release Wayne On 20/08/14 04:46 AM, 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. Tom ___ 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 -- Wayne Beaton @waynebeaton The Eclipse Foundation EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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 -- Wayne Beaton @waynebeaton The Eclipse Foundation EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
--- 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
On 21.08.14 22:18, Alexander Nyßen wrote: 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 No this is wrong org.eclipse.javafx is there so that: a) the target platform resolves b) at runtime bundles who do an import-package of javafx get physically wired to org.eclipse.javafx c) the classloader constructed for org.eclipse.javafx is provided by the org.eclipse.fx.osgi adapter hook. resolving is concerned, there seemed to be an analogy. Maybe I'm wrong, I'm no expert on this... Yep you are wrong. Tom ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
Tom, Von meinem iPhone gesendet Am 21.08.2014 um 22:32 schrieb Tom Schindl tom.schi...@bestsolution.at: On 21.08.14 22:18, Alexander Nyßen wrote: 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 No this is wrong org.eclipse.javafx is there so that: a) the target platform resolves b) at runtime bundles who do an import-package of javafx get physically wired to org.eclipse.javafx c) the classloader constructed for org.eclipse.javafx is provided by the org.eclipse.fx.osgi adapter hook. that's actually what I understood and was referring to (maybe that didn't get clear). If I try to relate this to what Ed said, a) and b) seem to be about 1) target and 2) installation resolving (which I falsely subsumed under just target resolving), while b) as well as c) seem to be related to 3) runtime resolving. Maybe the jre dummy bundle mechanism works different then I expect it to work, but with respect to 1) and 2), the org.eclipse.javafx bundle seemed to play a similar role, so that's where I saw the analogy. I was not referring to the role it plays in 3), which seems to make the difference. resolving is concerned, there seemed to be an analogy. Maybe I'm wrong, I'm no expert on this... Yep you are wrong. Tom Cheers Alexander ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
While you're at it, maybe it would be interesting to integrate e(fx)clipse in a package? Maybe the Java package? A bug report at [1] could help starting a discussion about this ;-) [1] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPPcomponent=java-package Thanks, Markus On Wed, Aug 20, 2014 at 10:46 AM, Tom Schindl tom.schi...@bestsolution.at 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. Tom ___ 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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
You need to create a release record in the PMI: https://projects.eclipse.org/projects/technology.efxclipse/create-release Wayne On 20/08/14 04:46 AM, 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. Tom ___ 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 -- Wayne Beaton @waynebeaton The Eclipse Foundation EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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
