CODEWITHSUNDEEP
javaeclipsesvnmaven
techsjs2012
techsjs2012

Reputation: 1737

Using Eclipse with Subversion and Maven

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?

Upvotes: 0

Views: 2129

Answers (7)

Javier Sedano
Javier Sedano

Reputation: 953

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.

Upvotes: 0

mantrid
mantrid

Reputation: 2840

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.

Upvotes: 0

Random42
Random42

Reputation: 9159

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.

Upvotes: 6

Swapnil
Swapnil

Reputation: 8318

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).

Upvotes: 0

demaniak
demaniak

Reputation: 3915

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.

Upvotes: 0

Lee Meador
Lee Meador

Reputation: 12985

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.

Upvotes: 0

Martin Seeler
Martin Seeler

Reputation: 6982

I had the same issue with eclipse, maven and git, so maybe it is helpful for you:

  1. Try to setup your repo in svn and check it out, but don't import it.
  2. You have to import the project over File -> Import -> Existing Maven Project into your workspace.
  3. 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.

Upvotes: 1

Related Questions