Workspace Mechanic and project-specific settings

110 views
Skip to first unread message

Eric Rizzo

unread,
Jan 25, 2013, 3:32:52 PM1/25/13
to workspac...@googlegroups.com
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

unread,
Jan 25, 2013, 3:34:50 PM1/25/13
to workspacemechanic
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

unread,
Jan 25, 2013, 5:00:47 PM1/25/13
to workspac...@googlegroups.com


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

unread,
Jan 25, 2013, 5:10:30 PM1/25/13
to workspacemechanic
You would need to do all those things even if it per-project configuration was already easy to do.
--
Robert Konigsberg

Eric Rizzo

unread,
Jan 25, 2013, 6:54:27 PM1/25/13
to workspac...@googlegroups.com
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

unread,
Jan 25, 2013, 7:00:37 PM1/25/13
to workspac...@googlegroups.com
I hear /usr/bin/cp is good for that kind of thing.

Alex

Eric Rizzo

unread,
Jan 25, 2013, 7:05:40 PM1/25/13
to workspac...@googlegroups.com
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
January 25, 2013 7:00 PM
I hear /usr/bin/cp is good for that kind of thing.

Alex



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:
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


Reply all
Reply to author
Forward
0 new messages