I am trying to use Eclipse, Subversion and Maven for my projects and everyone is telling me never to check in the following files:
target/
.classpath
.project
.settings
But if I dont check them in and some other project checkouts the project from within Eclipse, Eclipse does not know what type of project it is.. Are we doing something wroung?
How do you work?
Eclipse has a plug-in for Maven; I believe it is called m2eclipse. After having it installed you can select Import from Maven project and select the pom.xml which will import your project to eclipse even if .project and .settings are not present. So there is no need for you to commit them to svn. This comes with the advantage of IDE neutrality; other members of your team may use Intellij IDEA or NetBeans without any concern.
Also Maven has a plug-in for eclipse; you can go where pom.xml is located, open a terminal and type mvn eclipse:eclipse and it will automatically generate .project and .settings.. However the first option is more recommended.
I had the same issue with eclipse, maven and git, so maybe it is helpful for you:
Try to setup your repo in svn and check it out, but don't import it.
You have to import the project over File -> Import -> Existing Maven Project into your workspace.
The last step is to share the project. Rightclick -> Team -> Share -> SVN -> and set the existing one as repo.
That's the way I handle this in Eclipse. Hope it's clear enough?
Btw you should not check in these file, because classpath and so on could be different on other machines.
I check in .classpath and .project but not very often. You do have to make sure that everyone who is working on the project has versions of eclipse that are close enough (including the particular plugins and eclipse features included). Sometimes you can get by with very different versions of eclipse if you make sure almost nobody checks those files in and everybody just mostly compares and manually updates those files from the version control when they are updated.
If you don't check them in, everybody has to create an empty project and then load the source files (and all the version control files or folders) into the project. If you are careful you can copy in those two files and then fool with the options settings to make them match.
Note that Maven helps a lot with this as it takes care of most of the content of the .classpath file.
The main reason not to check in those files are that the IDE's will very likely make changes to those files to suit your local dev environment. Which will probably cause conflicts and thus "broken" projects if everybody is committing their versions all the time.
That said, eclipse should have decent maven integration via the m2eclipse plugin (which I believe might be baked in by default these days).
Part of the idea behind Maven is exactly this - reproducible builds cross platform, cross IDE etc etc - so IDE specific files like that should not be required to build the project.
Importing the project with the m2eclipse plugin should sort things out nicely.
If you mean the other members check out the project and it doesn't work for them, they can check out the maven project separately without using eclipse and then import it into eclipse as an existing maven project using the m2eclipse plugin. This works cleanly without any problems (for me at least).
if everyone in your team is using Eclipse and it is agreed that the project will never use anything else, you may as weel check those files in. but it will make things kind of irritating if someone uses IntelliJ, Netbeans of other tooling or has his Eclipse very customized.
It depends.
Maven documentation explicitly says something like "Do not check in .project/.classpath/.settings/ because they can be regenerated from pom.xml". The later part of the sentence ("they can be regenerated") is not true, so the first part of the sentence (the advice) may or may not be OK, depending on the circunstances. Not every bit of the Eclipse configuration can be regenerated from the pom.xml, so my opinion is that the decission is based on a tradeoff between how much gain you get from it and being tied to the particular IDE.
So it depends.
For "community projects", where usually each developer will use different IDEs and different versions of the IDE, I would recommend not to check in those files. Otherwise, it would be a pain for developers not using your IDE and your version of the IDE.
For large "corporate project", IDE and IDE version are not free to be choosen by the developer but firmly dictated by the project management. So are dictated things such as compiler(1), code formatting, validating rules, warnings-and-errors configuration, custom in-house plugins configuration and many others. Many of those things cannot be set in pom.xml (nor should they because Maven is not and IDE, but a building tool). So in this case I would recomend to check in those files and blame the developer who complies, because he is trying not to follow the dictates.
(Notice that in this case I intentionally used words such as "dictate" and "blame" because the project management of a corporate project has not only the right but also de duty to "dictate" and "blame")
In the opposite side, for one-person projects, you do not have to worry about your colleages, so go check them in.
But the key is that you have to know your circunstances and the consecuences and decide yourself.
(1) No, "maven.compiler.source" is not the compiler to be used.
Related
I am working on a final Java project for the semester with a group of other students, and we want to use a git repository to combine our efforts.
As there is no standard which IDE is used, we have .iml as well as .project and .classpath in our repository. It seems to me that this increases the importability of the project when cloning onto a new machine, but I'm sure there has to be some kind of conflict just waiting to happen.
What's the best practice here? Ignore .iml and .classpath/.project or commit them?
I'd suggest ignore the .iml and .settings and everything related to code editors or compilers. Have the setting as ambigious as possible so people can edit it in whichever format they want in whatever IDE they want.
With eclipse .settings for example, if the path differs, there will be unexpected side effects, messages of projects not found etc.. because eclipse tends to hardcode the path to the project. So /users/john/desktop/project/ won't run for /users/fred/desktop/project.
And it's not that much of an effort to set up an IDE to work with it.
Include in your project a quick setup manual for the most commonly used editors as a quick reference sheet.
If you use gradle you can take a look at how minecraft forge does it.
It has setup scripts for eclipse and for idea, so all the proper libraries are loaded and the runtimes are configured for the relevant IDE's
for someone it may seems a little weird but still I want to know if it's possible or not. We have a lot of projects which coded on eclipse so far and some of us wants to jump into intellij idea world.
Can we be able to run the projects via eclipse and intellij together at the same time? I mean for instance I'll be using intellij idea while another friend of mine will be using eclipse instead of intellij idea on the same projects, is it possible?
If it's possible, would it create any problem for version control systems such as subversion?
Subversion will have no problem at all, but I recommend you in that case that you rely your java build configuration (sources, compiler level, dependencies, etc.) on maven or gradle instead of doing it twice, once for every IDE you are using. Then both maven or gradle should be able to generate IDE-specific configuration files for each environment and you would work in the same conditions.
Actually I like the idea of working with a managed and automated build process, so if anyone is brave and bold enough to use vim... they can use it without problems, and still build their app.
Can we be able to run the projects via eclipse and intellij together at the same time?
Yes, because these IDE store their project data and configuration in different files, so they don't step on each other:
Eclipse stores its files in .project, .classpath, .settings
IntelliJ stores its files in .idea, *.iml
If it's possible, would it create any problem for version control systems such as subversion?
Not at all.
Btw I do this too sometimes: I have projects where members use different IDE: IntelliJ, Android Studio, Eclipse, with no problems.
For a Java project (with the team of 5-10 developers) should I store my IDE project files (e.g. Eclipse or IntelliJ Idea) in version control system (currently I store only build scripts)? What's the best practice?
PS Do you aware of any tools to automatically generate project files for common Java IDEs according to some descriptor?
You might want to take a look at the answers to this question: Which eclipse files belong under Version Control. As to the second part, maven has plugins for IntelliJ and Eclipse at least.
If you care about the project file at all, then you should check it into a VCS. Really, you might not care. But if you do, VCS it...
Our team (6-8 developers) originally checked in project files, and soon found that they can cause problems when it comes to paths and build path, etc. Usually not, but when an issue did arise it could take time to ferret it out. Then we stopped doing that, and it has worked much better. We now put definitions in the VCS ignore files to make sure they don't get in. However, in our case we work with Maven, so the practice has been create an eclipse workspace and then import the Maven projects from the source. So recreating project environment is quick and predictable. From my experience, checking in can cause minor headaches.
There are different opinions. Once I was told that I shouldn't put project files in VCS, but then project files ware added to repository (not accidentally).
Many open source projects have project file in VCS. I think it could be good practice if one particular IDE is proffered in other case developers should probably take care on project files by themselves.
Maven can generate project files (at last for eclipse)
I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.
Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:
I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.
For this specific project I have another reason not to commit the project files:
There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.
How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?
At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.
After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.
It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:
.settings/org.eclipse.jdt.ui.prefs - it contains the settings for the import ordering
.settings/org.eclipse.jdt.core.prefs - it contains the settings for the compiler version
In general I haven't noticed Ganymede modifying files without me modifying the project preferences.
I recommend to use maven so that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.
In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediately afterward." This means that we had to do some work:
Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
Create useful start up scripts for all of our relevant scenarios.
Create edited datasets that don't cause the checkout to take too much longer (it's a big project).
This philosophy was worth cash money (or at least labor hours which are almost more valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.
Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.
I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.
Try to port your project to a build system like maven. It has everything you need to get the same experience of the project on every machine you use.
There are plugins for just everything. Like the eclipse plugin. You just type "mvn eclipse:eclipse" and the plugin generates your entire ready to work eclipse project.
To give the answer to your question. Never check in files that are not being used by your project at any time in the development cycle. That means that metadata files like eclipse properties etc. should never be checked in in a SCM.
I like checking in the .project, .classpath, and similar files only if they will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)
If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do not check them into source control. It will only cause headaches in the long run.
I use IntelliJ, which has XML project files. I don't check those in, because they change frequently and are easy to recreate if I need to.
I don't check in JAR files. I keep those in a separate repository, a la Maven 2.
I don't check in WARs or JARs or javadocs or anything else that can be generated.
I do check in SQL and scripts and Java source and XML config.
I'd suggest having the actual project files ignored by the version control system due to the downsides you mentioned.
If there is enough consistent information in the project settings that there would be benefit from having it accessible, copy it to a location that Eclipse doesn't treat as special, and you'll have it available to work with on checkout (and copy back to where Eclipse will pay attention to it). There is a decent chance that keeping the actual project files separate from the controlled ones will result in loss of synch, so I'd only suggest this if there is clear benefit from having the settings available (or you're confident that you'll be able to keep them synchronised)
In our case, we used to check in the project files (.project and .classpath) to make it easy for all developers to create their project workspace. A common preferences file and team project set were located in source control as well, so creating your workspace was as simple as import preferences and import team project set. This worked very well, but does rely on everyone having a consistent environment, any customizations would have to be applied after the basic workspace is created.
We still do this for the most part, but Maven is now used so of course dependency management is handled via Maven instead. To avoid conflicting information, the .project and .classpath were removed from source control and are now generated via maven goals before we import the team project set. This would easily allow for different environments, as you would simply need scripts to generate the IDE specific portions based on the Maven configuration.
PS-For ease of maintenance though, I prefer having everyone use the same environment. Anything else inevitably becomes a full time maintenance job for someone.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization
Don't. Only check in the source code of your projects.
As a response to:
"There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard."
Eclipse offers a number of ways to keep local settings manageable: Java Classpath Variables (Java > Build Path > Classpath Variables) are one, 'Linked Resources' (General > Workspace > Linked Resources) are another http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Creating a README that states which settings to set before building/running the project works pretty well in my opinion.
Now how to make sure your continuous build system understands the changes that were made to the eclipse settings, thats another issue... (I have a separate build.xml for ant that I keep up to date by hand)
What is the best way to allow a team of programmers to use Netbeans, Eclipse and IntelliJ on the same project, thus eliminating the "which IDE is better" question.
Which files should or should not be checked into source code control?
I think the best way is to make the build process independent of IDE. This means that your project should not rely on any IDE-specific files to build, but rather use an external build system, like Apache Maven, Apache Ant, or even make or custom scripts. Maven is supported by most popular Java IDEs, either directly or via plug-ins.
If you don't want to use an external build systems, you should at least make the project as easy to set up as possible (i.e. by having standard folders for shared libraries and other dependencies). When I have working on teams with multiple IDEs in the past, I spent by far the most time on resolving dependencies as the prerequisites for building the project changed over time. In the worst case you may even end up with developers not bothering to get the latest version from the version control repository, since they think setting up the new project is such a hassle.
If your project has many library dependencies, I think its a good idea to make these available in binary form in the version control repository. That way people don't have to resolve all the dependencies of the dependencies and so on just to build a single project. This does however require that you have someone responsible for keeping the "official" binaries up-to-date whenever they change. (This is pretty much the same philosophy used by the Maven repository, but the principles can be applied manually even when not using Maven.)
Well, that's a pretty self-answering question.
The files to not check into source control are files that have to do with the IDEs themselves.
Leave it to the developers to generate these files.
If you use Maven, it can generate the files such as Eclipse's .project and .classpath for you. Eclipse in general is very easy to use with a basic file structure (with the new Java Project option).
I think Maven has Netbeans support as well, not sure about IntelliJ though.
Maven's site is maven.apache.org.
For each IDE that has more than one developer, check-in all the supporting files. Why re-invent the wheel at every desk.
I have done this with many different IDEs, and I have yet to see a filename conflict.
In fact, even when only a single developer uses a particular IDE, it is to his/her advantage to version the supporting files, for the same reason that you version the other files in your development environment: history, diffing, comments, etc.
For Eclipse, that would be .classpath and .project files.
My team uses Maven, and developers are discouraged from checking in Eclipse-specific files. Because they can be generated from Maven, these files are redundant.
Also, checking project-specific files seems like it would save time, but it usually winds up being a pain because of variations in different developers' workstations, resulting in wasted time resolving conflicts in the IDE-specific files. The only way to get around that is to force everyone to set up their environment the same way, which goes against the IDE-agnostic approach.
There are many considerations when using multiple toolsets within the same project team. For example, my team has Java developers using IntelliJ and most of the front end (JSP/CSS/HTML) developers using eclipse. We are in the process of migrating the Eclipse users to IntelliJ because of some IntelliJ plugins that we have developed that provide extended support for our environment. We're not going to develop the plugins for multiple platforms, so we are standardizing on IntelliJ across the board.
In terms of specific files, I can speak to IntelliJ. We have checked in our .ipr files and our .iml files. Do not check in .iws files. If you also have Eclipse users, configure your IntelliJ project to read/store dependency information in the .classpath file and commit that to your VCS.
We intentionally support multiple IDEs from the same SVN repository. Our thinking was that we want to ensure that, if a new person joined the team or someone had to start working on a new machine, we wanted them to be able to checkout the codebase, import it to the IDE and immediately have a work-able configuration.
What that means on the developer end is that they should not commit their changes to the IDE files. Everything else (e.g., src, test, lib and so forth) becomes the set that we normally update and commit every day.
The side benefit is that we have completely eliminated the IDE wars here: Netbeans and Eclipse people live in perfect harmony (looking askance at the IntelliJ people, but hey... ;-).
For more comments and answers on this topic see this question (How do you handle different Java IDEs and svn?)
We rename our IDE files for checkin with an extra extension .deletethis or similar. When a new person checks out the project, they simply strip off the extra extension and are good to go. This way we avoid source control conflicts with the project files as people tweak their environments. And you don't have to worry about educating new developers to not check in those files.
Typically, I would consider this a bad idea. I'm not sure what kind of environment this is (perhaps open source?), but it would really suck to support multiple IDEs. One thing I would recomend if this is unavoidable, would be to standardize your builds in ant scripts. If you have a large set of dependencies, this may be the easiest way to get a predictable build across all platforms.
If one of the IDEs happens to be RAD (based on eclipse), there is an entire folder called .settings that you would not want to include in the SCM.