I write code in several languages (Python, C, C++, and Java) using Eclipse. Is it possible to designate a directory on my machine (say /home/workspace/) as the "primary" workspace for any Eclipse session, but then to have subfolders, /home/workspace/python, /home/workspace/java, etc., in which I can create new Eclipse projects.
I don't want to have to navigate menus and select different workspaces for each session of Eclipse that I start up. I would rather just always have permission to manipulate any projects from a variety of folders at any time, but I can't find a clear answer about whether this can be done and how to do it.
As I understand your question; You want to have one workspace, but be able to code in several different languages without switching workspace but at the same time keep the projects separated?
First I would suggest you consider several workspaces, I find it convenient to keep settings and projects in separate workspaces. I rarely have to switch language that often.
But. I think what you want to do is to keep several working sets. You create one java working set, one C++ set and associate your different projects with a working set. Then you can minimize the java working set when you are running C++. For working sets you dont need any subfolders on the harddrive.
You might also want to look into Mylyn. Its a great tool for those who often are switching context. It saves the context (eclipse perspective, open files, etc) as associated with a task.
How about setting Eclipse to prompt for the workspace at launch? It wouldn't allow you to work in two languages at once, but should do the trick otherwise.
An Eclipse workspace can contain projects slated for different languages and those projects can live anywhere on your hard drive. There are at least two ways to do what you want. When creating a new project, uncheck the Use default location checkbox and browse to or specify the folder where you want your project to live. If a project already exists import the project into the workspace using the File->Import menu option and then select Existing Projects into workspace. In the next screen make sure the checkbox for Copy projects into workspace is not selected. This will leave the source files in the original folder.
In the Project explorer view, all the projects are going to look like they live at the root level. However you can group related projects into working sets. Then select just the working set you're interested in and all the others will disappear from view.
A warning is in order if you make use of eclipse variables in external tools (and possibly elsewhere). The syntax you use for paths needs to be adjusted. For example with projects outside the workspace this syntax ${workspace_loc:/MyProject/MyFile.txt} is no longer the same as this syntax ${workspace_loc}/MyProject/MyFile.txt
Related
I've been searching and searching for what the purpose is for a workspace. I've asked this question in stack chats but no one seems to know.
I know workspaces are local copies of solutions and you can switch between them when testing different things on the same projects but with different branches but I can do that with standard folders as well. So I can't figure out what the advantages and disadvantages are of using workspaces over normal folders. Is having different settings for each workspace the only advantage?
The only other obvious thing I see is shown in the screenshot but that a workspace is shown as a single "Code Workspace" file with no folder structure even though it does have one while standard folders have the structure and shows all contents.
I found this article on stack and it's kinda relevant but not as specific and it's unanswered. So instead of setting a bounty I thought I'd ask exactly what I was looking for. Asking about workspaces with settings vs user settings.
Two things which makes Workspace different from standard folders -
Like the other answer you linked to, you can have workspace based settings
In one Workspace you can open different folders which are not necessarily in the root folder which you open first.
In addition to workspace-based settings, workspaces can act like aliases that can link to a root folder (sort of like Dreamweaver's Sites feature). So you can keep a centralized folder/collection of all your workspaces in one place for easy navigation (a folder named VSC-Workspaces for example), yet they can point to and open work folders that may be saved in different locations on your hard drive, since they might be websites or python files, etc.
I have been using eclipse for a few years. I typically use just ONE workspace and have several projects for all of my perforce branches. I close the ones I'm not working on, open the one I am interested in.
The caveat to this approach is that I have to manually close empty editor tabs every time I do this.
Am I approaching this the wrong way?
I'm really not a fan of having multiple workspaces as then I have to setup proejct variables for each new workspace.
Is there a way to associate the currently open set of editor tabs to the current project(s)?
Thank you for your time.
-Dennis
Is there a way to associate the currently open set of editor tabs to the current project(s)?
AFAIK, no. However, you can associate the editors to a task by using Eclipse Mylyn. This way when you switch to an old task, it will set the editors and package exlorer to only show what you worked on the last time.
If you are working with defects from Jira or Bugzilla or a few other systems, these defects can automatically be imported into mylyn and will allow for very easy context switching.
If you dont get tasks from one of the supported repositories you'd have to manually create the tasks, but then just creating a dummy task for each project you work on would create the effect you are after.
An export of the Eclipse preferences looks a lot like a Properties file. Is this correct?
I'd like to share preferences with my team and for that, I need to filter the data (update/remove local paths, etc). Does anyone know any tools for this?
You might want to have a look at Workspace Mechanic for Eclipse:
The Workspace Mechanic automates maintenance of your Eclipse environment by tweaking preferences, adding extension locations, and so on. You can use it to:
Create a consistent environment among groups as large as the entire company, your local team, or even among your own many workspaces
Save time setting up new workspaces
Create tasks that ensure your favorite new preferences are applied to all your current and future workspaces. (This is one of our favorite features!)
If you have project-specific preferences, they will be stored in the .settings directory of you project.
That means you can add them directly in your VCS and share them through version control.
There is no native tool for filter them, but if you are using a Git repo, you can add filter drivers for making sure you ignore any path-specific changes.
Yes.
Preferences in Eclipse are implemented by org.eclipse.core.internal.preferences.EclipsePreferences. The save(IPath location) method will convert the internal structure to a Properties instance using convertToProperties() and then write the result to disk.
Is it possible to create StarTeam shortcut, opening project and overriding working directory?
Is it possible to create one StarTeam shortcut, opening several projects at a time?
Problem is: I have several solutions, which use the same StarTeam project, and I have to manually change working folder very often (View -> Properties -> Working folder). It is not possible to share data between solutions: local view should be located in separate place for each solution.
You could create different views for each project. Different views can have different working folders; in fact, they do by default. Keep in mind, a view can be set to behave pretty much the same as the default view, with regards to which revisions of files you see. But they can have their own working folders. The downside of this technique is that Change Requests and the like will also be "in the view," so moving them will not necessarily affect other views. But given that you are working on an entirely separate projects, that might not be all such a bad thing. As usual, you should experiment with this in a test project, and make sure you're happy with the behavior, before using it on your "life" repository.
The override/alternate directory for each project and folder is maintained inside a local file - not on the server. The default working folder is kept on the server, and any time you update it the changes are propigating to all other users.
The shortcut xml has no place to specify a working folder.
If you don't need the StarTeam GUI, stcmd allows you to specify a new working folder for most operations with the -rp and -fp flags.
If the projects that need this common library code are in their own views, you could also share the common project into a new subfolder within those other projects. You can use a relative path for this new subfolder that includes .. to move it outside the containing project's folder. This lets you use common code in many projects while allowing you to specify the location of that common code per project.
Shares come with some overhead, so be aware, but other than that it would probably work for what you're trying to do.
I'm using eclipse to work on a HUGE C project and it works generally well except for not being able to change views.
I create a new project and set the project source to the clearcase vob directory and it works just fine except it stores the project files in the vob. then when I change views the project cant be opened because its meta-data is sitting in the old view. I can create a new project but eclipse refuses to have two projects with the same path so I (probably unwisely) remove the original project and create it again. I'm spending too much time waiting for the indexer every time I switch views.
How can I switch views with out having to re-index everything?
I also worked on a project that used ClearCase with Eclipse. The same kind of drama that you describe happened to us on a regular basis. ClearCase was a big part of my reason for leaving that job.
With some distance between me an that horror, I've thought up a possible solution: Set up several different installations of Eclipse, with not just separate workspaces but separate .metadata and related stuff. Check out into separate Eclipses from the different views, then shut down one and fire up another to work with another view.
I haven't tried this, but it seems to me this should work.
Oh yes, you'll want to export your preferences between Eclipse installations.
Are you talking about snapshot or dynamic views here?
The path should be unique per view in both cases anyway.
In either case, what eclipse will not let you do is to have, in the same (eclipse) workspace, two projects with the same (eclipse) name.
You can try:
to have them in two different workspaces
to have a different .project per view (with a different name), provided those views reference the LATEST of two different branches.
(as As mentioned earlier in Which eclipse files belong under Version Control, those two files -- .project and .classpath -- can be under version control, provided they only use relative path.)
Perhaps the answer here is not to let clearcase anywhere near your workspace?
Use 'create project from existing source', so that the project lives inside the clearcase view, instead of having the project live in the workspace with a source folder inside the view.
Then you can have one workspace for each of your views.
This does imply checking in .cproject, .project, .classpath, etc.
if i switch view and use the same project it sometimes works if I manually copy .cproject and .project from one view to the other.