Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
Related
All!
In our project team, people use either IntelliJ or Eclipse IDE depending on what they are comfortable with. Eacf of the IDEs have their own settings files. For instance, IntelliJ uses .idea and .iml and Eclipse uses .project, .settings, .classpath! While some other stack overflow thread says it's not needed to check in any of these files from either IDEs if you are using Maven, I'm unsure why that's the case. None of the threads say why using Maven does not warrant (some of) the settings, .project, .classpath be checked in?
Can someone help me understand 2 things
1) Why don't we need these files to be checked in when using Maven?
2) If we must check in (Assuming Maven is not used), how do we ensure that either IDEs work okay when checking out from source control and what to check in to ensure cross compatibility.
Thanks!
1) These files are not needed because bothe IDEs can import maven projects using the pom.xml file. So the pom.xml file is your single source of project description for both IDEs.
https://projects.eclipse.org/projects/technology.m2e
https://www.jetbrains.com/help/idea/maven-support.html#maven_import_project_start
2) You see it right, it's hard to ensure cross-compatibility if you use only the native project files of the IDEs. Among many other things that's why it's encouraged to separate the build chain (Maven, Gradle, etc.) from the IDE. Also continuous integration systems can be configured more easily if a unified build tool is used so it's kind of a best practice to use one and keep it independent from the IDE.
In case you don't want to switch to maven now, check in the Eclipse .project and .classpath files, Intellij is able to understand them.
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.
I'm working on an open-source cross-platform C++ project that supports Make and Xcode builds. I'd like to add an Eclipse project as well, but there seems to be no double-clickable way to import a project into Eclipse. Consequently, my "project" consists of fact that I have .project and .cproject files checked into the repository.
torc/
trunk/
eclipse/
??
sandbox/
.project
.cproject
...
src/
.project
.cproject
...
xcode/
torc.xcodeproj/
...
...
Suppose somebody downloads the code but doesn't use Xcode. They can build the code with Make, but many people will probably want to peruse the code structure and sources, and Eclipse would provide a great way to do that.
Unfortunately, the user may not be familiar with Eclipse or how to import projects, and I'd like to make things easier for them, not harder. I was hoping to provide something double-clickable or draggable that would get them started with minimal grief. Can anybody suggest a good way to do this? Or is there an alternate approach that would feel natural to current or prospective Eclipse users?
I am aware of this approach, using org.eclipse.cdt.managedbuilder.core.headlessbuild, but that seems to work primarily with never versions of Eclipse and CDT.
I have an answer, but it's not very pretty.
You could create a workspace directory for your project in your repository and check it in with the project already added to the workspace. Then, you could create a script which launches Eclipse and tells it to use the workspace directory in the repository. (For example, eclipse -data ./eclipse/workspace.) You should make sure the workspace has been cleaned first because a workspace that has been built can contain quite a lot of extra metadata.
That said, this is not a great solution. Experienced Eclipse users will probably not want to use your workspace because preferences are stored in the workspace, and besides, if they see a .project and .classpath file, they're already going to know how to import it into their own workspace. People unfamiliar with Eclipse are likely not to have Eclipse installed at all.
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.