Community
Participate
Eclipse IDE
When I tried to install the Eclipse 3.0 M7 examples (eclipse-examples- 3.0M7.zip) which I download from http://fullmoon.torolab.ibm.com/downloads/drops/S-3.0M7-200402122000/eclipse- examples-3.0M7.zip, the examples were installed, but they were not loaded to the workbench. Here are the steps to follow in order to regenerate this scenario 1. Install Eclipse 3.0 M7 on Solaris 9 or HP-UX 11.11 2. Download example archive eclipse-examples-3.0M7.zip from http://fullmoon.torolab.ibm.com/downloads/drops/S-3.0M7-200402122000/eclipse- examples-3.0M7.zip 3. Install the examples by following the instructions given in the download page. They are as follows: “To install the examples, first make sure you have exited your Eclipse program. Then download the zip file containing the examples and extract the contents of the zip file to the same directory you used for your SDK installation. For example, if you installed the Eclipse Project SDK on d:\eclipse-sdk then extract the contents of the examples zip file to d:\eclipse-sdk. Start Eclipse. The example plug-ins will be installed.” 4. Launch Eclipse. Expected Behavior: The examples are detected, installed and loaded to the workbench. By selecting 'Window > Show View > Other > SWT Examples' from the workbench menu option, each individual example can be launched. Actual Behavior: The examples are detected and installed, but never loaded to the workbench. Therefore, the SWT Example category is not available in the “Show View” window. Important: After browsing the Eclipse newsgroups, I found the fix for this bug in the following news article http://dev.eclipse.org/newslists/news.eclipse.platform/msg13244.html The fix given in this article is as follows: “Go to Help > SoftwareUpdates >Manage Configuration and launch the Configuration Dialog. Turn on disabled features filtering and then enable the examples feature.”
On Linux and Windows one can detect changes in a directory (new file added, file removed, etc.) by checking the timestamp on the directory itself. It appears that on Solaris and HP this assumption is incorrect. Could you confirm that if: - D is a directory - a new file N is added to the directory D, the timestamp on D is unchanged - a file R removed from D does not affect the timestamp on D either ? If that's the case, is there a quick way to detect directory changes (file added/removed) without having to process all the directory contents? Thanks
I have performed the following steps on both Solaris 7 and 8 and HP-UX 11.11. I used ls -lia to verify dates. Created a directory. Timestamp is time and date of creation. Created a new file in that directory. Timestamp changes on the directory to the new time when the file was created. Removed the file. Timestamp on the directory changed again to the time that the file was removed. Maybe the date format on Solaris and HP-UX is different than what it is on Linux and Windows.
Thanks! The date format should not matter, we are using the java.util.Date class and call getTime() to obtain the time in milliseconds and then do comparisons. I will try performing the suggested steps on Windows and see if that leads to a problem. For now, I wanted to rule out any timestamp issues that could be OS specific.
We have made some significant changes to the eclipse startup and they will be available in tomorrow's integration build. I tested the problem on Windows using nightly build 0222, and things seem to work. Have you encountered the same problem with M7 on Windows? Please pick up tomorrows integration build and give it a try, the problem may have been solved already.
I did experience the same problem with Eclipse 3.0M7 on Windows 2000. The integration build I20040224 can not be run on Windows 2000, Solaris 9 and HP-UX 11.11, so I could not check whether this problem exists in that build. If it helps, the following was the log entry (content of .log file) that I found after the Eclipse I20040224 workbench was crashed. !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Feb 24, 2004 10:45:05.967 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.Error: Unresolved compilation problems: The import org.eclipse.ui.commands.CommandHandlerServiceFactory cannot be resolved The import org.eclipse.ui.commands.IMutableCommandHandlerService cannot be resolved The import org.eclipse.ui.commands.IWorkbenchWindowCommandSupport cannot be resolved The import org.eclipse.ui.contexts.IWorkbenchWindowContextSupport cannot be resolved The import org.eclipse.ui.internal.commands.ws.WorkbenchWindowCommandSupport cannot be resolved The import org.eclipse.ui.internal.contexts.ws.WorkbenchWindowContextSupport cannot be resolved IWorkbenchWindowCommandSupport cannot be resolved (or is not a valid type) for the field WorkbenchWindow.workbenchWindowCommandSupport IWorkbenchWindowContextSupport cannot be resolved (or is not a valid type) for the field WorkbenchWindow.workbenchWindowContextSupport workbenchWindowCommandSupport cannot be resolved WorkbenchWindowCommandSupport cannot be resolved or is not a type workbenchWindowContextSupport cannot be resolved WorkbenchWindowContextSupport cannot be resolved or is not a type WorkbenchWindowCommandSupport cannot be resolved or is not a type workbenchWindowCommandSupport cannot be resolved actionSetAndGlobalActionCommandHandlerService cannot be resolved IMutableCommandHandlerService cannot be resolved (or is not a valid type) for the field WorkbenchWindow.actionSetAndGlobalActionCommandHandlerService CommandHandlerServiceFactory cannot be resolved actionSetAndGlobalActionCommandHandlerService cannot be resolved IWorkbenchWindowContextSupport cannot be resolved (or is not a valid return type) for the method getContextSupport workbenchWindowContextSupport cannot be resolved IWorkbenchWindowCommandSupport cannot be resolved (or is not a valid return type) for the method getCommandSupport workbenchWindowCommandSupport cannot be resolved IWorkbenchWindowCommandSupport cannot be resolved or is not a type The method getCommandSupport() is undefined for the type WorkbenchWindow IWorkbenchWindowContextSupport cannot be resolved or is not a type The method getContextSupport() is undefined for the type WorkbenchWindow at org.eclipse.ui.internal.WorkbenchWindow.<init> (WorkbenchWindow.java:209) at org.eclipse.ui.internal.Workbench.newWorkbenchWindow (Workbench.java:1149) at org.eclipse.ui.internal.Workbench.openFirstTimeWindow (Workbench.java:1196) at org.eclipse.ui.internal.Workbench.init(Workbench.java:912) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1520) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:263) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:47) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:256) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:100) 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.basicRun(Main.java:279) at org.eclipse.core.launcher.Main.run(Main.java:742) at org.eclipse.core.launcher.Main.main(Main.java:581)
Sudarsha, the integration (re)build is available now. Could you please give it a try when you have a chance? Thanks!
Created attachment 8180 [details] A screenshot of the Product Configuration dialog
When I installed Eclipse examples eclipse-examples-I20040225.zip on Eclipse Integration Build I20040225 on Solaris 9 and HP-UX 11i as requested, I realized that the examples were installed and loaded to the workbench once the Eclipse was restarted. This is the expected behavior, therefore it is successful. However, according to the product Configuration dialog (can be launched by selecting “Help -> Software Updates -> Manage Configuration” from the main menu) the “Eclipse SDK Examples 3.0.0” was still disabled even though they were loaded to the workbench and could be launched by selecting 'Window > Show View > Other > SWT Examples' from the workbench menu. My guess is the Product Configuration dialog was not updated to reflect the recent changes. A screenshot of the Product Configuration dialog is attached as product_configuration.jpg.
We'll leave the bug open to investigate why the example features appear disabled.
Fixed in the latest integration build 0303. BTW, you should also be able to install the examples using the update manager (and no restart would even be needed). Right now the update site is experimental only, but it should be available at some point.
The defect that I mentioned in Additional Comment # 8 still exists in Eclipse 3.0M9 Build (Build id: 200405211200) on Solaris 9.0 and HP-UX 11i platforms. This time I installed the Eclipse Examples by simply extracting the example zip archive into the same folder that I used for the SDK installation and started the workbench. I could see the examples were installed and loaded even though the Product Configuration Dialog (can be launched by selecting “Help -> Software Updates -> Manage Configuration” from the main menu) stated that the Eclipse SDK Examples were not (i.e. examples are disabled).
Have you tried this on other OS'es ? Was only Solaris and HP that failed? I don't have access to Solaris and HP, so could you please check the timestamp on the eclipse/features, eclipse/plugins, eclipse/feature/<the_example_feature> and eclipse/plugins/<the_example_plugin> directories? Also, can you attach the content of eclipse/configuration/org.eclipse.update folder here? Thanks!
Created attachment 11141 [details] Content of eclipse/configuration/org.eclipse.update directory
I didn’t try this scenario on other OSes other than Solaris 9 and HP-UX 11i. So, I am going to test it on Windows 2k now. I’ll let you know how it goes. In the meantime, here are the timestamps that you requested. eclipse/features: May 26 11:03 eclipse/plugins: May 26 11:03 eclipse/feature/<the_example_feature>: May 21 12:54 eclipse/plugins/<the_example_plugin>: May 21 12:54 I also attached the content of eclipse/configuration/org.eclipse.update directory to this defect. Note that I have enabled the example feature from Product Configuration Dialog before the content of eclipse/configuration/org.eclipse.update directory was extracted.
I tested it on Windows 2000 platform. This defect was not reproducible. I guess the example installation failure only happens on Solaris and HP-UX platforms. Do you want me to test this on Linux as well?
Thanks! Here what I think it happens: When you unzip the examples, the timestamp of the eclipse/features and eclipse/plugins directory changes (and it should). This triggers the update configurator to reconcile the configuration with what has been unzipped. The configurator checks the timestamp on each feature directory, looking for one that is newer than the old configuration. However, the unzip has not correctly created the timestamps, likely because it preserves those from the orginal zip file. As such, the feature does not appear in the platform.xml file (it only appears after you enable it). With plugins, the story is a bit different: for performance reasons, the update policy (check platform.xml) is USER-EXCLUDE, which is empty, so all the plugins from that site are picked up, including the newly unzipped plugins (even though they have an older timestamp). BTW, if you have a chance, please test on Linux as well, so at least we have a more comlete picture of where things fail.
Created attachment 11161 [details] Content of eclipse/configuration/org.eclipse.update directory on Linux
I experienced the same problem when I tried to install the Eclipse examples on Red Hat Enterprise Linux 3.0. Note that there are two different example zip archives available on the Eclipse Download Page. One of them is for the Windows family and the other is for the rest of the supported platforms. May be the Windows version of the example zip archive does not cause this problem, but the other one does. That may be why this issue is not reproducible on Windows platforms. Here are the timestamps that you requested. eclipse/features: May 26 12:20 eclipse/plugins: May 26 12:20 eclipse/feature/<the_example_feature>: May 21 12:30 eclipse/plugins/<the_example_plugin>: May 21 12:54 I also attached the content of eclipse/configuration/org.eclipse.update directory to this defect (see org.eclipse.update_RHLinuxEnt3.0.zip file). Let me know if you need further assistance.
Thanks for help! I think the problem is clear, the timestamp from inside the zip is carried over on the plugins directories.
Installing features should be done via the update standalone commands or via the update ui. Anything that is manually downloaded is tolerated (plugins are picked up), but not fully integrated. The user must manually enable those features in the configuration manager. The fact that it works on Windows, is a side-effect that benefits those users. I will close this bug as wontfix.
