Re: [cross-project-issues-dev] Status and outlook for Mars M1 and Luna SR1 RC1
We left scout-rap disabled for Mars M1 on purpose. We expect to have it included in M2. Regards Adrian Von: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von David M Williams Gesendet: Mittwoch, 20. August 2014 21:09 An: cross-project-issues-dev@eclipse.org Betreff: [cross-project-issues-dev] Status and outlook for Mars M1 and Luna SR1 RC1 Been a busy few days! I think we are on the verge of getting some green builds again, but wanted to be sure to mention some hacks I had to make: For Luna I disabled mylyn-docs-intent.b3aggrcon (I also removed eclipselink which I hope doesn't surprise them, as they were not participants in the Sim. Release! ... definitely need to tighten up our process! ) For Mars, more changes. In addition to the above two changes, the following contain some repo or feature disabled. The first one in the list (and the last) are the only ones I made ... but thought it'd be good to call attention to the others in case anyone is surprised. I also had to adjust the feature ranges of emf.transaction and gmf.runtime. emf-transaction I'm pretty sure was a typo, but the latter I'm not so sure. I changed (increased) feature ranges so it would match what was in the repo it was pointing at, but as far as I know it might have been pointing at the wrong repo? soa-bpmn2-modeler.b3aggrcon emf-emf-rap.b3aggrcon gef.b3aggrcon mft.b3aggrcon scout-rap.b3aggrcon swtbot.b3aggrcon mylyn-docs-intent.b3aggrcon Still a few hours left, if anyone can safely make changes to fix up things to be included, or accurate. The good news is I think the warm up RC has been effective in getting Luna close to lined up ... the next RC's, in a few weeks, will have little time for major changes, so I hope this preliminary step avoids problems for those that should be real release candidates. Also, more good news, I think this is the most M1 participants we've ever had! ... I am glad everyone is getting a good early start on Mars, as it should be. Thanks! smime.p7s Description: S/MIME cryptographic signature ___ 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
[cross-project-issues-dev] EGF participating in Mars release
Hi, EGF will be participating in the Mars simultaneous release. Offset: +3 Release record: https://projects.eclipse.org/projects/modeling.emf.egf/releases/1.3.0 Regards, Benoit Benoit Langlois Model-Driven Engineering Expert Product Lead Thales/Corporate Engineering/IEE/IWB 18 Avenue du Maréchal Juin 92366 Meudon-La-Forêt Cedex France Phone: +33 (0)1 70 28 23 53 Visit our website : http://http://www.thalesgroup.com/www.thalesgroup.comhttp://www.thalesgroup.com/ Polarsys IWG: http://www.polarsys.orghttp://www.polarsys.org/ Kitalpha: https://www.polarsys.org/projects/polarsys.kitalpha EGF: http://eclipse.org/egf Sirius: http://eclipse.org/sirius ___ 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] Jubula participation in Mars release
Hi all, Just for the record: Jubula will continue to participate in the simultaneous release. Offset: +3 Release record: https://projects.eclipse.org/projects/technology.jubula/releases/3.1-mars - Achim BREDEX GmbH Mauernstr. 33 38100 Braunschweig Tel.: +49-531-24330-0 Fax: +49-531-24330-99 http: www.bredex.de Geschäftsführer: Andreas Vogel, Ulrich Obst, Achim Lörke Amtsgericht Braunschweig HRB 2450 smime.p7s Description: S/MIME cryptographic signature ___ 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
[cross-project-issues-dev] QVTo participating in Mars release
Hi, QVTo will be participating in Mars. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/4.0.0 Sergey Boyko ___ 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] Heads up on small change in availability time: 9 AM to 10 AM (Eastern)
Just so everyone knows that to expect ... Markus, Christopher and I have discussed our coordination on Friday mornings, and decided it would be easier to target 10 AM (Eastern) to make the repository visible, and (in many cases) the EPP packages visible at about that same time. Of course, there will be times that the EPP package will still be delayed ... since that depends on many things ... but we know that 10 AM will be easier to coordinate than 9 AM, just given our work schedules, time zones, etc. We'll see if this works better ... but since I like to sleep till noon, I'll still have to set an alarm. :) [And, just kidding, I do like to sleep till noon, but that hasn't happened in yeas.] Thanks, ___ 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
[cross-project-issues-dev] Release records for Mars
Hey folks. A lot of projects have already declared their intention to participate in Mars. I've been updating the participation page [1] as these declarations come in. The deadline to declare participation is M4 (December 19), but there's no reason to delay. For those of you who have not yet declared, here's a little help... To create a release record in the PMI: log in, visit your project's page, and click Create a new release. Minimally, provide a name for your release, and set the date to June 25/2015. Once you have this, send a note to this list informing the group of your project's name, participating release name, and your project's offset in the build order. I'll take care of updating the participation page. Note that initial project plans should be captured by M4 (December 19). At that time, it'd be great to see a few sentences of description and a theme or two. The description is what we'll use to describe your contribution in our press, blogs, tweets, etc., so providing a good (concise) description is a great way to help us help you. Note that we added a feature recently that automatically populates the Issues tab on your release by matching the release name to corresponding target milestone entries in Bugzilla [2]. We are working on some theming that will better contrast fixed vs. open bugs. If there is anything that you feel we can do to make this better, please open a bug against Community/Project Management Portal. If you have any questions, please ask. Thanks, Wayne [1] https://projects.eclipse.org/releases/mars [2] https://wiki.eclipse.org/Project_Management_Infrastructure/Release_Metadata#Issues -- 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
[cross-project-issues-dev] EMF Facet participating in Mars release
Hello, EMF Facet will be participating in Mars. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.emft.emf-facet/releases/0.5.0 Regards, Grégoire ___ 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
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] EMF Facet participating in Mars release
EMF Facet has been in incubation for four years. Isn't time to move out and get a nice apartment of your own? (i.e. graduate) (I'm practicing for a similar discussion with my son) Wayne On 21/08/14 12:41 PM, Grégoire Dupé wrote: Hello, EMF Facet will be participating in Mars. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.emft.emf-facet/releases/0.5.0 Regards, Grégoire ___ 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] MDT.BPMN2 participation in Mars release
Yes, yes it issorry, I wasn't paying attention ;) - Original Message - I've assumed +2 based on last year. Wayne On 19/08/14 01:05 PM, Bob Brodt wrote: The BPMN2 metamodel project will be participating in Mars. Release documentation can be found here: https://projects.eclipse.org/projects/modeling.mdt.bpmn2/releases/1.0.1 Robert (Bob) Brodt Senior Software Engineer JBoss by Red Hat ___ 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 ___ 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
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.
[cross-project-issues-dev] BPEL Designer participation in Mars release
The BPEL Designer project will be participating in the Mars release with a +3 offset. The release record is here: https://projects.eclipse.org/projects/soa.bpel/releases/1.0.5 Thanks, Bob Robert (Bob) Brodt Senior Software Engineer JBoss by Red Hat ___ 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] BPMN2 Modeler participation in Mars release
The BPMN2 Modeler project will be participating in the Mars release with a +3 offset. The release record is here: https://projects.eclipse.org/projects/soa.bpmn2-modeler/releases/1.1.1 Thanks, Bob Robert (Bob) Brodt Senior Software Engineer JBoss by Red Hat ___ 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, 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
Re: [cross-project-issues-dev] Did somebody just break git?
/gitroot wasn't mounted on one of the servers after a reboot. Try now. Denis On 08/21/2014 03:59 PM, Greg Watson wrote: When I try to view any Git repos [1], I get the message No repositories found”. Any ideas? Greg [1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git ___ 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
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
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release
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.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 ---
Re: [cross-project-issues-dev] Did somebody just break git?
Working again. Thanks! On Aug 21, 2014, at 4:09 PM, Denis Roy denis@eclipse.org wrote: /gitroot wasn't mounted on one of the servers after a reboot. Try now. Denis On 08/21/2014 03:59 PM, Greg Watson wrote: When I try to view any Git repos [1], I get the message No repositories found”. Any ideas? Greg [1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git ___ 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] Did somebody just break git?
When I try to view any Git repos [1], I get the message No repositories found”. Any ideas? Greg [1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git ___ 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 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
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! 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 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 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? 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.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
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
