Bugzilla – Full Text Bug Listing
| Summary: | Project import (New Projects Wizard) doesn't work for arbitrary project types | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Benjamin Muskalla <b.muskalla> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, alvarofernandogarcia, angvoz.dev, daniel_megert, eclipse, eclipse, hansfn, hauser, langdominik, mappukut, markus.kell.r, martin.oneachtain, matthias.sohn, mistria, pavel, pelham789, raffi.khatchadourian, rharrison, robin, s.maratea, thomasproeger, tomasz.zarna |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Benjamin Muskalla
I have this same problem importing a project from EGit on Windows. Steps: - Cloned repository - File > Import... - Select Projects from Git - Select existing cloned repository - Select "Use the New Projects Wizard" - Click "Finish" (only button available to continue) - Select "Java Project" - Enter project name, click "Finish" - Project is created, but no files are imported (project is empty) One difference I have with the original bug is that if I import the project as a general project and select a sub dir of the repository, then the files are imported. According to the documentation on the EGit website, the EGit import wizard should start back up to finish the import after the New Project Wizard finishes, however this is not happening. I have the similar problem on my Linux Debian Squeeze box. I want to import a C++ project from a github repository. Cloning the project works fine but if I try to import the code into a new C++ project I end up with an empty C++ project in my workspace. Steps: * Clone a repository without an eclipse project file * Import source with "Use New Project Wizard" * Configure a C++ project ==> result: an empty C++ project. Importing the source with "Import as General Project" and "Import Existing Project" works fine. Here, a new "General Project" will be created, all source files imported and the Team Provider will be connected to the original repository. I'm using: EGit Version 0.11.3 JGit Version 0.11.3 Update Site: http://download.eclipse.org/egit/updates Eclipse Version: Helios Service Release 1 / Build id: 20100917-0705 Same problem as last 2 posters, namely that when 'new project wizard' is used an empty project is the result. In my case, I select php project with the same result. If I select general project then the project is correctly set up with files and repo intact. egit 1.0.0.201106090707-r jgit 1.0.0.201106090707-r eclipse 3.6.1. As a workaround you can import as a general project. Then you can convert to a java project by following this tutorial. Everything as normal then. http://www.mularien.com/blog/2007/12/05/quick-tip-convert-an-eclipse-general-project-to-a-java-project/ I have also noticed this same behavior for the eclipse packages shipping with Fedora 15. Having this ability would be a boon to the CraftBukkit - a Minecraft server mod - plugin developer community. Many developers do not use Maven and publish raw Eclipse sources on GitHub without .project or other support files. The inability of Eclipse users to import such as a Java project requires us to import files cause a disjoint between the project and a Git repository or manually tweaking a General Project's files to add the Java nature. Bluntly speaking, if creating a Java project is offered as an option - the feature also being described in accompanying and third-party documentation - then it should be implemented or stricken as an option. That said, I can imagine that there may be other higher priority issues that currently prevent this issue from being addressed, but at least do others the favor and remove the option, rather than teasing them and making them pound their head against a wall wondering what they're doing wrong until they discover that it is a bug :) Judging from the origin date of this bug report, this feature has been an open issue for over a year and should either be fixed or killed. I have same problem.
Steps for reproduce (in brackets my data for example):
1. Go to Window -> Open perspective -> Other -> Git Repository Exploring;
2. Click "Clone repository";
3. Fill "Source Git Repository" form (ssh://gitolite@localhost:2222/demo);
4. Do the Branch selection (master);
5. Select Local Destination (/home/sgr/workspace-git/demo);
--- Repository clonned into local destination
~/workspace-git/demo$ tree
.
├── demo
│ ├── src
│ │ └── demo.py
│ └── test.txt
└── .git
├── branches
...
6. Right click on project -> Import Projects;
7. Select "Use The New Project Wizard" -> Finish;
8. Select Project Wizard (PyDev Project) -> Next;
9. Enter project Name (demo) and other parameters -> Finish;
--- Project created without files from repository.
~/workspace$ tree
.
└── demo
On OS Windows7 x64 on the same Eclipse and EGit versions project importing works fine.
Eclipse version: 4.3.0;
Egit version: 3.0.0.201306101
OS: Debian GNU\Linux 7.1
Java: Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) Client VM (build 23.6-b04, mixed mode)
*** Bug 412450 has been marked as a duplicate of this bug. *** I don't see what EGit could do to improve this, as we're limited to what the Eclipse platform provides here. When the user selects "Use The New Project Wizard", we currently run NewProjectAction of Platform UI. This starts a new project wizard as if the user selected File > New > Project... But there's no way for us to tell it that the new project should be located in the working directory of the Git repository. @Dani/Markus: Is there a possibility of extending the platform to be able to implement this? (In reply to comment #9) > I don't see what EGit could do to improve this, as we're limited to what the > Eclipse platform provides here. > > When the user selects "Use The New Project Wizard", we currently run > NewProjectAction of Platform UI. This starts a new project wizard as if the > user selected File > New > Project... But there's no way for us to tell it > that the new project should be located in the working directory of the Git > repository. > > @Dani/Markus: Is there a possibility of extending the platform to be able to > implement this? This should be doable, see CVS Checkout As for an example. Another related problem is bug 367832. (In reply to comment #10) > This should be doable, see CVS Checkout As for an example. See https://bugs.eclipse.org/bugs/attachment.cgi?id=234147 *** Bug 367833 has been marked as a duplicate of this bug. *** (In reply to comment #11) > (In reply to comment #10) > > This should be doable, see CVS Checkout As for an example. > > See https://bugs.eclipse.org/bugs/attachment.cgi?id=234147 Thanks for the hint. So it uses the following (IMO a bit hacky) solution to get the created project, see CheckoutAsWizard#getNewProject: http://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/bundles/org.eclipse.team.cvs.ui/src/org/eclipse/team/internal/ccvs/ui/wizards/CheckoutAsWizard.java?id=f743d2de7592e078b2fd7b49dc80a884c6106536#n293 After that, it checks out the sources from CVS into the created project. In EGit, the order is reversed, we first clone the repository to the desired location, then import projects. But maybe a solution would be to move the new project to the correct location after the new project wizard is finished? A quick try of moving a newly-created Java project (with an empty "src" folder) to an existing location with Refactor > Move resulted in "Resource already exists on disk". But maybe the UI does more checks than IProject#move or the check can be disabled. Dani, what's your opinion about this approach? Another user with the same problem: http://stackoverflow.com/questions/18879825/fetch-local-git-project-not-configured-for-eclipse-with-egit Using IProject#move as described in my last comment does not seem to be a solution that works as it assumes that the target directory is empty. I'm now wondering whether an even more hackish solution would work: Removing the created project from the workspace, then moving the .project file to the desired location and then importing that into the workspace. I really think we need help from the platform on this one. The cleanest way would be for the new project wizard to be able to get the desired location as input and then it would create the project there directly. *** Bug 318386 has been marked as a duplicate of this bug. *** Maybe I miss something here (I admit I didn't read all the comments) but from a brief look I can see at least two workarounds for the issue: 1) when on the last page of the Import Git project wizard i.e. the one titled ~"Select a wizard to import projects" pick the last option "Import as general project" 2) if on that page you decided to go with the "Use new Project Wizard" option, when the wizard opens and you're on the page for entering project name, don't forget to change project location (from default to the one you saw in the previous wizard os the local destiation directory for the repo being cloned) The above worked for me for a non-java repository, which didn't have a .project file. As the result I got a new project in my workspace, with the repo content and a .project file as a new, untracked change. In other words, unless I got it wrong, the issue occurs only when the user decides to use the new project wizard and the default location. Is that correct? I'm trying to understand this more deeply, to figure out if I can help and what's need to be done. (In reply to Tomasz Zarna from comment #16) > Maybe I miss something here (I admit I didn't read all the comments) but > from a brief look I can see at least two workarounds for the issue: > > 1) when on the last page of the Import Git project wizard i.e. the one > titled ~"Select a wizard to import projects" pick the last option "Import as > general project" Yes. The problem with that is that it's not always possible to convert a general project to a X project (including adding all the necessary builders, etc). E.g. try creating a new general project and then later converting it to a Java project. Good luck ;). (I guess this is one of the little things that other IDEs do better than Eclipse (not that that is hard).) > 2) if on that page you decided to go with the "Use new Project Wizard" > option, when the wizard opens and you're on the page for entering project > name, don't forget to change project location (from default to the one you > saw in the previous wizard os the local destiation directory for the repo > being cloned) > > The above worked for me for a non-java repository, which didn't have a > .project file. As the result I got a new project in my workspace, with the > repo content and a .project file as a new, untracked change. That works, but it's not obvious that the location has to be changed in the wizard. It would be nice if we could pre-fill that location. > In other words, unless I got it wrong, the issue occurs only when the user > decides to use the new project wizard and the default location. Is that > correct? I'm trying to understand this more deeply, to figure out if I can > help and what's need to be done. Correct. The hard part is implementing this in a non-hacky way, see comment 14 for some ideas. (In reply to Robin Stocker from comment #14) > I really think we need help from the platform on this one. The cleanest way > would be for the new project wizard to be able to get the desired location > as input and then it would create the project there directly. +1 I guess we'd "just" need a new interface "ILocalFilesystemImportWizard extends IImportWizard" for import wizard which would add setLocation/getLocation methods, and to adapt most existing wizard to use those methods when initializing. Then EGit could call the "setLocation" method on the import wizard before actually showing it. EGit could even only show wizards that would implement this ILocalFilesystemImportWizard since other ones may not be relevant and easy to use in the context of an import from EGit. @Robin: WDYT? Did you open a bug against platform to request that? Another approach to import, that has been discussed on some bugs for Platform UI but that is probably too intrusive to be changed soon, would be to have import being a "compound" operation: first it would create the generic project, and then it would allow specific wizard to configure it, using the Resource API so those configuration wizards would be more "universal" than the one we have now which needs to take care of both original location (filesystem, SCM, network, zip...), and expected project natures. But I guess it's better to discuss this on the platform-ui-dev mailing-list. (In reply to Mickael Istria from comment #18) > (In reply to Robin Stocker from comment #14) > > I really think we need help from the platform on this one. The cleanest way > > would be for the new project wizard to be able to get the desired location > > as input and then it would create the project there directly. > > +1 > I guess we'd "just" need a new interface "ILocalFilesystemImportWizard > extends IImportWizard" for import wizard which would add > setLocation/getLocation methods, and to adapt most existing wizard to use > those methods when initializing. > Then EGit could call the "setLocation" method on the import wizard before > actually showing it. EGit could even only show wizards that would implement > this ILocalFilesystemImportWizard since other ones may not be relevant and > easy to use in the context of an import from EGit. > @Robin: WDYT? Did you open a bug against platform to request that? Do "new project" wizards implement IImportWizard or INewWizard? I guess that the idea could work, yes. Looks like NewWizard would also need a new method. > Another approach to import, that has been discussed on some bugs for > Platform UI but that is probably too intrusive to be changed soon, would be > to have import being a "compound" operation: first it would create the > generic project, and then it would allow specific wizard to configure it, > using the Resource API so those configuration wizards would be more > "universal" than the one we have now which needs to take care of both > original location (filesystem, SCM, network, zip...), and expected project > natures. > But I guess it's better to discuss this on the platform-ui-dev mailing-list. Yes, something like that would be nice. I can sort of work around this by first creating my project directory in my workspace and then importing the git repository into that directory. Since yesterday we have an experimental integration of the clone wizard with the auto-import framework which is incubating in e4. This new feature was implemented by Mickael and is available from the nightly build repository http://download.eclipse.org/egit/updates-nightly https://git.eclipse.org/r/#/c/43988/ If you installed it you can invoke it from the menu "Import... > Git > Projects from Git (auto-import)" import using the new smart import works nicely: - clone repository - Import... - Git > Projects from Git (with smart import) - Next - Existing local repository - choose repository - Next - the smart import wizard will auto-detect project nature etc - Finish to create a new project of the auto-detected project nature *** Bug 497152 has been marked as a duplicate of this bug. *** In EGit 4.8 (Oxygen.0) it is not possible for me to use the "Use New project wizard" option without that the following error pops up (maybe because the project directory is not the Working Tree directory): "Error connecting project Foo, no Git repositories found" (I tried "General > Project" and "Java > Java Project" with an empty Git repository and with a Git repository that contains files and folders.) See also https://stackoverflow.com/q/36191347/6505250 *** Bug 519140 has been marked as a duplicate of this bug. *** |