Will my .project file cause problems in other peoples workspaces?

views:

answers:

Will my .project file cause problems in other peoples workspaces?

Hi,

I share a project with other team-members over SVN. Now I am using the SpringIDE-Plugin in my Eclipse which adds a <buildCommand>-Element to my .project file, which is also under version control. None of my team members does use the SpringIDE.

So my question is: If I commit the .project-file, could my colleagues workspace break after the next update?

Thanks

+2 A:

I don't know for sure if it'd break, but it can certainly cause conflicts/confusion.

My policy is to always exclude client-specific IDE config from source control, which means .project files get globally added to svn:ignore (or .gitignore) and not committed.

An example of a bad constraint that a shared .project has is that you're forced to use the same project name.
I currently have three Eclipse projects in the same workspace, referring to the same SVN project (different branches), and using my own naming convention to differentiate them.

Peter Boughton 2009-10-20 10:48:10

I'd try the .project on another machine first, but don't jump the gun and avoid committing them. Assuming the entire team uses Eclipse having correctly versioned .project and .classpath files can be crucial to new team members. Imagine simply importing an entire project without having to configure any build path/jar resources

basszero 2009-10-20 10:57:10

"Assuming the entire team uses Eclipse" - so you're forcing a specific IDE on people, instead of allowing them to use whatever they are most comfortable with. Even when all on Eclipse, you're forcing things like plugins/nature, and worst of all, specific project names.

Peter Boughton 2009-10-20 11:32:27

@Peter Boughton Yeah, but including .project, etc. is the policy here. I am not comfortable with it either. We have a lot of libraries that must be included in several projects. So they do it to avoid configuring this again and again for each machine.

moxn 2009-10-20 11:37:55

And thanks for your time, btw :)

moxn 2009-10-20 11:38:49

Well if you've got a lot of setup to do, I'd write a script to do it - which I guess is what Pascal is referring to with his generated ones.

Peter Boughton 2009-10-20 11:45:46

I use Maven to be precise :)

Pascal Thivent 2009-10-20 12:35:10

+1 A:

In my experience, when a buildCommand fails because it is missing a plugin, the rest of the build is not affected, but it does produce a potentially annoying error message every time it fails.

Michael Borgwardt 2009-10-20 10:50:47

Ah, okay. Annoying error messages are definitely not the way to go. Thank you, I will look for a way to circumvent that. Maybe I will propose to NOT check in .project in the future. Thank you.

moxn 2009-10-20 11:40:34

+2 A:

I don't know the answer but that should be easy to test in your environment. Just try to use your .project file on one of your teammate's machine.

If it breaks the workspace when not using the SpringIDE plugin, the following rule of thumb will of course apply: "never check in files that break others environments".

Personally, I don't like to check in IDE specific files like Eclipse's .project or .classpath as I generate them (I use maven).

Pascal Thivent 2009-10-20 10:51:00

+1 for the rule of thumb :) See my comment on Peter Boughton's post. Thank you as well!

moxn 2009-10-20 11:42:13

You're welcome. I've seen your comments and in your case, I see 2 options: 1. make SpringIDE a standard in your team/company. 2. live with it if you are the exception.

Pascal Thivent 2009-10-20 12:37:22

ansaurus

tags:

views:

answers:

Will my .project file cause problems in other peoples workspaces?

related questions