Bugzilla – Full Text Bug Listing
| Summary: | [Import/Export] Import Project by drag and drop | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ed Willink <ed> | ||||
| Component: | IDE | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P5 | CC: | daniel_megert, ed, jtan, Lars.Vogel | ||||
| Version: | 3.1 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Ed Willink
I've just upgraded from 3.2M5a to M6 and my workspace broke, so I have to import all my projects by hand again. This is still a mjor pain. Is there no way to define a project set? (I just tried to export on M5 and it only offered those projects that had a CVS delta.) I also tried to grab .metadata files, but they have bundleIds in which are unstable between workspaces. What import wizard are you using? Import > Existing projects into workspace and pointing to the directory of the workspace will list all the projects in that workspace. You can select all of them and import in one action. It seemed much better for a while, offering the sub-tree as you say, but as of ? M5a if I choose the root directory, it proceeds to create a preoject there rather than offering me its children. In Package Explorewr I do, Import...General/Existing Projects into workspace, Select Root Directory. Can you give a more detailed description of the steps you are doing and what is happening - into which workspace directory is the project being created, is only one project being created when you have multiple projects selected? Note there is also an option to copy the project into the workspace which, instead of just being a pointer to the project in the directory you selected, will copy the project into the workspace you are importing into. I need to know if you are using that option or not. In detail.... I had a Workspace that I had successfully used and upgraded between 3.2M3,4,5a. I extend Eclipse with EMF, EMFT, GEF, VE, NiceXSL, ATL, each in a separate update site to avoid polluting a specific Eclipse with a particular add-in. In upgrading to 3.2M6, I wanted to avoid having to traverse 6 paths from the Desktop to register each add-in (see Bug 86590). I therefore tried a manual edit of configuration\org.eclipse.update\platform.xml to copy the UM config from 3.2M5a. Since feature now have four part names I deleted the <feature> elements, retaining just the <site> elements, hoping that the features would be auto-read from the sites. Sadly my Workspace ended up broken, I presume because the above was foolish. For reference, broken is !ENTRY org.eclipse.osgi 4 0 2006-04-07 14:25:20.187 !MESSAGE An error occurred while automatically activating bundle org.eclipse.core.resources (22). !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.start() of bundle org.eclipse.core.resources. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1013) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:969) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.preFindLocalClass(EclipseLazyStarter.java:86) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:402) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:338) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:387) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:351) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:546) at java.util.ArrayList.get(ArrayList.java:321) at org.eclipse.core.internal.properties.PropertyBucket.readEntryValue(PropertyBucket.java:267) at org.eclipse.core.internal.localstore.Bucket.load(Bucket.java:299) at org.eclipse.core.internal.properties.PropertyBucket.load(PropertyBucket.java:252) at org.eclipse.core.internal.localstore.Bucket.load(Bucket.java:266) at org.eclipse.core.internal.localstore.BucketTree.loadBucketFor(BucketTree.java:114) at org.eclipse.core.internal.properties.PropertyManager2.getProperty(PropertyManager2.java:132) at org.eclipse.core.internal.resources.Resource.getPersistentProperty(Resource.java:999) at org.eclipse.core.internal.resources.ContentDescriptionManager.getCacheState(ContentDescriptionManager.java:275) at org.eclipse.core.internal.resources.ContentDescriptionManager.startup(ContentDescriptionManager.java:463) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:1893) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1653) at org.eclipse.core.resources.ResourcesPlugin.startup(ResourcesPlugin.java:367) at org.eclipse.core.internal.compatibility.PluginActivator.start(PluginActivator.java:31) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:994) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:988) ... 27 more Root exception: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:546) and the Workspace remains broken despite cleaning out configuration and restarting. So as is too often required, a new Eclipse means a new Workspace. To populate the new Workspace, with the (external) projects of the old Workspace, I just do Import... General->Existing Projects into workspace enter the parent folder of my projects as Select Root Directory, I see a single ticked folder. Since I am importing projects I obviously do not select copy. The problem is that the single folder is not recognised as the parent project. Ah! I've cracked it. On 14 Feb an accident put a .project in that folder so it appears to be a project. So the bug is now. a) the search for .project files does not traverse below folders with a .project in. b) the display of folders with .project files does not display their hierarchical structure. e.g. if I have firstTry/Temp and secondTry/Temp, I cannot tell which Temp is which. In response to:
a)
So basically your directory setup is something like:
workspaceRootFolder
someFolder with a .project file in it
subFolders of someFolder with .project files in them
How does this happen? If you remove the higher level .project file is the problem fixed?
b)
Since you aren't allowed to have 2 projects with the same name in one workspace (Temp is the name of the project, correct?), I don't understand how b) can ever be an issue. Has your workspace directory been manipulated by outside of Eclipse's mechanisms for updating/modifying the workspace? I guess I don't understand how the 6 paths you mentioned appear in your file system.
a) Got it. A repro...
With .project in ..../root/proj1, .../root/proj2 etc, try to create proj3 in .../root/proj3.
Package Exporer:New->Project...:Plug-in Project,Next
proj3
not default location, .../root
result is proj3 at .../root/.project, not .../root/proj3.project
("/" is also allowed as the location!)
This is consistent behaviour, but at least confusing since what is 'location'?
In earlier versions of Eclipse 3.0, 3.1 ... up to perhaps 3.2M3ish it never seemed possible to create such sibling projects. I always had to specify
.../root/proj3 to avoid the "overlapping projects" error and then use Explorer
to move .../root/proj3/proj3 to .../root/proj3 before re-importing the project.
That bug has now been cleared, leaving me with a bad habit that caused the wrong but undiagnosed entry.
Perhaps it is sufficient to change the wording to "Use default project location", to make it quite clear that what is pre-loaded with a Workspace
path is actually the incomplete project path.
[New->Project... invoked on .../root/proj1, should offer .../root as the
pre-filled in not-default location, shouldn't it?]
b) You can easily have multiple projects with the same name.
Create Temp in different workspaces. e.g Workspace and runtime-workspace,
then import a project from one to the other. It works, but can be very
bad news in terms of Java build consistency since one Workspace builds and
the other doesn't refresh and so you get very confusing class mismatches.
That seems really stupid doesn't it, but it isn't.
Consider an X.Examples plug-in for a Tool X under development. X.Examples
and X.Tool plug-ins exist in the main Workspace. In order to use the development
version of X you must run up a runtime Workspace. To manipulate the examples with X you import X.Examples into that workspace!
a) I must be misinterpreting your steps - I tried them and got the overlapping workspace location error. 1. Run target workspace located at d:\root 2. Create Proj1 and Proj2 in default location 3. Create Proj3, check not at default location, select d:\root This is the only way I could interpret your steps to replicate. Can you clarify? b) How are you importing the second Temp project into the workspace? You cannot import 2 projects with the same name by using the Import Existing Projects into Workspace wizard. *** Bug 135889 has been marked as a duplicate of this bug. *** (In reply to comment #8) > b) > How are you importing the second Temp project into the workspace? You cannot > import 2 projects with the same name by using the Import Existing Projects into > Workspace wizard. I guess the point here is that the wizard should provide user some path info so that user can pick the project that he indeed wants. Here is a scenario why it's useful: I have a folder called "source" which contains some sub-folders and each sub-folder has a bunch of projects serving me for different purpose. Some projects' name are same among the subfolders. Now I want to import some projects from different subfolders all in once, so I select the folder "source" as root directory, then I see many projects with the same name and without path info. As a workaround, I guess I need to select subfolder instead of "source" folder, but it conflicts the purpose of multiple seletion. Just my 2 cents... and an img is attached. Created attachment 39551 [details]
screen shot of import wizard
James, I can't open the screenshot you attached. I need a repeatable test case before I can address this bug. What James described is very much in line with my experience. I hope he can fix the screen shot for you. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag. |