I tried to rename my top level folder which contains multiple java projects. I also wanted to create a new workspace to point everything to the right location. My current workspace has all the right projects in it, but when I go to import the copied projects into my new workspace, they don't show up. I checked each projects .classpath and .project files and they seem to be the same. I thought as long as they have a .classpath and .project eclipse should recognize them and be able to import them but they don't show up. I looked in the workspace files but don't see anything there that seems of value. What other files do my projects need to be picked up by Eclipse? I'm not even sure how I got them into my current workspace to begin with.
Related
Just by a mistake I had deleted a spring project in STS.To use it back I borrowed the same project from my friend in zip format but when I tried to import it says
Some projects cannot be imported because they already exist in the workspace
Following is the way I tried to import
file->import->general->existing projects into worspace->select archive file
and after browse when I select the zip project
Some projects cannot be imported because they already exist in the workspace
and the finish button and next button are in disabled state.Please help me
The workspace in STS/Eclipse is not automatically the same as the file structure that you have on disc in your workspace directory. You can have projects in this workspace folder or somewhere else on disc.
To get them into your project explorer (and access them from inside STS/Eclipse), you need to import them (Import Existing Projects into Workspace). Then you can select the folder where those projects are located in. In case you have those projects already in your workspace folder on disc, you can choose the workspace folder as root folder in the wizard. It will show all the projects that exist on disc in that folder and grey those out that are already imported/referenced in your workspace in Eclipse.
Make sure it is really not in workspace, also if there aren't any other projects with the same name. If not, just delete the .metadata folder or create a new workspace.
Check if you still have the project in folder of the workspace on disk. You may have deleted in STS, without checking 'Delete on disk'. So, the project may be still there in the workspace folder though its deleted in STS.
I get this issue from time to time. Usually I just open a new workspace but sounds like you don't want to loose other projects.
I simply open the.project file in my project and change the name of the project in name tag.
Good Luck!
Probably whey you 'accidentally deleted' your project, you only deleted it from the Eclipse workspace, but not from the actual workspace folder on your hard-drive (as other people pointed out, Eclipse can arbitrarily map workspace projects to files on disk, so it is possible for a project to be 'deleted' from your Eclipse workspace but still exist on disk.
The good news is the files you deleted are actually still there.
Instead of importing your project from a zip, you may just want to import those files from the workspace folder back into your Eclipse workspace.
Generally this kind of problems not occurred you can go to Project option and clean and than restart STS.
May be STS is not synched with the latest configured project.
When you launch Spring Tools Suite, it will ask you to Select directory as workspace as below:
If the directory you selected here (i.e., workspace directory) is the same as the directory where the project that you are going to import resides, then you will get Some projects cannot be imported because they already exist in the workspace.
Therefore, to solve the issue,
Close Spring Tool Suite
Create a new directory
Launch Spring Tool Suite again
And, select that as your workspace
Launch the application and you would be able to import as you mentioned in your question
It solved my problem.
Hope it helps..
Happy Coding!!
the problem is that when you delete a project maybe sts only close it.
Try View Menu --> uncheck closed projects
Now you will see all closed project, simply delete it.
I keep my workspace folder in the Dropbox folder so I can use it on different computers. Usually there isn't a problem. Today however I opened Eclipse and found it doesn't show the projects in the package explorer.
I checked and it's set to the correct workspace folder.
I tried to Import existing projects into workspace, but Eclipse doesn't allow importing the projects because 'they already exist in the workspace' - even though they don't appear.
Will appreciate your help.
Keep your project files in DropBox. You shouldn't share a workspace like that -- it will inevitably lead to issues like the one you describe.
That is, keep the project folder, along with the .project, .classpath, and .settings/ in your shared Dropbox space. Create a new workspace on each computer, then "Import existing project" into each workspace, selecting your project in Dropbox, being sure to unselect "copy projects into workspace".
I don't have idea about using dropBox-BUT-However
For your question::
I tried to Import existing projects into workspace, but Eclipse doesn't allow importing the projects because 'they already exist in the workspace' - even though they don't appear.
Possibility:: Projects are not in Eclipse explorer but a copy of it exists in the workspace folder so eclipse is not allowing you to add the projects with same name again.
Solution:: Create a new workspace and then use dropbox to import the projects.
What you can also try is do
Create new General Project
Select in current workspace
Create project with name of an already existing project in your workspace
I seem to remember using this to "hydrate" already existing projects in my workspace into the eclipse package explorer.
This happened to me and it was because I inadvertently filtered out some of the files in the filters option in the Package Explorer.
Inside PackageExplorer -> Small drop down on top right side -> Filters
Un-select all and see if your files are now visible. Worked for me.
I had a corrupt workspace (due to svn collision).
I deleted the .metadata directory from the workspace, and then reloaded eclipse, and did an "import" of a project into the workspace.
However, the project got imported in a rather strange way -- all directories in the project appear, but the src/ directory does not have automatic compilation (when choosing a .java file) -- it is as if the src/ directory is not identified as a special directory.
Is there a way to fix that?
I also followed http://letsgetdugg.com/2009/04/19/recovering-a-corrupt-eclipse-workspace/, and that did not help either.
Switch to a new workspace.
Then go File -> Import -> Exsisting projects into workspace .
In the root folder text box , type the address of corrupted workspace.
Click Refresh .
Select the projects and click finish
All configuration data for your workspace is stored in .metadata. Try to recover the deleted folder then fix the workspace. Otherwise you will need to reconfigure everything.
You can salvage certain folders from .metadata to keep your preferences (e.g. key bindings) at least.
After importing your project, check your project properties, especially the entries in "Java Build Path". There you have to add the "src" directory as source folder. Maybe you also have to adjust the output folder and libraries you are using in your project.
create a new project.
copy your pages ,library files,etc.
set build paths.
compile it. then others will be automatically created
copy project to another (right click -> copy in eclipse)
new project created was correct for me in same situation and .class files repair .
I'm trying to make modifications to the trunk found at https://wafle.svn.codeplex.com/svn SVN repository location. The way that I did this in Eclipse was that I used Subclipse, added a new repository location, then opened up the project and right clicked on the trunk. Then I clicked "checkout" and checked it out as a new Java project. Then I found the folder containing the source code that I want to change and recompile and I used Build Path->Make source folder. Next, I realized that I needed 190394994 jar files that were all in different places under the project's "Third Party" folder. So I used Build Path->Configure Build Path in Eclipse, then individually added each jar I needed through "Add External Jars".
My question is; did I do all of this right, and is there something I could have done more easily, such as import all the jars at once instead of individually clicking each?
Thanks.
I'm guessing that you are embellishing a little and didn't add 190 million jar files by hand. (Even at 1 jar click per second, you would be going nonstop for 2,200 days.) Incidentally, you can shift-click and choose many jars from the same directory.
The secret is in the .classpath file; that is where the build path is stored. Someone before you has probably created a fully-orbed .classpath file and stored it in SVN.
If you created this as a new Java project, it will begin with a very simple .classpath with the folder for your project's class files and the JRE. (Apparently, SVN does not overwrite it with the .classpath or you chose not to merge your local version with the one from SVN.)
Next time, you might want to overwrite your project's .classpath with that fully-orbed one on SVN. Refresh and look at the Build Path. They should be all there and in place.
First thing: rajah9 is exactly correct - there is a .classpath file already.
You just got a little hung up on a really odd svn repo layout. the java stuff is mixed in with the .net stuff. Check out the trunk and then do a file > import... then select general > existing projects into workspace. You'll want to select the Source/JNAWindowsAuthProvider/ folder.
There is already a .classpath that references the jars in the ThirdParty folder. (not quite 190 million)
Second thing: when you added the jars as external jars, it makes an absolute path to the jar file. you want to always avoid that, if you hit the add jars button it will be a relative path.
I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --
src
WebContent
build
dist
build.xml
.project
.classpath
.settings/
The build directory is not supposed to checked in obviously. What about the other ones?
I am guessing all the . files should not be checked in either. Can some one verify this?
What is this dist directory and the .settings directory?
Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.
EDIT:
I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?
** EDIT 2 **
Found it! Turns out I should not check in the following --
.project
.settings/
.classpath
Once these 3 are removed the New project Wizard works as expected and everything is fine.
If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ? IMO it is cleaner to keep your project IDE-independent and easy to set up.
I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.
The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.
Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target.
You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties. You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.
Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.
In our case, we have checked in all you mentioned in the list except, .settings/.
With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.
Read this, there are some really good points to ponder about.
Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.
I would omit the .project, .settings/, dist, and build.
The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.