I agree that productivity is important. I'm still wondering if having
tools to get from the pom to the IDE projects isn't a better approach
though.

The things I'm wrestling with are (not all of which are really
important, but some are):
- does having derived artifacts checked in really help productivity
or can it hurt it, say if the derived one gets out of synch with the
POM file, say? There are a few ways to get settings from Maven POMs
into Idea and eclipse. (either with Maven tools or IDE tooling).
- How do you enforce that IDE configs are in synch with the project
dependencies? What if someone is relying on the checked in IDE file to
match the build settings and gets mislead because of it?
- How do you check that IDE Settings changes are portable? I've had
situations where updating an IDE settings file caused me to have to
spend an hour fixing things because someone changes something to work
on their machine only. With a maven build file I have a CI Build to
tell me quickly if something is broken. With an IDE settings file it's
a bit of a free for all.

- What if your team does not use 1 IDE? While in some environments,
(pair programming for example) having one IDE make it easier to work
together, I also know that swapping between IDEs because of project
standards can cause one to lose productivity. And "which IDE to use"
is probably low on the list of "useful standards" when compared to
things like coding style issues, etc... as long as your IDE can help
you work within the standards, why should anyone care what tool you
use?
- What happens when you have a step that works fine in a build, but is
hard to do in an IDE context. (things involving token replacement and
configuration are typical examples)? I've been on projects where we
spent a lot of effort getting something to work in an IDE when it
worked fine with the build.

Lots of things above...If I had to pick two things to understand they would be:
- Consistency of IDE settings that are checked in
- Having IDE use influence build structure

Steve

On Mon, Jan 5, 2009 at 11:34 PM, Austin Hastings
<austin_hastings@...> wrote:
> At the risk of pointing out the obvious, IDE configs are not just about
> storing build settings. They are frequently ways to save developer hours.
>
> Even if a file has nothing whatsoever to do with the build, it's worth
> archiving if it saves new developers an hour of IDE setup, or if it
> reduces confusion because of not understanding the tool (and let's face
> it, Eclipse is about the worst when it comes to bad documentation).
>
> My recommendation would be to find that one guy on the team that
> everybody goes to for advice, and archive his configuration. It may not
> be the most common, but it pays off the most in making his life easier
> when he's helping out some other victim.

--
Steve Berczuk | steve@... | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com