views:

92

answers:

5

What do people think is the best way of setting up a Java, maven-2 web project so a new developer can come on board easily?

Do you checkin you project settings, .classpath, .project .settings folder etc into source control and use variables?

Or

Is it better to just checkin code and use the maven eclipse plugin to generate project settings?

Keep in mind these are multi module projects, with different facets so the project meta data could be quite complex

A: 

check out everything with m2-eclipse should pose no problems at all; at least for us. So don't use SVN perspective, but in new project there is also an option under Maven to choose Check out maven project from CSV.

toomuchcs
+3  A: 

Never ever ever check in any .* file in a maven project. It will mess things up whenever any developer turns on or off any eclipse builder or nature.

If you need to enforce common configuration, use the additionalConfig flag of the Maven Eclipse Plugin

seanizer
To the downvoter: you apparently haven't been in .project hell yet. I have been there and I'm never going back. I refuse to work in projects where eclipse configuration files are checked into the SCM.
seanizer
It is rather unprofessional to say "I refuse to work with"... especially that you haven't gave any arguments why project configuration should not be checked in.Anyways, like I said, it is a matter of personal preferences. Besides, .project and other Eclipse configuration files independent of the local environment, so in most cases it is not an issue.
Eugene Kuleshov
@Eugene **Not** having them checked into scm is not an issue. There are a lot of eclipse installations out there that put platform dependent absolute pathes into these files. Everything you need is a pom.xml.
Willi
@Willi no it is far from everything. At very minimum it must set the code style, formatting settings and code templates.
Eugene Kuleshov
@Eugene Let me rephrase "I refuse to work with": a) "I hope I'll never have to work with ..." and b) fortunately I am usually in a position where I get to make this kind of decision myself. BTW, Classes and Jar files are also independent of the local environment. Does that mean I should check them into the SCM also? No, an easy guideline for maven projects is this: everything that's not either pom.xml or underneath src goes into .cvsignore or svn:ignore etc.
seanizer
@Eugene These configuration files can be supplied as separate files. But you should never check something in that can be generated from the source code. .project and .classpath files can be generated from the pom. You wouldn't check in .class files. Am i right?
Willi
@Willi there is lot of stuff under .settings folder which can't be generated from the "sources". Besides, why generate something that is easier to edit in IDE? Like I said, it is personal preference, but you don't have to make it absurd.
Eugene Kuleshov
Why do you say this? You can parameterize any local references.So you all you have to do is set a system variable and thats it. You wouldnt have references to "C:\myproject". If you use maven you have to run lots of commands to generate the project structure i.e. WTP with all the options you want.
+1  A: 

This is controversial, and normally depend on a person's own judgment.

Personally I like to check in all IDE configuration files, especially if all team members are using the same IDE. This way you can use IDE's UI to manage project configuration, such as formatting and other code editing settings without need to manually tweak Maven's plugin configuration, which is too easy to break.

Eugene Kuleshov
+1  A: 

It depends on your environment. If your developers use similar machines in terms of OS and disk partition, workspace location, framework(s) location, etc, then I don't think you will have a problem with checked-in settings, in fact, as some have stated here, it can simplify the process of on-boarding.

However, I've always worked in environments where everyone has his own individualized settings, some people used macs, some were on windows or linux, etc. Disk partitions were not the same neither was the way everyone organized their workspaces. In that kind of an environment committing project settings can cause really big pains. We've always added them to SVN ignore list. We use a screencast to make on-boarding quicker.

shipmaster
A: 

We do not checkin files like .project, .classpath and .settings in our VCS for the reasons given by @seanizer: avoiding hell.

So here is how we handle things:

  • we use m2eclipse or the maven eclipse plugin to derive what can be derived from the POM
  • we use a dedicated build-tools Maven module to hold files such as our
    • checkstyle.xml as suggested by the Checkstyle Multimodule configuration
    • codestyle-eclipse.xml (Eclipse Formatter profile ready to import)
    • codetemplates-eclipse.xml (Eclipse Codes Templates ready to import)
  • we document how to setup the development environment using the above files in our Wiki

All this is highly inspired by what Vincent Massol is doing at XWiki (see their Java Code Style page and their svn for a concrete example).

Pascal Thivent