Bugzilla – Full Text Bug Listing
| Summary: | Product export bundles JRE even when "bundle jre for this environment" is unchecked | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Ralf Ebert <ralf> | ||||||||||
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> | ||||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | alexis.drogoul, c.keimel, curtis.windatt.public, d.n.gonzales21, difu.wang, gary, hjg.com.ar, irbull, karasiuk, malcolm_smith, shashwat.work, sunny.tang, tjaensch, tomkanka, walther, zulliger | ||||||||||
| Version: | 3.6 | Keywords: | helpwanted | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 178953 [details]
com.example.mail.zip
Example plug-in project for reproducing
Same problem here. (In reply to comment #2) > Same problem here. Problem in 3.7 still present. Also the selection of the JRE content (JDK vs. plain JRE) does not take the actual configuration into account. (In reply to comment #3) > (In reply to comment #2) > > Same problem here. > > Problem in 3.7 still present. Also the selection of the JRE content (JDK vs. > plain JRE) does not take the actual configuration into account. The problem persists in 3.7.1. And the same exact JRE (the one of the target platform) is copied in the different directories when building for multiple platforms. *** Bug 347195 has been marked as a duplicate of this bug. *** I found that I was still getting a JRE bundled after unchecking the "bundle jre..." checkbox, and even after removing the execution environment, if I had previously checked the "bundle jre.." checkbox. I needed to remove the JRE from my product to prevent it going in my p2 repository due to the existing issue with p2 trying to update its own JRE on windows. Even creating a new product configuration did not resolve the issue. I eventually found that I could get the JRE out of the generated product by deleting the contents of the .metadata\.plugins\org.eclipse.pde.core folder from my workspace. Seems like it is caching stuff there that doesn't get tided up once the option is unchecked. (In reply to comment #6) > I eventually found that I could get the JRE out of the generated product by > deleting the contents of the .metadata\.plugins\org.eclipse.pde.core folder > from my workspace. Seems like it is caching stuff there that doesn't get tided > up once the option is unchecked. The workaround does not work for me. In fact I have deleted the whole plugins folder under metadata and it still adds the JAVA_HOME version of Java to my RCP product. (In reply to comment #7) > (In reply to comment #6) > > > I eventually found that I could get the JRE out of the generated product by > > deleting the contents of the .metadata\.plugins\org.eclipse.pde.core folder > > from my workspace. Seems like it is caching stuff there that doesn't get tided > > up once the option is unchecked. > > The workaround does not work for me. In fact I have deleted the whole plugins > folder under metadata and it still adds the JAVA_HOME version of Java to my RCP > product. Hello, i encountered the same problem but found a solution (http://www.eclipse.org/forums/index.php/mv/msg/162865/515229/#msg_515229) working for me since i do not need the metadata repository. In short: Delete <vm/> content in the product file before exporting. Hope that works for you. removing the rcp part is not one I can do as it then does not include the launchers required. Also I have a beta product that I need to update which already has the jre bundled within the binaries folder, so removing the JRE out of the repository would not be enough as I would also have the issue that the update will still fail. This is because the product to be updated contains the JRE and it attempts to uninstall it. Hi, Deleting the <vm/> content by directly editing the product file actually worked for me as well as a workaround. However, I'm wondering what it can break elsewhere… Hope this nasty bug will be fixed soon (I'm fed up of manually trashing useless JREs from my exported products). Cheers Alexis (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > > I eventually found that I could get the JRE out of the generated product by > > > deleting the contents of the .metadata\.plugins\org.eclipse.pde.core folder > > > from my workspace. Seems like it is caching stuff there that doesn't get tided > > > up once the option is unchecked. > > > > The workaround does not work for me. In fact I have deleted the whole plugins > > folder under metadata and it still adds the JAVA_HOME version of Java to my RCP > > product. > > Hello, > i encountered the same problem but found a solution > (http://www.eclipse.org/forums/index.php/mv/msg/162865/515229/#msg_515229) > working for me since i do not need the metadata repository. In short: Delete > <vm/> content in the product file before exporting. Hope that works for you. *** Bug 372772 has been marked as a duplicate of this bug. *** Actualy: The JRE which is associated with the Execution Environment is copied into the exported product. It seems as though the attribute include (<windows include=false">) from the product definition is not evaluated correctly. Is this bug only on windows or also on other platforms? Created attachment 223251 [details]
1-checkbox.patch
Created attachment 223252 [details]
2-clearcache.patch
Created attachment 223254 [details]
2-qualifier.patch
There are two problems here. 1. The “include” attribute from the product definition, corresponding to the “Bundle JRE for this environment with the product” checkbox, is not evaluated in the build process. This can be fixed using the attached 1-checkbox.patch. It is actually part of Andrew Niefer’s patch for bug 307269, but for some reason was never applied. 2. When the intermediate org.eclipse.pde.container.feature_root.win32.win32.x86 IU, containing the launcher executable and possibly the JRE, is unpacked to apply branding (ant task eclipse.brand.p2.artifact), it is not always “downloaded” freshly from the place where it was built (correctly including or excluding the JRE as specified in the current build), but an outdated cached copy of it may be used that includes or excludes the JRE as specified in some earlier build. Malcolm in comment 6 was on the right track here – for me, when I’m running Eclipse standalone, that download cache is in p2/org.eclipse.equinox.p2.core/cache in the Eclipse install directory though, not in the workspace. When I’m running Eclipse in the debugger of another Eclipse instance, using a launch configuration named “Publisher Eclipse Application”, the download cache is in .metadata/.plugins/org.eclipse.pde.core/Publisher Eclipse Application/.p2/org.eclipse.equinox.p2.core/cache in the workspace of the debugger Eclipse. (This also explains my earlier infuriating experience that it would behave differently when run in the debugger than when run standalone, even when both were pointed at the same workspace.) This cache hit occurs because the container feature always has the same version number, 1.0.0. I can think of two ways of solving that: A. Clear the download cache before unpacking. This is implemented in the attached 2-clearcache.patch. It adds a bundle dependency from org.eclipse.pde.build on org.eclipse.equinox.p2.touchpoint.natives and uses a class from an “internal” package there, I’m unsure if that is permissible. I also have a version that does not do that, but duplicates some information (location of the cache) from there, which is probably worse. B. Vary the version number by including a “qualifier”. This is implemented in 2-qualifier.patch. It has the disadvantage that when exporting many times, the download cache is filled up with many, possibly big (if they include the JRE), and essentially identical files. I have no idea if there is any kind of size limit or garbage collection on the cache to take care of that. I’m hoping someone who is more familiar with PDE than I can review these and decide which is better, or if there is a different, even better solution. I don't have much time to put towards this, but I will take a look in M4. I tweaked the changes from checkbox patch and pushed the fix to master: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=bb7ffb8c9afc2ca6a02be93d7055f6ad4d0a3a93 The proposed change to PDE Build to clear the cache seems reasonable, but I hesitate to alter the p2 branding task which I know nothing about. For now I am moving this bug to the PDE Build bucket. Later during the release once the PDE commit rights are collapsed, we can try changing this and see if any side effects are noticed. Thanks! Good point about the added null check. (I don’t know offhand if jreInfo can be null, but as a first approximation I can assume that the existing null check on vm = … was there for a reason.) Finally had some time to look at this. Neither solution is satisfactory. The PDE Build change of clearing the cache applies anytime the branding task is run. It may not be the case that the artifact was just built, so deleting the cache will hurt performance. Adding a dependency on touchpoint.natives isn't very good either as it expands the set of bundles needed to run the ant task. If the bundle was already in the dependency tree that would be ok (and we could request to be x-friended), but it is independent. I tried out the qualifier patch which is much better scoped. However, as expected, the cache just continues to grow. I'm not sure what to try next. cc'ing Ian in case he has any suggestions from the p2 side. Perhaps there is some limit to the cache, in which case adding a qualifier makes the most sense as the feature's content is changing. Otherwise is there a way to turn off the caching? The problem is still here with Kepler 4.3.1. Removing <vm/> from the product configuration does not work as well. For anyone who is persistently stuck with this issue, the following steps should resolve: * If present, delete the entire <vm>...</vm> section from the source of your .product file and save. * Close Eclipse * Delete contents of <WorkspaceLocation>\.metadata\.plugins\org.eclipse.pde.core * Delete folder <EclipseInstallLocation>\p2\org.eclipse.equinox.p2.core\cache Having moved to a new machine and finding this issue resurfacing these steps worked for me. Product builds no longer contain a bundled JRE. Mass change for PDE Build bugs tagged with "helpwanted". PDE build is not actively enhanced, hence I close these bugs as wontfix. Please reopen if you want to contribute a patch. |
Reproduced on Windows 7: - Used Eclipse Build 3.6.0 (I20100608-0911) or 3.6.1 (M20100909-0800), fresh workspace - Created a new RCP app plug-in using the mail template - Create a new product file in the plug-in using the existing product - Configure an execution environment, but leave "bundle jre for this environment" unchecked. This is persisted in the product file as: <vm> <windows include="false">org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6</windows> </vm> - Exported the product using Export > Eclipse product (with or without generate metadata repository) - Export folder contained bundled 'jre'