Bugzilla – Full Text Bug Listing
| Summary: | [Import/Export] Import existing projects does not search subdirectories of found projects | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Axel Mueller <aegges> | ||||||
| Component: | IDE | Assignee: | John Arthorne <john.arthorne> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P5 | CC: | acc_eclipse, bugs, cbeams, cs01lg, daniel_megert, dev, eclipse, eclipse, john.arthorne, mark.melvin, matt, michael.isvy, nogudnik, pwebster, szczepiq, walter.brunauer | ||||||
| Version: | 3.2 | Keywords: | helpwanted | ||||||
| Target Milestone: | 4.3 M1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 244315 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Do you have a .project file in the "TOP" Directory? The import tool will scan recursively, but will not scan into directories that contain a .project file. Yes, there is a project file in the TOP directory. Is it possible to "convince" Eclipse to scan directories that contain a .project file? As of Eclipse 3.2 I can create projects in subdirectories of another project (Import CVS module and choose non-default location). This behaviour was added intentionally because scanning the entire project tree takes a long time (see bug 84713). I don't know the right answer here. Scanning below projects seems unnecessary in the common case. However, now that we do support nested project content directories, it seems a valid request. Maybe the wizard should have a "search for nested projects" checkbox option. That would be very useful!
>> Maybe the wizard should have a "search for nested projects" checkbox option.
We didn't do it initially as it is pretty easy to get a conflict between the top project and the nested one. *** Bug 152479 has been marked as a duplicate of this bug. *** (In reply to comment #5) > We didn't do it initially as it is pretty easy to get a conflict between the > top project and the nested one. Can't you show a hierarchical structure that would make it more clear to users. Import wizard can also check that selected projects don't have conflicting overlap and raise proper error/warning. Will this enhancement be included in the upcoming 3.3? It would be very helpful in convincing my colleagues to use Eclipse. (In reply to comment #5) > We didn't do it initially as it is pretty easy to get a conflict between the > top project and the nested one. Then why do you allow to create projects physically nested inside projects? IMO you either have to fully support nested projects in the resource model (including import functionality, see bug #172870), or prohibit to generate them at all (like in the old days, where it was not allowed to create another project in any file system branch already containing one). my 2 cents, Walter Axel: this wont be making it into 3.3. Sorry. > Axel: this wont be making it into 3.3. Sorry.
That's a pity. I just installed the latest RC of version 3.3 . In order to get a clean workspace I had to manually import every single project that is located below another project (there are a lot in our source tree and you have to know where they are located as Eclipse does not show them!).
If I suggest this routine to one of my colleagues they will say that Eclipse is crap and they will just keep their Visual Studio.
Any update on this issue? It seems to me that the best suggestion so far is to allow an optional 'search for nested projects' checkbox in the Import->Existing Projects dialog. Thanks. All Gradle users are waiting eagerly for this feature. Gradle (gradle.org) is a very popular build framework; multi-project builds in Gradle are nearly always nested. Most of the gradle builds are multi-project. Gradle supports Eclipse in multiple ways, for example one can generate metadata files - .project, .classpath for all the projects. However it is painful to import those projects because dev has to do it per each nesting. 10+ branches are not uncommon. Another problem is that it's not clear for many developers that he needs to run the import wizard again per each subproject. We've had reports from devs who didn't grasp why 'subprojects are not visible in the import wizard' and got discouraged from using eclipse (competing IDE products don't have that issue :) Sometimes it is necessary to reimport projects again and click through the wizard again. Another thing (not that related but I figured I'll share) devs reported is that if the wizard needs to be used 10+ times devs make mistakes in working set allocation. In the result the project setup gets messed up and they start over again. Pardon me for the complaining tone of this comment. I wanted to share more use cases that warrant completion this feature. Eclipse is a great tool and I'd like to thank you very much hard work involved in providing it for us! Cheers :) We are not looking at this area at this time. But patches are welcome. http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW That's not only useful for Gradle but also for Maven multi-module projects. It would be great to have this checkbox! *** Bug 378059 has been marked as a duplicate of this bug. *** I'd also like to see this feature - the terrible codebase we've got has a bunch of nested projects and they all need to be in the workspace for dependencies to work. For some reason, I am able to import a set of projects if I select a folder which is 3 levels on top of them. Don't ask me why :). So on my computer, I have: /home/user/work/projects/parentProject/childProject1 (and I have a set of other child projects next to childProject1). If I point the Eclipse wizard to "/home/user/work/", it does propose to load all the projects in one click. But if I point to "/home/user/work/projects/", it only proposes to load the parentProject. That's really weird behavior. I'm using Eclipse 4.2. Cheers, Michael. Does anyone have any thoughts on whether a "Search for nested projects" checkbox should be checked or not checked if the "Select archive file" radio button is selected rather than "Select root directory"? Also, would users expect the list of projects to be refreshed (the search to be triggered) whenever the "Search for nested projects" checkbox is checked/unchecked? I'm leaning toward "yes." 1)I believe you can search for nested projects in an archive file as well. So people should be able to decide whether or not they want to search for nested projects inside the archive file. I would say that selecting the radiobutton "search for archive file" should not have any impact on the checkbox (people are still free to check or uncheck it). 2) Yes, I think we can expect the list to be refreshed when the list is checked/unchecked. Thanks for the input Michael. I'm working on implementing the new option, and it's going well. It looks like the dialog already includes nested projects when importing from an archive file (in Indigo SR2 at least). Given that, do we still think the new option should be available when imported from an archive file, or should it be disabled and always enabled? I'm going to attach the ZIP I'm testing with, which contains the following structure: foo foo/.classpath foo/.project foo/bin foo/src foo/bar foo/bar/.classpath foo/bar/.project foo/bar/bin foo/bar/src foo/bar/goo foo/bar/goo/.classpath foo/bar/goo/.project foo/bar/goo/bin foo/bar/goo/src So there's three projects; foo, bar (nested in foo), and goo (nested in bar). If searching for nested projects is not enabled, only foo should show up in the list. Otherwise, foo, bar and goo should show up. Created attachment 215633 [details]
Nested project structure
(In reply to comment #24) > It looks like the dialog already includes nested projects when importing from > an archive file (in Indigo SR2 at least). > > Given that, do we still think the new option should be available when imported > from an archive file, or should it be disabled and always enabled? > > I'm going to attach the ZIP I'm testing with, which contains the following > structure: > > foo > foo/.classpath > foo/.project > foo/bin > foo/src > > foo/bar > foo/bar/.classpath > foo/bar/.project > foo/bar/bin > foo/bar/src > > foo/bar/goo > foo/bar/goo/.classpath > foo/bar/goo/.project > foo/bar/goo/bin > foo/bar/goo/src > > So there's three projects; foo, bar (nested in foo), and goo (nested in bar). > If searching for nested projects is not enabled, only foo should show up in the > list. Otherwise, foo, bar and goo should show up. Let me clarify one sentence: When importing from an archive file, do we still think the new option should be available or should it be disabled and automatically checked? Personally, I think when importing an archive file the new "search for nested projects" checkbox should be automatically checked and disabled. I don't see a disadvantage to that behavior, since searching for nested projects in an archive file is highly unlikely to perform poorly. Hi Matt, I just tried with an archive of 10 MB with 20 projects inside, and it took less than one second to scan them all (and my hard drive is not an SSD one!). It's indeed much faster than working with a folder, I'm impressed. So I would say that it's acceptable to disable that checkbox. Thanx for working on that issue! I'm sure the Maven and Gradle communities will be very grateful :). (In reply to comment #28) > Hi Matt, > I just tried with an archive of 10 MB with 20 projects inside, and it took less > than one second to scan them all (and my hard drive is not an SSD one!). It's > indeed much faster than working with a folder, I'm impressed. > > So I would say that it's acceptable to disable that checkbox. Ok, sounds good. > Thanx for working on that issue! I'm sure the Maven and Gradle communities will > be very grateful :). No problem; just scratching an itch! Here's an additional question: in your experience, are projects often nested multiple times, such as the example structure I've attached where goo is nested in bar which is nested in foo? Or is just a single level of nesting more common/sufficient? Well, that's not very common, but I've seen that before. It's great if we can support that as well. (In reply to comment #30) > Well, that's not very common, but I've seen that before. It's great if we can > support that as well. Shouldn't be an issue. I believe I have fully implemented the enhancement, but there's a caveat. When importing nested projects from the filesystem, the "Refreshing workspace" job experiences an IllegalArgumentException if it attempts to refresh a nested project before refreshing the project it is nested in. It seems to refresh the projects by project name in alphabetical order. For example, if I import the following structure the error occurs:
b/.project
b/.classpath
b/a/.project
b/a/.classpath
After the import, Eclipse tries to "refresh" project "a" before refreshing project "b", and the IllegalArgumentException is thrown with message "Element not found: /b/a." This leaves "a" in a error state "Project 'a' is missing required source folder: 'src'". If I then manually refresh "b", the error on "a" disappears and all is well with the world.
If, on the other hand, "b" is nested in "a", the projects are refreshed in the same order as before ("a", then "b"), but no IllegalArgumentException is thrown and both projects are without error. So it seems important that nested projects be loaded/refreshed after the project(s) they are nested within.
It isn't clear to me whether this should be considered an issue with the import dialog or if it should instead be considered an issue with the "Refreshing workspace" job. I'm leaning toward the latter.
Here are the full event details for the error:
eclipse.buildId=M20120208-0800
java.version=1.6.0_21
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
Error
Tue May 15 11:11:24 EDT 2012
An internal error occurred during: "Refreshing workspace".
java.lang.IllegalArgumentException: Element not found: /b/a.
at org.eclipse.core.internal.watson.ElementTree.elementNotFound(ElementTree.java:256)
at org.eclipse.core.internal.watson.ElementTree.createElement(ElementTree.java:184)
at org.eclipse.core.internal.resources.Workspace.createResource(Workspace.java:1369)
at org.eclipse.core.internal.resources.Workspace.createResource(Workspace.java:1322)
at org.eclipse.core.internal.localstore.RefreshLocalVisitor.createResource(RefreshLocalVisitor.java:80)
at org.eclipse.core.internal.localstore.RefreshLocalAliasVisitor.createResource(RefreshLocalAliasVisitor.java:38)
at org.eclipse.core.internal.localstore.RefreshLocalVisitor.synchronizeExistence(RefreshLocalVisitor.java:219)
at org.eclipse.core.internal.localstore.RefreshLocalVisitor.visit(RefreshLocalVisitor.java:293)
at org.eclipse.core.internal.localstore.UnifiedTree.accept(UnifiedTree.java:110)
at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.java:920)
at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:904)
at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1663)
at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Created attachment 215656 [details]
Import Projects screen capture showing new "Search for nested projects" checkbox
I've attached a screen capture of the dialog showing the new checkbox.
Matt, can you attach your current changes to support this, or give a pointer to your git repo if you have a reachable clone. I would like to take a look at the exception in the refresh job. (In reply to comment #34) > Matt, can you attach your current changes to support this, or give a pointer to > your git repo if you have a reachable clone. I would like to take a look at the > exception in the refresh job. John: no problem, I forked the repo on github: https://github.com/mhurne/eclipse.platform.ui The branch you'll want is bug-144610. It was based on the R3_7_maintenance branch. (In reply to comment #35) > (In reply to comment #34) > > Matt, can you attach your current changes to support this, or give a pointer to > > your git repo if you have a reachable clone. I would like to take a look at the > > exception in the refresh job. > > John: no problem, I forked the repo on github: > https://github.com/mhurne/eclipse.platform.ui > > The branch you'll want is bug-144610. It was based on the R3_7_maintenance > branch. John, have you had any success reproducing the issue I described? Let me know if there's anything I can do to help. Thanks! The exception during refreshLocal is a real bug in platform resources. It is covered by bug 244315. (In reply to comment #38) > The exception during refreshLocal is a real bug in platform resources. It is > covered by bug 244315. Thanks! I have added a test for importing nested projects in the following commit: https://github.com/mhurne/eclipse.platform.ui/commit/f4020c8bde38ab6a5763a46a76157b26f278eaf1 Thanks for all your work on this Matt! (In reply to comment #41) > Thanks for all your work on this Matt! No problem, John. Is there any more action I need to take to contribute the code? Thanks. Actually.. yes, one administrative detail. Can you make a statement on this bug that you (a) wrote 100% of the code; (b) have the right to contribute the code to Eclipse. This is part of our code provenance checks [1] [1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf I personally authored 100% of the code in the following changesets, and I have the right to contribute the code to Eclipse: https://github.com/mhurne/eclipse.platform.ui/commit/2032fe19fa0c7d66c22599458fbfaef3936d6b64 https://github.com/mhurne/eclipse.platform.ui/commit/f4020c8bde38ab6a5763a46a76157b26f278eaf1 I see that the target milestone is 4.3; I made my changes on R3_7_maintenance. Do you need me to apply them to a different branch? Well, if you rebase on master that would be ideal. But on the other hand there has been little change in that area so I expect we could cherry-pick it either way. (In reply to comment #46) > Well, if you rebase on master that would be ideal. But on the other hand there > has been little change in that area so I expect we could cherry-pick it either > way. OK, I've rebased the changes onto master. The previously linked to commits no longer exist. Now you want: https://github.com/mhurne/eclipse.platform.ui/commit/b63a12f3192300736b4c2006e0dcceed7acfc981 https://github.com/mhurne/eclipse.platform.ui/commit/3b2cc261be8450c9d6e00993a702ea62daf26e39 If you'd like me to create a pull request on github, let me know! Where do we stand on this? Are there any specific plans to incorporate my changes for a particular release? Thanks! (In reply to comment #48) > Where do we stand on this? Are there any specific plans to incorporate my > changes for a particular release? Thanks! We want to pick them up early in Eclipse 4.3 (Kepler). Work on that will start soon after we ship at the end of June. PW (In reply to comment #49) > (In reply to comment #48) > > Where do we stand on this? Are there any specific plans to incorporate my > > changes for a particular release? Thanks! > > We want to pick them up early in Eclipse 4.3 (Kepler). Work on that will start > soon after we ship at the end of June. > > PW Thanks for the update, Paul. I have cherry-picked Matt's two commits, verified, tested, and pushed to master: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2e5c525b33b6b9514af5b4c198b663b0c65724a1 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d2cd930a1e782fd81b73bc55a2c7799a92a02caf (In reply to comment #51) > I have cherry-picked Matt's two commits, verified, tested, and pushed to > master: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2e5c525b33b6b9514af5b4c198b663b0c65724a1 > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d2cd930a1e782fd81b73bc55a2c7799a92a02caf Excellent, thanks! Note that this P5 enhancement went into 4.2.1. (In reply to comment #53) > Note that this P5 enhancement went into 4.2.1. This is really a new feature which should also get more testing (e.g. a quick test shows a missing mnemonic) and hence I'd prefer to put this into 4.3/Kepler only. - Reverted the two commits in the 'R4_2_maintenance' branch - Added the missing mnemonic in 'master' and fixed the copyright date Verified in I20120917-2000 and verified that it is not in SR1 RC4. (In reply to comment #55) > Verified in I20120917-2000 and verified that it is not in SR1 RC4. Actually, on a second test, and re-read of this bug, the current solution is a bit confusing. Why should I be able to to choose searching nested projects when importing from a folder but not when importing from an archive? Filed bug 389878 to track that. *** Bug 283368 has been marked as a duplicate of this bug. *** |
I would like to import several existing projects via Import->Existing Projects into Workspace. Unfortunately, only projects that are in the root directory itself or in the immediate subfolder below are imported. My source structure is as follows: TOP/ src1/ prj1 prj2 src2/ prj3 If I select TOP as the root directory the Import Wizard does not show any projects. I have to use the Import Wizard for every subfolder (here, src1 and src2).