Having a bit of a problem,
Due to the source-control set-up we use, each bug/enhancement is worked on in a new branch. This is fine, but when in Eclipse, we need to set-up a new project for every branch.
Is there any way of easily setting up default preferences for a project, or importing/exporting project preferences within Eclipse?
Thanks,
Stuart
One possible solution would be to store those common preferences at the workspace level for Eclipse (see Manage your Eclipse environment article)
The downside of having multiple workspaces is the need to share development preferences among them.
Since preferences are persisted on a workspace basis within Eclipse, you have to export your workspace preferences and import them to your desired workspaces (File > Export > Preferences).
Even if you stay in the same workspace (with several projects), you can share common settings with other developers by exporting those workspace preferences.
As mentioned by Fabian, the project specific settings are in .classpath and .project, but he left out .settings:
.settings are for IDE project-specific settings like compiler warnings and so on.
It you want to share project-specific IDE-related settings, just copy the .settings directory from project directory to project directory.
Tips: copy your project launcher (created by default in <workspace>\.metadata\.plugins\org.eclipse.debug.core\.launches) into your .settings directory: that way, you will also share your custom project launchers.
The above methods might work in some settings but do not address the problem of exporting a single project from your workspace including its properties for use by another person.
One way of doing this is to export the project folder as a zip archive as described above but also save the following file from your workspace:
.metadata/.plugins/org.eclipse.core.resources/.projects/MYPROJECT/.indexes/properties.index
where MYPROJECT is your project name.
If you then import the project as a new project in a different workspace you can afterwards
copy this file into your new workspace metadata and you will have the original project properties.
The project-specific settings (contrary to the already mentioned workspace-specific settings) are stored in two hidden files in the project: .classpath and .project, which you might be able to reuse to setup your projects.
Have a look at Workspace Mechanic
Related
There's an option to start a project in Spring Tool Suite we can select our Project path and Workspace. Where I need to choose if I need to save project files?
I need to save files on D:\3rd year\SQA location. Where I need to put this, in Project path or Workspace?
Updated
In this window when I click "Add a local project" link in below the above window appear.
The workspace is a concept of Eclipse and contains the metadata for settings and which projects belong to the workspace. You can put your projects into your workspace folder, but you don't have to. You can put your projects anywhere you like. And you can import projects from anywhere into your workspace.
When creating new projects in Eclipse/STS, the wizard usually asks you where to store the project itself. The default is often set to the workspace location, but you can change that and put the project anywhere.
Therefore, in your example, the project path is probably the path where your project itself is stored (or will be stored), whereas the workspace location is the location where your workspace metadata information will be stored.
Hope this helps!
This is how the workspace assign on an eclipse
My Web project run only when my project is at c:\Ampps\www\myProject but eclipse contains it on C:\Simple\workspace\myProject. My problem is I want to run project and the workspace is different. What is the things keep in mind before choosing the workspace. And what are the alternatives if the wrong workspace choosen ?
Eclipse does not require your projects to live under your workspace folder. Therefore you are allowed to have a project and workspace as you describe.
When creating a project, uncheck the default location checkbox in the wizard and select your truly desired location.
My only recommendation on workspace location is to have it on a local drive and don't have it as a sub directory of any project in your workspace.
How can I clone all of my Eclipse settings (preferences, plugins, etc) from one computer to another?
IIRC, Eclipse installs into a folder as opposed to all over the place like most Windows apps. Have you tried just copying the entire folder?
They are stored in the .metadata directory in your designated workspace directory. So you can copy that over, although some settings may not work right away as they contain absolute paths.
If you are referring to the plugins themselves, just copy the eclipse_dir/plugins folder
Eclipse has an import/export facility for general workspace Preferences:
File > Export > Preferences
Choose "Export All" and then provide a destination path and filename for your preference file (Eclipse will automatically add a .epf extension).
In a new (or existing) installation of Eclipse import the .epf file
File > Import > Preferences
Project specific settings, if you enabled (and configured these), are stored in the subfolders .classpath, .project and .settings inside the project folder. Assuming you preserve your project folders for use by the new Eclipse installation, your project-specific settings will remain safe.
Eclipse projects are also imported/exported via Eclipse file menu:
File > Import > File System
see this post regarding the way Eclipse uses the workspace .metadata directory
I'd like to associate some ANT targets with my project's build in Eclipse.
No problem, I create a custom ANT builder, specify targets to run, all is well.
But then I realize that the builder information is saved in the workspace instead of the project! Why is that, and how do I fix it?
The goal is that anyone who imports the project in a new Eclipse workspace can build it without adding the builder manually. This means that I should have the builder configuration under source control, which means it should belong to the project, not the per-user workspace.
Maybe I'm just missing something?
There is a bit of confusion, it seems, because builders look like launchers, but they are stored in a different directory. Simply creating the .settings dir and copying the xml doesn't help...
When I create the .externalToolBuilders directory under .settings and copy the launcher/builder there, I get this:
Solution:
I restarted from scratch, deleted the project-specific data in the workspace directory, but left the .settings dir in the project dir. Re-created the builder/launcher, and Eclipse automatically created it in the correct place, and also added it to source control.
Indeed, your launcher (Run/Debug launchers or External Builders launchers) are saved by default in the workspace.
<workspace>\myProject\.externalToolsBuilder)
You can move that directory (.externalToolsBuilder) manually in the .settings directory of your project.
And uncheck the option "Delete configurations when associated resource is deleted" as mentioned in this SO answer.
With a full refresh of the project (or even a delete, followed by a reimport), your local version of .externalToolsBuilder should be taken into account.
For the Debug/Run launchers (not your case), you also can (since Eclipse3.4) use one of the Import wizards:
File > Import
type launch configuration, and you can import said configuration directly within your project.
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.