Community
Participate
Working Groups
Product runs fine. When I try to export the export just hangs. No errors, no console output, nothing. Just hangs out there with the CPU maxed. It would be nice to have some kind of opportunity to diagnose what's gone wrong but instead I'm left randomly swapping out delta packs and update sites out of the target platform hoping some combination will work. Nothing so far has.
As so often happens, after spending hours and hours off and on over weeks trying to get something silly to work, I file a bug and then figure it out. I don't know why that is, but this one is particularly annoying. Here's the issue -- OS X export get's stuck when a JVM is selected -- with no error msg, just get's stuck. See: http://forums.dzone.com/eclipse/1281-eclipse-gets-stuck-during-export-product.html. The only way to get the export to succeed is to remove the JVM by unselecting the "Execution Environment" checkbox on the maxosx tab of the launching page. But why wasn't that working for me? I noticed finally that after checking the box and I save nothing changes in the file! Closing and reopening the dialog returns you to the previous state, but you don't notice that because its on a different page. I just never noticed that the editor wasn't getting marked as dirty because usually I had changed something else already. By hand-editing the xml file, and removing the line: <macos>org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/OSGi%Minimum-1.0</macos> I was able to get the build to work.
Moving to UI...
- Reproduced this: Product editor is not getting dirty when unchecking execution environment, even if made dirty by other means, the setting is not saved. - On OS X the execution environment cannot be bundled, so there should be no "macosx" tab in the execution environments in the first place. - The section should be labeled "Bundle Execution Environment with Product" instead of only "Execution Environment" to make clear that this is about bundling a JVM, not about setting the runtime environment.
See also bug 276005. Something definitely needs to change here. In general, this is almost always wrong on the Mac. For multi-platform export, this will be wrong for all platforms except the currently running platform. Even on non-mac, single platform export, this is probably wrong unless the user has explicitly gone and set up his installed JRE preferences with this in mind. It is interesting to set an execution environment for product export without bundling the JRE, particularly when building with p2 metadata. I suggest: 1) decouple the execution environment selection from the bundling of the jre 2) Setting the EE doesn't need to be done per-platform 3) Including the JRE should be a separate option. It should be per-platform and allow setting file system paths. Taking the path from the preferences can be a default. 4) We need to prevent known bad selections, most notably on Mac we can't allow the system framework jre to be selected. (Bug 276763 represents the only valid case for the Mac, this was never valid before 3.6)
(In reply to comment #3) > - The section should be labeled "Bundle Execution Environment with Product" > instead of only "Execution Environment" to make clear that this is about > bundling a JVM, not about setting the runtime environment. Yes! I've found that to be really confusing. Of course my product build needs to have an execution environment. One completely reasonable reading of "Execution Environment" is as the desired JDK / OSGi platform to <i>use</i> on the target platform. (In reply to comment #4) > See also bug 276005. This one is a frustrating example of a larger issue that I have no idea how to solve except by trying to educate users about this. I had actually seen that bug the last time I was trying to figure this out about a half year ago. I searched in vain for it. Bugzillas in general don't show up in google and anyway for good specificity it works much better to do a real bug search. Unfortunately, the referenced bug lists Mac OX X as the target OS, and PC as the target platform! So my search for "export hangs" in Cocoa and Mac missed it. > Something definitely needs to change here. Yup. > 1) decouple the execution environment selection from the bundling of the jre Totally. Again see above, these are separate issues, basically compliance vs. deployment. > 4) We need to prevent known bad selections, most notably on Mac we can't allow > the system framework jre to be selected. (Bug 276763 represents the only valid > case for the Mac, this was never valid before 3.6) Yes, and there is a much deeper issue here that I think makes this bug a kind of poster child. It's a perfect storm of having build fail in a spectacularly opaque way together with the interface not properly representing -- actually misrepresenting -- what is going on. The root issue is that there is nowhere for proper validation and inference to go. It shouldn't be in the form itself because then we're mixing view and model, but it can't be in the PDE architecture because ant doesn't really have any strong systematic way of enforcing behavior in any meaningful way. The only thing that you can do is hope that someone has thought of every possible thing that can go wrong in every conceivable build circumstances, and that is an unreasonable burden to place on anyone. We need instead to be specifying configurations that are known to be valid and then allowing people to step outside of that box if desired. But that all get's down to infrastructure and my guess is that it probably doesn't make much sense to seriously attack that issue without an underlying build framework that has a sound well separated place to put all of the semantic validation logic, i.e. a model-driven EMF solution ala B3 and Buckminster.
(In reply to comment #5) > Bugzillas in general don't show up in google and > anyway for good specificity it works much better to do a real bug search. Vote bug 298359 :)
This was mentioned three times by different people in the newsgroup the last days, seems to be a hurdle for many developers.
Created attachment 164787 [details] attempted patch Curtis can you look at this. Patch changes the product editor to explicitly include the JRE in the product. You can select an execution environment without including the JRE. It also allows an empty selection for the EE. EEs are still set per platform. Export on mac checks for "/System/Library/Frameworks/JavaVM.framework", I haven't tried this part yet since I don't have a mac.
I'll take a peek in the next couple of days.
Patch works great for me, I actually prefer the combo with an empty selection over the check box. The checkbox tracks enablement correctly and it handles files that previously had EEs set. I have applied the patch to HEAD.
Thanks for the fast action, folks! I'll try this out as soon as I get the time to grab and install the latest build..
(In reply to comment #10) > Patch works great for me, I actually prefer the combo with an empty selection > over the check box. The checkbox tracks enablement correctly and it handles > files that previously had EEs set. > > I have applied the patch to HEAD. I'm grad if you apply the patch to R3_5_maintenance branch also.
(In reply to comment #12) > I'm grad if you apply the patch to R3_5_maintenance branch also. 3.5.2 is shipped. There are no more planned releases in the 3.5.x stream.
> (In reply to comment #12) > > I'm grad if you apply the patch to R3_5_maintenance branch also. > > 3.5.2 is shipped. There are no more planned releases in the 3.5.x stream. Hi Masaki, Please note the workaround in comment #1. Once you know that this is an issue its not that hard to fix -- the real problem being for people who haven't seen this bug. :) hth, Miles
What was committed in https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=c12d257c2953ab89f41a5530d03978fc0fa4ac86 is actually missing a part of Andrew’s patch (comment 8). Was that intentional? The missing part is @@ -188,7 +189,12 @@ IJREInfo jreInfo = fProduct.getJREInfo(); for (int i = 0; i < configurations.length; i++) { String[] config = configurations[i]; + if (!jreInfo.includeJREWithProduct(config[0])) + continue; + File vm = jreInfo != null ? jreInfo.getJVMLocation(config[0]) : null; In my experience, that part is necessary (but not sufficient) for fixing bug 325368. See comments and patches there.
