hiding Maven-generated artifacts under **/target/ in multi-module projects

Question

I have been tasked with migrating our existing Java Maven projects from SVN to TFS and resolve any find a suitable workflow using Eclipse/M2Eclipse.  I have managed to import projects initially to TFS and get them imported to Eclipse under TFS source control.  I can then import the sub-modules as existing Maven projects and that seems to work. 

One of the problems I have been running in to is that the assumptions that Maven uses seem to conflict with the assumptions that TFS makes.  In particular, we keep having problems with pending adds for all the dynamically generated /target/* files maven generates during the build.  This makes check in a huge pain as we have to manually de-select everything under target.  It also causes errors if anyone has a build open and someone else tries to import it, as it shows pending check-ins on files we don't ever want to check in.  This is made more confusing by the fact that even when we delete the target directories, TFS still seems to think they are there.  It seems to ignore the deletes of the directory when we do 'mvn clean'.

I am aware of the .tpignore file and tried adding it to the root project and trying a few obvious regex formats without success.  Presumably others are using this with a multi-module Maven projects so I was hoping someone might be able to suggest a few pointers.  Has the .tpignore file been tested with multi-module Maven projects using M2Eclipse?  Am I just perhaps missing something obvious about the syntax?  Any help would be greatly appreciated.

Thanks,

Sean

Answer 1

Most of our java projects use multi module maven projects. What we had to do was create a .tpignore file at the root of every module/eclipse project. Our developers don't like checking any compiled or IDE specific files. The format that worked for us was.

/target/.*

/bin/.*

.settings/.*

.classpath

.project

Hope this helps. On a side note, I have found that TFS integration with java works better when checking in the eclipse files but most of our developers don't like it. What do you guys think?

 

 

Answer 2

Regarding check-in in of Eclipse files - we definately work better that way and that is the way that we do most of our testing.  I take it that your guys do not check in the .classpath and .project files?  Is the reason for this that they might typically use many development tools on a project and do not want the source tree polluted with IDE specific elements?

Keen to understand how they want to work in this way so that we can make the plug-in work better in this use case.

---

http://www.woodwardweb.com

Answer 3

Here are a few comments from the developers as to why they don't check in the eclipse files. We also have a mix of deverlopers that use Intellij, multiple versions of base eclipse, springsource, flex, and rational rpt and rft. They basically like to think of eclipse project files as generated files so they don't want them in TFS.

"Unless you make sure to use variables when you add something to the classpath then you get a path specific to someone’s hard drive.  Thus, unless my hard drive is set up in the same directory structure as theirs, which using maven generally has your username in it, then it won’t find those resources on my drive and I have to go fix those manually.  Also, not everyone has their eclipse configured with the same plugins, etc. so that also causes issues.  It is so easy to just generate them with Maven than have to fix all the errors manually."

"This is an excellent point and deserves to be expanded on.  You could also cause problems with different version of the .project file (eclipse 3.2, 3.3, 3.4, 3.5, 3.6).  I have always created different workspaces for different eclipse versions because this can be so problematic.    How would this affect the intellij crowd?"

 

A few suggestions from the developers

 

1) If an eclipse project is not found during the import process they would like to be able to specify the project name intead of defaulting to the name of the directory.

2) The maven2 plugin for eclipse is also used and has integrations with a lot of source control systems including source safe. This plugin allows you to import a maven project that will automatically run mvn eclipse:eclipse