I'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
...avoid using absolute paths in your project
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.
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...
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
What Eclipse specific files should I add to the VCS (Subversion, GIT, etc...) when sharing an Eclipse project?
What I have here:
.autotools
.cproject
.project
.settings/
Just stumbled upon this and had the same problem some time ago, so I will try to share my experience.
First it depends on who are the other users of the VCS or better what programs they will use. If they do not use Eclipse these files will only pollute their projects.
If they do use Eclipse the files might be of use to them, but in my latest project I did not include them for the following reasons:
Everyone had another system which meant other paths for the includes and so on. Concluding from this I surveyed the contents of these files to see if they should be used:
.cproject: The includes are listed here, so you will have different files in the list on each platform. -> leave out
.project: Found some environment dependent paths here too. Maybe it also has a problem when there are different plugins installed. -> leave out
.settings: It might make sense sometimes to share the settings but usually it is each developers own decision. -> leave out
.autotools: I did not use this, so I cannot say anything about it.
Summary
It seems best to leave those files out of the repository.
For Eclipse this introduces the problem of creating a new project when importing from the VCS. In this case you should give advice on how to configure the project to set it up correctly.
When you put the project files into the VCS those who do not use Eclipse will probably have less problems than those who do, because the files are simply ignored at their site while the Eclipse users will have to reconfigure them for their system.
Maybe there is some better way to share those projects but I did not find one yet.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.