Workspace Mechanic and project-specific settings

[Eric Rizzo]

I'm looking for a solution to keep the project-specific settings synchronized for a large number of projects. For example, I'm working on a large app with many individual projects. We want to specify consistent project settings (Java compiler settings, save actions, etc.) for all of the projects. We want the .settings folder checked into source control with each project, so that they are automatically applied regardless of what workspace the projects are checked out into. In other words, we want to ignore workspace settings.

This is easy to set up (configure the project settings the way we want in one project, then copy over the ./settings folder into all the other projects and check them all in), but it's a maintenance headache; when we want to adjust one of the settings, we have to re-copy the ./settings folder to all of the projects again.

My question is, is this something that Workspace Mechanic could help with? It's not something that the whole team needs to do, we just need 1 or 2 people responsible for making settings changes.

Thanks,

Eric

[Robert Konigsberg]

Workspace Mechanic tasks have typically focused on the workspace as a whole, and not individual project settings. However, could you just not have per-project settings and just define it for the workspace?

--
Robert Konigsberg

[Eric Rizzo]

On Friday, January 25, 2013 3:34:50 PM UTC-5, Robert Konigsberg wrote:

Workspace Mechanic tasks have typically focused on the workspace as a whole, and not individual project settings. However, could you just not have per-project settings and just define it for the workspace?

Workspace settings are not as reliable as having per-project settings checked in, IME. You have to rely on each developer workspace to actually import the settings and on developers to not change workspace settings. With project-specific settings, they are automatically applied as the project is checked out and/or updated from source control. Users can change them, yes, but at least they'd be touching a source-controlled file if they do.

I suppose I could use workspace settings and rely on every developer installing Workspace Mechanic, all pointed at a shared location for the tasks, but that's a lot of configuring not practical for the team I'm working with right now. Sadly, I barely get everyone on the same version of Eclipse, much less rely on them all having this third-party plugin installed and configured correctly. :-(

Eric

[Robert Konigsberg]

You would need to do all those things even if it per-project configuration was already easy to do.

--
Robert Konigsberg

[Eric Rizzo]

No. I'm not thinking of having every developer install Workspace Mechanic. I, or someone I delegate to, would set up and "own" the project settings and check them in. From then on, every developer would get them automatically, nothing to do. We would lock down those .settings/ files in source control so not just anyone can change them. With this particular team, we don't want that kind of thing to be wide open anyway. All I'm looking for is something to make updating 100+ /.settings files easy for me to do all at once.

Eric

[Alex Blewitt]

I hear /usr/bin/cp is good for that kind of thing.

Alex

[Eric Rizzo]

Hah. Yeah, well if you can do that with cp for 146 project folders(the number currently in our dev workspaces) , selectively among a larger set, and maintain it as projects are added/removed, then your script-fu is far superior to mine. :-)

Eric

Alex Blewitt

January 25, 2013 7:00 PM

I hear /usr/bin/cp is good for that kind of thing.

Alex

Eric Rizzo

January 25, 2013 6:54 PM

No. I'm not thinking of having every developer install Workspace Mechanic. I, or someone I delegate to, would set up and "own" the project settings and check them in. From then on, every developer would get them automatically, nothing to do. We would lock down those .settings/ files in source control so not just anyone can change them. With this particular team, we don't want that kind of thing to be wide open anyway. All I'm looking for is something to make updating 100+ /.settings files easy for me to do all at once.

Eric

On Friday, January 25, 2013 5:10:30 PM UTC-5, Robert Konigsberg wrote:

Robert Konigsberg

January 25, 2013 5:10 PM

You would need to do all those things even if it per-project configuration was already easy to do.

--
Robert Konigsberg

---