felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Tooling
Date Tue, 23 Aug 2005 17:43:28 GMT
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

  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". 


View raw message