On Tuesday 23 August 2005 23:26, Jeff McAffer wrote:
> The summary is that we can (and will) do better in the tooling but the
> present tooling addresses the very significant issues of classpath
> management and incremental building/launching/testing. In our experience,
> those are the places that developers really get tripped up and spend time.
I have a perpetual fear of becoming dependent on (to whatever degree) on GUI
based tools, as experience generally shows that there are several issues
related to IDEs and collaborated efforts;
1. It is difficult to get people to have the *exactly* same setup for the
IDE. This results in for instance "automatic formatting" being executed
by individuals, committing code into the repository with no positive
content, only creating larger commits which are hard to review.
If several such individuals are let free, review deteriorate to "none"
and is a "no go" for auto formatting.
I agree this is the developer's responsibility, but the IDEs does not
seem to take this very seriously. I am sure you (Jeff) will highlight
that the entire eclipse community manages this "issue", so I guess;
- each part of the codebase is only coded by one person, or
- draconian enforcement of a common setup, or
- checkstyle is enforced in Subversion pre-commit hook, or
- peer review is not done by the mails sent from commits, or
- everyone thinks it is Ok.
Perhaps I have missed some better way... but any of the above seem
"difficult".
2. It is still unclear to me, whether the hidden .classpath and .project
files should be committed to a shared code repository or not. Some
claim it is possible to solve the issue with "Variable" in Libraries.
IIRC, generation of Jar files and other artifacts also seemed very
sensitive to introduce "local conditions" making it troublesome.
If they are not committed, it is hard to keep up with changes
made by other people (introduction of new packages for instance).
If they are committed, the commits become "large", more frequent and
harder to review.
3. People who have "strong" IDE background tend to do many "sensitive"
tasks manually, since it "is so easy, just click...", which to me is
insane. Maybe it is a coincidence that my experience is that
"Eclipse-only releases" are more riddled with problems than those with
automated processes. (By the way, that goes for other manual tools
used as well, so not an Eclipse problem per se.)
4. The IDEs I have used so far (Eclipse, Netbeans and IDEA) are all
extremely weak in dependency management. No separation between build,
runtime and testtime dependencies, which would create incorrect
dependencies for the bundles (if used), AFAICT.
I don't want to discourage people to use Eclipse in any way, but I am
convinced that it, and all other IDEs, are not good "build tools", but is
excellent in other areas to improve productivity, such as editing, access to
relevant information, navigation, refactoring and so on.
Another related note;
Small detail about Bundle development with Eclipse 3.1, that I am currently
being faced with;
The Eclipse developers (I am not one of them) claim that Eclipse "must have"
the bundle manifest in <projectroot>/META-INF. I think I have also heard that
Eclipse "own" that manifest and will populate it as one "go along", whereas
we depend on automated build processes which will generate the manifest
during each run, from the overall project model (similar to Maven's POM).
Somehow I get the impression that this is an example of a "all-or-nothing"
approach that does not improve group productivity and is potentially a
quality risk.
I hope I don't sound too negative. Just trying to raise awareness of existing,
and definately unsolved, issues around the "IDE as build tool", and to some
lesser degree "Eclipse for collaborative efforts".
Cheers
Niclas
