My "workspace" folder includes a hidden folder called ".metadata". Is it important to backup this folder regularly?
The .metadata folder is an area where Eclipse plug-ins can save any information they want to save. This will include things like your preference settings, information about the contents of projects and the indices the Java plug-in uses to find classes and methods quickly.
It also includes the .log file where Eclipse logs errors.
Exactly what is stored there depends on the plug-ins you have installed (one of my plug-ins has a database in the .metadata) so it is a good idea to back it up (along with the projects).
Related
I am using Eclipse Indigo, and after having successfully extracted my project folder into my Eclipse workspace, it does not show up in the package explorer. I tried refreshing eclipse and restarting it, to no avail. I am 100% certain my eclipse is using the right directory and the project is in it.
What could be the problem? Thank you.
EDIT: "import projects into workspace" worked for me, but why was that necessary?
Files in the directory are not automatically picked up by the package explorer. You need to import them.
Try using the File > import, then choose
Existing Projects into workspace.
There is a checkbox that says "Copy projects into workspace" which copies it to your workspace if it happens to be in a different folder. If you start with your files in another folder, you'll see how it's copied and set up with configuration files in your workspace directory.
To answer the question, "why is it necessary to import?" you have to realize that the Eclipse workspace is just a logical container for projects, not necessarily the physical container for them.
Also realize that a directory of project-related files does not make an Eclipse Project; Eclipse must be given or generate it's own set of configuration in order to understand a project (minimally, for Java projects, .project and .classpath). Without those, Eclipse has no idea what to do with an arbitrary folder that you call a "project." That's what the Import or Create Project wizards are doing under the covers, generating those config files.
My "~/eclipse" folder contains the following subfolders: about_files, configuration, dropins, features, p2, plugins, readme.
Is it important to include this folder, or some of its subfolders, in the regular backup of my hard-drive? Or are they just standard files that come with the installation and can always be restored by re-installing Eclipse?
Making a backup of the complete eclipse folder makes sense as it contains all the plug-ins which you have installed. Sometimes eclipse breaks because of a new plug-in or just any random problem. Then it's great to have a backup and you don't need to install every plug-in which you had before.
I'm often surprised that Eclipse is giving error during search "File is out of sync with file system", for the file that I have not even opened. I have a large workspace with hundreds of files under SVN control. I have configured Eclipse to "auto-refresh" on load to minimize such issues.
I can't stop wondering how can this happen at all? Why does it need to "refresh" if it should (at least I expect it to) just load everything from file system?
It looks like it's storing all the files somewhere (not even in memory, having a need to refresh on load), and if it's true - I don't like it.
Eclipse does not store your files anywhere except your workspace directory and does not use the file system directly every time when you need some files.
Eclipse indexes/caches different meta-information for all projects and theirs files in your workspace. The information can be found under .metadata folder of your workspace directory.
Such information is used to provide the tree of the files to the Eclipse and show resources in views such as Project Explorer, Package Explorer etc.
The main reason of such behaviour is performance purposes.
The out of sync problem appears when:
you create files manually (out of the Eclipse) in your workspace
Eclipse plugins or processes create/update/delete/etc. files improperly i.e. do not call related Eclipse API to refresh the resources and update the indexes.
I'm trying to re-familiarize my self with the Eclipse environment and ant integration.
Question is: how to keep my sources dir + build.xml separate from the workspace?
What I have is
a small java project and its build.xml file with all the sources placed under a separate
project folder. I then started Eclipse and let it import my project via
New Project -> "Java Project from existing Ant Build File"
All went fine, until when I wanted to build the project from inside Eclipse using build.xml.
Ant starts complaining about not being able to find the source tree. After I examined
the workspace I found that Eclipse had copied the build.xml into the workspace, so it's
obvious that ant couldn't find any sources there. They are still under my project director
and I do want to keep them there, if possible.
so whats the best way so make this setup work? workspace on one side, my project on the other?
Thank!
edit: Is what I want even possible ?
Instead of using "Java Project from Existing Ant Buildfile", just create a simple "Java Project". In the wizard uncheck "use default location" and enter the path (or browse) to the top level directory of your existing project (i.e., where your build.xml is). True, eclipse will create .project and .classpath files in your project directory (if they do not already exist), but the project will remain outside the eclipse workspace.
Case in point, this setup has worked really well in a very particular situation on a standalone system where the source tree resides in a common location but each user has a workspace in a protected location. Using the method described above, each user of this system can create a project in their own eclipse workspace, execute ant targets and subsequently remove the project from their own workspace without affecting other users' workspaces.
What about using links?
Windows Symbolic Links
Linux man page for ln
I do this all the time in C++ projects (no Java, sorry, but I think the concept is portable).
I have my workspaces in ~/workspaces/{workspace_name}. I have a single shared project file in ~/{my_projects, and then the source trees (multiple versions) are in ~/proj1, ~/proj2, etc.
Within each ~/proj* directory, I put a symlink to ~/my_projects/.project and .cproject (required for C++, not used in Java). So each source tree is sharing the single project file. Then in each workspace (one for each source tree), I configure the workspace by importing the project link. For example, ~/workspaces/proj1 imports ~/proj1/.project, but ~/proj1/.project is actually a symlink to ~/my_projects/.project.
So this keeps the source separate from the workspaces. When building, there's no real configuration to do -- I just have Eclipse run make in the appropriate node of the tree -- we already have our own command-oriented build system (we're not using ant, but the same principle should apply).
I source-control the ~/my_projects folder in a private area of the SCM, so other team members don't see it or fiddle with it -- many of them don't use Eclipse at all.
There isn't really any need to try and avoid Ant and Eclipse using the same set of source files. In fact, its probably better that they do use the same set.
Bear in mind, you're not actually mixing anything. There is just one set of source files and then there are two different ways of building it; Ant and Eclipse. These builders are independent of each other, so there is no problem with being coupled to Eclipse. You can even happily commit all the eclipse files (.classpath, .project, .settings) to source control without affecting any developers who use a different IDE.
I do this all of the time (admittedly using maven, not ant), but the same principle applies.
If you have an existing project in Eclipse (with the .project in the source tree), then you can Import Project->Import Existing Project. When the dialog box comes up, you can choose to 'Copy projects into workspace'. Make sure this is unchecked, and them import.
You still store the .project in the original source tree, but thats all.
So now I have
code/xxx (which contains the .java files, which are in SVN)
code/xxx-workspace (which contains the eclipse workspace)
I am the only developer on this project.
I would not add the complete workspace, but I would add the .classpath and .project files (as well as the source, of course) so that you can recreate the project if needbe.
I wouldn't commit the whole workspace. But it is worth exporting platform settings and checking them into source control (probably in a separate SCM project as they don't really belong to any individual project) if you've made several changes in case you need to import them into a new workspace.
Examples of these files are those settings for:
Java->Code Style->Formatter
Java->Code Style->Clean Up
Java->Code Style->Code Templates
General->Editors-Text Editors-Spelling-Dictionary
Any other preferences you've made extensive changes to that support import/export
You should check in the primary sources/resources for the project. As others have noted, for a typical project this includes the .project and .classpath files.
Depending on the type of project, I'd add the .settings folder from the project. This folder contains project-specific settings that override the platform preferences, and other project-specific settings. If those are essential to your project then I would add them.
No.
Files that are generated by the IDE or by a build process (binary files, documentation produced by a generator) should not be checked into source control. The only files that should be checked in are your source files and external libraries that your source files utilize.
You might also be interested in the answers to this question: What should NOT be under source control?
I would commit only the project(s) you are working on, as well as .classpath and .project files, and not the whole workspace itself.
Even if you are the only developer, avoid committing the .settings directory. You could switch to another version of Eclipse, or another installation with a different set of plugins, and when you checkout projects in the second installation the .settings directory will be different. Also the .metadata directory is bound to vary.
That said, attempt to use Maven so that the Eclipse .project and .classpath files can be generated without requiring them to be checked in.
I've played with the idea (with Subversion) of having a "MyProject_Eclipseproj" folder that only contains the the Eclipse project files and directories, with an svn:externals prop that pulls in all the "MyProject" files/directories.
So, the layout would be:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
The MyProject folder would be pure code, no eclipse contaimination. The MyProject_Eclipse_Ver would contain Eclipse specific files, and pointers to pull in the code folders. You could also have specific folders for different Eclipse versions so each developer wouldn't be forced to upgrade if something changed in the .settings or .project file between versions.