If I want to use eclipse for projects in different environments,
what is the recommended way to work?
Install multiple instances of eclipse each configured differently?
No ... the typical why is you have for each of your projects a separate workspace.
All configurations are collected in this workspace. The only exceptions is if you need different plugin for the different environments, but usually this is not the case.
There is a nice tool from a google developer
http://code.google.com/a/eclipselabs.org/p/workspacemechanic
which help you to sync some general settings between different workspace.
Basically yes - things that make it easier for me are the Eclipse Workspace Mechanic (I have a folder with config files on my Dropbox, and reference that from the Workspace Mechanic preferences in the different Eclipse instances, so I automatically have them configured) and Mylyn (with which the data is usually stored centrally anyway and the settings can be exported and imported in a different Eclipse instance - I keep such an export on my Dropbox again).
Related
What is a "safe" way to share an Eclipse workspace between two computers? I've had problems using Dropbox and I've had problems using Github. I am looking for a best practice that will "just work".
Update
I read below and many other places that sharing a workspace doesn't work. But my collection includes 50 projects, are you saying that I need to create 50 github repos? There's no way to put them all in one repo to save the repetition?
Solution (imperfect, but still improving)
My collection of projects is in a github repo called projects/ which includes 50 subdirectories, each structured appropriately as they would be for an eclipse project.The /projects directory doesn't have meta-data or any other eclipse info (AFAIK)
Separately, in ~ I create a brand new Eclipse workspace. And then I "manually" import each one with Eclipse. I do this on each machine that needs to access those projects via Eclipse.
No, the workspace will contain machine-specific information and locations. Share the projects themselves, preferably through a source code management system like git. If anything in the project refers to something outside the workspace, you'll want it changed to refer to that resource in a portable way (e.g. pick the JRE using an Execution Environment instead by name).
Look at the thread at https://stackoverflow.com/a/37799711/10235188. They describe how to share a workspace and configurations between machines. Otherwise you'll always have problems with absolute paths.
What is the best way to share project specific settings between multiple Eclipse projects?
I'm working with an application that is divided into several Eclipse projects. All of the Eclipse projects should use the same compiler settings. I could duplicate the settings in all the projects, but I'm looking for a way to avoid that.
The relevant settings are the ones that are saved in <PROJECT_LOC>/.settings, most importantly org.eclipse.jdt.core.prefs but also for example org.eclipse.jdt.ui.prefs. They are the ones that are set in Project Properties > Java Compiler, Java Code Style (and a few more places).
The solution must be version control friendly.
One possible solution use a linked resource, from org.eclipse.jdt.core.prefs or .settings of the projects to the same file, located in one of the projects. A similar solutions is to use soft file system links. I don't really like these solutions, it seems to me that they are hard to maintain, for example if the name of a project is changed.
I found this question which is different because it asks about sharing settings between developers, not between projects. (I must do both.)
How to share Eclipse project preferences between users?
I think it depends on how frequently you expect projects settings to change.
If not frequently, you shouldn't over-engineer your solution: just configure one project and copy settings to other projects, put everything under version control and you're done, except for having to perform this operation again every other year, or so.
If frequently, and if a lot of settings are involved, and if all (most) workspace projects should indeed use the same settings, then consider creating your own Oomph setup, that would include your settings as workspace settings. Then let all projects just use the workspace settings. (Of course a few projects could still deviate and use their own project settings, but once using project specific settings, changes to workspace settings will have no effect on that project).
BTW: Oomph includes capabilities to also specify once and for all: selection of plug-ins to install plus how to populate a workspace with projects from version control, and more. So I can only recommend this tool if you are really concerned about systematic configuration of working environments: create one setup - apply it automatically hundreds of times. And no, I'm not an author of Oomph, just a happy user.
Sharing your workspace setup using Project Sets
Your workspace setup may consist of several projects from one or more repositories. Once you have setup your workspace, you can share it with others by exporting a Team Project Set. A project set is a text file that contains a pointer to each of the projects contained in the project set.When a project set is imported, these pointers are used to fetch the projects from the repository.
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm
A long time afterwards I got an idea about how to solve this:
Set up a multi-module Maven project.
Configure the settings in the parent pom file.
Import the projects into Eclipse as Maven projects.
Disclaimer: I haven't actually tested this, so I don't know how well it's working...
Eclipse has projects, what's the purpose of the Workspace that appears to group projects? Projects could live in the directory tree isn't that a more natural way of organizing different projects?
When you first start up Eclipse not knowing much about it, it feels like an unnecessary layer of bloat that new users have to get accustomed to first. You're forced to set up some organizing structure that, although specific to Eclipse, wants to live in the rather general-sounding place ~/Workspace.
The workspace is a collection of projects and the metadata that cannot be included in a project because it's not portable (references paths and resources on a specific system) or because it pertains to Eclipse as a whole.
Without the workspace concept, opening a project in Eclipse would be followed by multiple steps of getting things configured. This information would be lost when Eclipse is closed or all projects you ever work on would have to share the same configuration.
Examples of metadata stored in workspace:
Locations of available JDK's and JRE's. The project references a JRE by name, the workspace metadata is needed to resolve that reference.
Locations of application servers.
Path variables.
Open perspectives, layout of views, etc. Consider one application where you need Git and app server vs another application where you need SVN and Android development tools. The views you'd want to keep open and how you'd arrange these views would be very different for two applications.
Hi and thank you for reading this!
I have two computers in my office LAN: One very powerful PC which i use most of the time for development and a notebook.
Now i would like to share all eclipse projects between these two devices (for example manually sync and then switch to the notebook). I don't need them to be availalbe in a cloud or something. I have also a NAS (network attached storage) which is always running.
Is it possible to synchronize all my projects? The main problem: complexity...
I use multible eclipse installations with multible addons like Aptana
Studio, SpringSource Tool Suite, Maven, Git, ...
Most Projects are Java EE, built with maven (different maven goals like jetty or tomcat)
Some projects use git for teamwork (with some external partners)
Some Projects use my own project-builders (external programs)
I use multible workspaces (i use different workspaces for different customers which include different projects)
Some projects are inside an eclipse workspace and some are outside
My current solution is to use a file syncronization program which syncs my whole "Projects" Folder (the root for my whole working-life) to a folder inside my NAS (manual sync - not on file change or schedule). The problem with this approach: I have to synch over 100000 files. This takes 20 minutes only to analyze what has changed. And when i open eclipse one time and manipulate one static html file, eclipse changes over 2000 files (most of them are in the .metadata folder)...
I'm open to every solution. Do i have to change the structure of my project setups? Do i have to use another sync solution? Or is it just not possible? Do i have to use an cloud store solution? Would this affect projects which already use git?
Thank you for ANY reply!!!!!
best regards!
Manuel
Indeed it is possible. How about using git for this scenario? You could create a bare repository on the NAS for those projects that shouldn't be published.
I guess if you deal with source code and really a lot of files this might be the best strategy to do this efficiently and secure (in terms of get-out-what-you-put-in).
I've decided to use the FreeFileSync tool from http://sourceforge.net/projects/freefilesync/
There is some effort to configure it to ignore some files and folders, but the tool provides nice filter possibilities. Configuring these filters can be very time consuming but they're working fine :)
Thank's for all your help!
Should every team member create his or her own workspace and import project stored under source control? Or is there a way to put workspace under source control too?
How to avoid using absolute paths in workspace configuration?
Are there other bottlenecks in this task?
I would not put Workspaces into SCM; that would demand that each developer's environment be identical. Instead take care to avoid any hard-coded paths; use workspace variables.
Use Project Set Files to identify and share sets of projects that need to be imported to a Workspace. These files can/should be kept in SCM, perhaps in dedicated release projects.
My practice when doing serious work on an application is to start with a clean workspace, no extraneous projects. Populate it using the PSF.
One route people take is to generate the Eclipse projects from the build file. This has an added benefit if the development environment is designed to not have a rigid structure (e.g. the path to library X can be relatively different in environment Y than in environment Z) since the same configuration data (files, environment variables, etc) can be used to set up the Eclipse project as the non-Eclipse environment.