Community
Participate
Eclipse IDE
I used to be able to copy the windows fragments into a linux install (or the other way around) to make a shared platform install multi-platform ready.. If I do this now I get the following error: 1116263293346.log :::::::::::::: !SESSION Mon May 16 12:08:13 CDT 2005 ------------------------------------------ !ENTRY org.eclipse.core.launcher 4 0 2005-05-16 12:08:13.398 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.RuntimeException: Could not find framework at org.eclipse.core.launcher.Main.getBootPath(Main.java:639) at org.eclipse.core.launcher.Main.basicRun(Main.java:268) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) This worked fine in 3.1M6 (well in 3.0 as well) and I thought things like this would be considered API and not changed between M6 and M7..
and what about bugs being introduced? :-) Did you lay M7 over M6? Could you give steps on how to reproduce?
Sorry, I was just freaking out I have more problems upgrading from M6 to M7 than I have from 3.0 to 3.1M6. :) I had to revert it for now due to deadlines; I'll get you a better analysis of what is happening though when I pick it back up in a few days. But no, its a clean M7 install but with our own feature as the main feature. I strip out the platform specific fragments from other platform downloads and put them all in there (well just win32 and linux gtk at this point that we support). I notice thought there are things in configuration/ that didn't use to be there or at least wasn't absolutely needed in M6; even some gtk specific .so files it looks like. Maybe that has something todo with it?
I redid this and figured out it was my config.ini that somehow seemed to have ruined this. We didn't change the config.ini between 3.0 and 3.1M6 and it worked fine. However moving to M7 the 3.0 config.ini did no longer work. I got a different error on my second attempt which helped out (can't find application something or another). Anyways, I'm closing this as invalid. Not sure if anyone will be worried about config.ini that worked in M6 (but was probably wrong) doesn't work in M7. I'm not too worried at least.
This issue has reemerged in RC2 (was not present in RC0 or RC1) and seems now easily reproduceable (but also simpler to get around). If I install win32 plug-ins and binaries together with another platform (like linux), this worked fine in pre-RC2, but now it fails to start the first time and gives this error in the configuration directory: mmoeller@mmoeller:~/Dev/TeamWorks/TeamWorks/KeplerSM/teamworks> more ../deploy/ae-eclipse/configuration/1118942188362.log !SESSION 2005-06-16 12:16:28.33 ------------------------------------------------ eclipse.buildId=unknown java.version=1.4.2_08 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -name TeamWorks Authoring Environment Command-line arguments: -os win32 -ws win32 -arch x86 -name TeamWorks Authoring Environment -consoleLog -clean !ENTRY org.eclipse.core.runtime 2005-06-16 12:16:57.298 !MESSAGE Product teamworks.ae could not be found. !ENTRY org.eclipse.osgi 2005-06-16 12:16:57.360 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: No application id has been found. at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:204) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) !ENTRY org.eclipse.osgi 2005-06-16 12:16:57.423 !MESSAGE Bundle update@plugins/org.eclipse.core.resources.linux_3.1.0.jar [41] was not resolved. !ENTRY org.eclipse.osgi 2005-06-16 12:16:57.470 !MESSAGE Bundle update@plugins/org.eclipse.update.core.linux_3.1.0.jar [43] was not resolved. !ENTRY org.eclipse.osgi 2005-06-16 12:16:57.501 !MESSAGE Bundle update@plugins/org.eclipse.swt.gtk.linux.x86_3.1.0.jar [48] was not resolved. ---------------- This however only happens the first time I switch between the platforms. If I run first on Linux, then on Windows, the first time I run it on Windows it fails with the above problem. The next time if I stay on windows it works fine again (until I switch to Linux which it will fail once again). I'm reopening but lowering my severity. It is annoying and it was supported before (maybe not supposed to be supported however :)).
It is strange that it stopped working. Rafael, can you see if there are any obvious changes that went in to cause this? Having said that, switching back and forth has not really been a scenario that is high on the list. Most people want to have a shared install of all the different plugins but then run one configuration for Windows, another for linux gtk, etc. For any given configuration they do not switch on a per run basis.
Note that "used to work" and "supported" are different things. As Jeff mentioned, the main scenario we want to support requires you to use separate configuration areas for every OS. So if you cleaned the configuration area (keeping only the config.ini file), and marked the install as read-only, this would force the configuration area to be stored under a OS-specific location, so there would be no risk of collision. Explicitly specifying distinct locations for the configuration area should work as well. For instance: ./eclipse -configuration linux-configuration eclipse.exe -configuration windows-configuration As per the problem you are seeing now, the symptoms seem to indicate that we are not discarding the cached state of bundle resolution when the platform changes. During shutdown, we somehow save the correct settings, and next time we restart theproblem does not happen. I will investigate.
Morten, only now I noticed you started the failing session with -clean. That makes failing even more strange. Do you always run with -clean?
Morten, could you try the following: 1) once it is running fine on one platform, switch the other platform and run for the first time with (in addition to any options you are already using): -console -consolelog -noExit 2) As soon as it fails, you should be left at the "osgi>" prompt. Eclipse will not exit. Now type: ss Please attach the full output since Eclipse was started to this PR. Thanks.
osgi console is a neat tool :) anyways this is the logs. And yes I always always run with -clean. I understand if this wont be fixed for 3.1. It is an annoyance to me its not a production issue for our customers. I can add that the "eclipse.product" listed in config.ini (and that is what the exception complains about) is not located in the normal plugins directory. its in an extension directory which is located inside the platform install and our links/teamworks.product file contains this: ----------------- mmoeller@mmoeller:~/Dev/TeamWorks/TeamWorks/KeplerSM/deploy/ae-eclipse> more links/teamworks.product path=teamworks ----------------- So could it be some cache that translates the path from 'teamworks/' into an absolute path on the platform which causes it to fail on another OS? I have no idea how this actually works so I'm just making wild guesses here ;) And from the exception that sounds fair. That would also be an issue if people used the install on a shared drive and they used a different share drive-letter for different machines however I'm guessing. In any case, this is the console log output with the 'ss' command: ----------------- !ENTRY org.eclipse.osgi 2005-06-17 10:42:58.116 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: No application id has been found. at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformAct ivator.java:204) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) !ENTRY org.eclipse.osgi 2005-06-17 10:42:58.194 !MESSAGE Bundle update@plugins/org.eclipse.core.resources.linux_3.1.0.jar [41] w as not resolved. !ENTRY org.eclipse.osgi 2005-06-17 10:42:58.241 !MESSAGE Bundle update@plugins/org.eclipse.update.core.linux_3.1.0.jar [43] was not resolved. !ENTRY org.eclipse.osgi 2005-06-17 10:42:58.288 !MESSAGE Bundle update@plugins/org.eclipse.swt.gtk.linux.x86_3.1.0.jar [48] was not resolved. ss Framework is launched. id State Bundle 0 ACTIVE system.bundle_3.1.0 1 ACTIVE org.eclipse.core.runtime_3.1.0 2 ACTIVE org.eclipse.update.configurator_3.1.0 3 RESOLVED org.eclipse.tomcat_4.1.30.1 4 RESOLVED org.eclipse.jface.text_3.1.0 5 RESOLVED org.eclipse.draw2d_3.1.0 7 RESOLVED org.eclipse.help.appserver_3.1.0 8 RESOLVED org.eclipse.core.filebuffers_3.1.0 9 RESOLVED org.eclipse.ui.editors_3.1.0 10 RESOLVED org.eclipse.jface_3.1.0 11 RESOLVED org.eclipse.ui.workbench.texteditor_3.1.0 12 RESOLVED org.eclipse.ui_3.1.0 13 RESOLVED org.eclipse.ui.forms_3.1.0 14 RESOLVED org.eclipse.ui.cheatsheets_3.1.0 15 RESOLVED org.eclipse.update.core_3.1.0 Fragments=55 16 RESOLVED org.eclipse.gef_3.1.0 17 RESOLVED org.eclipse.platform_3.1.0 18 RESOLVED org.eclipse.osgi.util_3.1.0 19 RESOLVED org.eclipse.core.boot_3.1.0 20 RESOLVED org.eclipse.swt.win32.win32.x86_3.1.0 Master=46 21 RESOLVED org.eclipse.ui.ide_3.1.0 Fragments=56 23 RESOLVED org.eclipse.update.scheduler_3.1.0 24 RESOLVED org.eclipse.help_3.1.0 25 RESOLVED org.eclipse.ui.views_3.1.0 26 RESOLVED org.eclipse.ui.browser_3.1.0 27 RESOLVED org.eclipse.help.ui_3.1.0 28 RESOLVED org.eclipse.search_3.1.0 30 RESOLVED org.eclipse.ui.console_3.1.0 31 RESOLVED org.eclipse.core.resources.compatibility_3.1.0 Master=36 32 RESOLVED org.eclipse.ui.workbench_3.1.0 Fragments=54 33 RESOLVED org.eclipse.ui.intro_3.1.0 34 RESOLVED org.eclipse.ui.presentations.r21_3.1.0 35 RESOLVED org.eclipse.platform.doc.user_3.1.0 36 RESOLVED org.eclipse.core.resources_3.1.0 Fragments=31, 53 37 RESOLVED org.eclipse.compare_3.1.0 38 RESOLVED org.eclipse.core.variables_3.1.0 39 RESOLVED org.eclipse.update.ui_3.1.0 40 RESOLVED org.eclipse.core.expressions_3.1.0 41 INSTALLED org.eclipse.core.resources.linux_3.1.0 42 RESOLVED org.eclipse.help.webapp_3.1.0 43 INSTALLED org.eclipse.update.core.linux_3.1.0 44 RESOLVED org.apache.lucene_1.4.3 45 RESOLVED org.eclipse.core.commands_3.1.0 46 RESOLVED org.eclipse.swt_3.1.0 Fragments=20 47 RESOLVED org.eclipse.core.runtime.compatibility_3.1.0 48 INSTALLED org.eclipse.swt.gtk.linux.x86_3.1.0 49 RESOLVED org.eclipse.osgi.services_3.1.0 50 RESOLVED org.eclipse.text_3.1.0 51 RESOLVED org.eclipse.help.base_3.1.0 52 RESOLVED org.eclipse.rcp_3.1.0 53 RESOLVED org.eclipse.core.resources.win32_3.1.0 Master=36 54 RESOLVED org.eclipse.ui.workbench.compatibility_3.1.0 Master=32 55 RESOLVED org.eclipse.update.core.win32_3.1.0 Master=15 56 RESOLVED org.eclipse.ui.win32_3.1.0 Master=21
The path you specify in the link file is relative to the Eclipse install or to your current directory?
eclipse install.. The folder "teamworks" (which contains the extension) is in the same folder as the "plugins", "configuration", "features" etc. But 50-60% of the time, eclipse install directory == current directory. But the product link seems to work off the eclipse install because sometimes I do things like start eclipse using "../deploy/ae-eclipse/eclipse" from linux and that works fine as well.
I tested this a little more. It is not only a Linux -> Windows issue, it is a change folder issue. Scenario: 1. I have Eclipse on a shared drive, I map this drive to T: and run my application for the first time. It works fine. 2. Another user (or myself) mount the same share to drive Y: and run Eclipse. Now I see that exact exception I saw on Linux -> Windows (cannot find application). 3. I run it one more time from Y: and now it works (and it will do so every consecutive time I run it from Y:). So a simple grep found the actual cause of this: ./org.eclipse.update/platform.xml:<site url="file:teamworks/eclipse/" enabled="true" updateable="true" linkfile="y:/KeplerSM/deploy/ae-eclipse/links/teamworks.product" policy="USER-EXCLUDE"> linkfile is set to an absolute path (although I thought the links directory always had to be <eclipse-install>/links. I could revert to RC1 and see what happens there, but I'm guessing it just keeps it relative or tries to refind the path if it cannot find it from the link? I always run with -clean, so that doesn't help on this either.
And actually, from the xml it seems like it is not an issue because I have a relative path in my link file (that path is kept as file:teamworks/eclipse/), it is the path to the link file itself that is turned into an absolute path. So any change to the folder (change drive, move folder etc) of an eclipse install that uses extensions will fail I would think.
Re: comment 11 - relative paths in the links files are resolved having the *current* directory as reference (not the install directory). This is not API, but it is how it has been since a long time ago. I tested it myself, and later found bug 35037 which is exactly about a request to make them install relative instead. The problem in your scenario is caused by recent work in storing site URLs relative to the install URL. Now we always store them as relative URLs. Before, even sites whose URL where specified as relative by the user would be immediately transformed to absolute and saved that way. If locations changed, during the next startup the existing configured site would be discarded right away (the site location does not exist). But now we store them as relative, so when we read them back, they seem to exist fine. The issue is that we do not store the link file location relative as well (bug 98335). So after reading the already configured directories, we process the links directory and ignore what we find there because the same site has already been configured. The next step is what kills us: in PlatformConfiguration.validateSites(), any sites whose linked file locations do not exist are discarded. There are two possible fixes for this one: either bug 98335 is fixed (ideal solution, but more risky) or in the ConfigurationParser, we discard configured sites if their link file location does not exist as well (for a matter of consistency I think we should anyway). Dorian, Dejan: do you want to even look at a patch?
Created attachment 23633 [details] patch for org.eclipse.update.configurator Here it is anyway. It does what I mentioned before. The validation done while parsing the configured sites applies the same rules as the validation done by PlatformConfiguration.validateSites().
Note that due to the way Update deals with user specified relative URLs and relative URLs coming from the persisted platform.xml this will only happen for the case the external location path is specified as relative to a directory under the install. Two workarounds are possible: - to have the relative external location outside the eclipse directory - to specify an equivalent path such as: ../eclipse/myproduct instead of just myproduct.
"this will only happen for the case the external location path is specified as relative to a directory under the install" should read: "this will only happen for the case the relative external location path is a directory under the install" The two workarounds described above apply.
Given the worksarounds from comment 16, can we just readme this?
After reading all the comments, I am at loss as to what exactly is that we need to put in the readme :-) (please forgive me, it has been a long release :- ).
I was thinking that we would just include the info from comment 16. Perhaps Rafael can help nail down some wording etc?
Maybe too late, but here is the suggested blurb: Extension location is lost if the install path changes A previously configured extension location may be temporarily removed if the install is moved or mounted under a different path. This only happens when the link file that configures the extension location uses a relative path that points to a directory under the Eclipse install. On a second startup using the same install path, the extension location is added again (bug 95403).
Just now noticed this was not in the update inbox. Dejan, please take a look at the suggested note for the readme. Whether it should be released or not is up to you. Note that even if the note released, this PR should still be fixed (after 3.1).
Sent a note to SOnia for 3.1 readme. Leaving the defect as open for post-3.1.
This is a mass update of Platform Update bugs that have had no activity in three years. Platform Update was replaced in Eclipse 3.4 (2008) by a new provisioning system called Equinox p2. If this bug or enhancement is not already addressed in p2 please enter a new bug report against p2 (RT > Equinox > p2). If you still want to see this bug addressed in the deprecated Platform Update component, please reopen this bug. Patches welcome.
