Community
Participate
Working Groups
Since Neon egit uses the smart import wizard. This has a very worse effect on importing from a repository, where the projects are not direct children of the git working directory. E.g. if you have the common directory layout gitroot\plugins\project_a gitroot\plugins\project_b gitroot\tests\project_c gitroot\tests\project_d gitroot\releng\project_e then the smart import wizard either shows * an empty list of projects for the gitroot (if "search nested" is off) * some hundred projects (if "search nested is on"), since it now includes all the runtime test projects contained as resources in project_c and project_d. So with the above directory layout, an end user now only has the choice of either selecting each project sub directory in the working tree one by one for importing, or to show all nested children (including test runtime projects) and to manually choose the actual projects from the list. I'm not sure if this is caused by how egit uses the smart import wizard or if the smart import wizard really doesn't make any difference between * recursing into sub folders of a normal (non project) folder * recursing into sub folders of an Eclipse project. In the latter case you may want to move this issue to the correct platform project.
This is not an Egit issue, but a Platform one. Did you try hacking around the filter and select all/deselect all buttons? (In reply to Michael Keppler from comment #0) > I'm not sure if this is caused by how egit uses the smart import wizard or > if the smart import wizard really doesn't make any difference between > * recursing into sub folders of a normal (non project) folder > * recursing into sub folders of an Eclipse project. Many projects have .project files at mutliple level, we need to recurse in those, and cannot make a difference with recursing into other regular folder.
This is a major bug that kills workflows that worked perfectly fine before EGit started to use the "smart" importer. Comment 0 was already pretty clear, but I'll try again with steps: - Clone git://git.eclipse.org/gitroot/platform/eclipse.platform.team.git - Try to import existing top-level projects from .../eclipse.platform.team/bundles/ I.e. only existing projects that are defined in that folder. Don't create a useless project for .../bundles. Don't create projects for .../bundles/org.eclipse.core.net/fragments/... => You fail. The workaround is to use "File > Import... > Existing Projects into Workspace", manually set the root directory, disable the "Search for nested projects" Good that Dani blocked off bug 500117 (but bad that he actually had to).
> Don't create a useless project for .../bundles. Useless is subjective here. For m2e to work, every folder of the hierarchy with a pom.xml must be available. > Don't create projects for .../bundles/org.eclipse.core.net/fragments/... Whatever gets a .project gets detected. As several projects also use the convention to have .project in intermediary layers (such as bundles/) to ease Maven import (when this same intermediary folder uses a pom.xml), there is no way to figure out what case the user is in. The wizard had to take a default decision that is the best for most users, and it seemed like importing all folders with a .project is preferred. I don't think that the average project suffers from this issue. This issue is specific to your habits and expectations regarding imports, but soome other users actually prefer the current behavior...
(In reply to Mickael Istria from comment #3) > The wizard had to take a default decision that is the best for most users, > and it seemed like importing all folders with a .project is preferred. To me this seems a bad choice. You want to replace the old wizard by the new one. But at the same time you ignore an existing use case and propose a new use case as important. That will not work, since there are a lot of projects out there with hundreds of test data projects contained in sub folders of their test bundles, and these can only choose between zero and several hundreds of bundles to be imported. (Anecdotally, the new import wizard is _the_ single feature of Neon, where people ask for switching back to Mars in our company) > I don't think that the average project suffers from this issue. Every project with test data projects in test bundles has this issue. See above. I want to repeat my initial suggestion, which would easily fix both use cases, as far as I understood them: * If a directory has a .project file, then search in sub folders only if the "Nested" checkbox is checked. * If a directory has no .project file, then search in all sub folders. For the Maven use case, select the checkbox. For the previous Eclipse behavior ignoring test data projects in test bundles, don't select the checkbox.
> You want to replace the old wizard by the new one. I never said I want that ;) The goal of the import wizard is to be more helpful and simpler in most cases than digging to the Import... wizard and picking the right wizard. People who have a more specialized wizard which works better for them can and should still be allowed to use this specialized wizard. Maybe EGit should offer a way to revert to the previous page of the wizard https://wiki.eclipse.org/images/1/19/Egit-0.11-import-projects-select-wizard.png from the Smart Import one? I can investigate this. > That will not work, since there are a lot of projects out there with hundreds of test data projects contained in sub folders of their test bundles, and these can only choose between zero and several hundreds of bundles to be imported. I see that the "Deselect All" does deselect all proposals, even if filters are used. Would it be better for your use-case if the deselect all would deselect only the proposals that are still visible under the filter. (to be honest, I expected it to work that way, and the fact that it deselects all is more like a bug to me) Then one could use a filter and then deselect all to more easily deselect a subset of the tree. I will fix this. > * If a directory has a .project file, then search in sub folders only if the "Nested" checkbox is checked. Unfortunately, at the moment, the Smart Import wizard doesn't offer that level of control. Actually, the wizard is mostly agnostic from the .project: a .project isn't much more meaningful to it than a pom. However, there is a mechanism in place in the interface to easily allow to "remove directory" proposal. In the case of PDE projects, then this method could be implemented to remove test resources.
(In reply to Mickael Istria from comment #5) > Maybe EGit should offer a way to revert to the previous page of the wizard > https://wiki.eclipse.org/images/1/19/Egit-0.11-import-projects-select-wizard. > png from the Smart Import one? > I can investigate this. Actually, this shouldn't be in EGit but in Platform. I'll come back to you soon with a code proposal.
New Gerrit change created: https://git.eclipse.org/r/86161
@Lars: Another use case for those improvements (and for easier navigation to specialized import wizards) is the some projects such as BuildShip do contribute a specialized wizard and not an integration with the Smart Import. This link, although not the best workflow one can imagine, is currently a relatively cheap, nice and efficient way to handle trickier import stories. Hence I believe that despite not being ideal, the proposed patch is valuable.
(In reply to Mickael Istria from comment #8) > @Lars: Another use case for those improvements (and for easier navigation to > specialized import wizards) is the some projects such as BuildShip do > contribute a specialized wizard and not an integration with the Smart > Import. This link, although not the best workflow one can imagine, is > currently a relatively cheap, nice and efficient way to handle trickier > import stories. > Hence I believe that despite not being ideal, the proposed patch is valuable. I missed that you are not hard-coding a link to the old wizard but offering an option to start any import wizard. Great idea.
Gerrit change https://git.eclipse.org/r/86161 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=240e8f400f2eabfb36575299811c79b8050fcd62
I believe that this is a perfect example of the limitation of such a generic "smart" import wizard. It's designed to handle the most common cases as good as possible, but there are often cases for which it's too limited (here it's about deciding whether nested projects are to be included or not - about whether there's a hierarchy of .project files we want to import as m2e tends to encourage, about about whether those aren't desired since they are test or example resources). I think the patch that allows to easily redirect selection to specialized import wizards is a decent solution for the user-story: if one finds the wizard doesn't work for them, they can very easily switch back to another one. So users don't feel stuck with an unpleasant proposal and are proposed alternatives. Marking it as fixed then.
