Niclas, All of us at Eclipse recognize that there are many people who prefer to not use IDEs. The point of Jeff's post was not to encourage anyone to move to GUI-based tools who don't want them.
However, there is a thread from a while back entitled "Oscar's Studio" that talks about building an Eclipse plug-in for Felix (nee Oscar). What Jeff is suggesting is that a highly functional GUI tool already exists for building bundles already exists with the Eclipse 3.1 Plug-In Development Environment (PDE). As external observers, it seems that a sensible alternative to writing YAPI (yet another plug in) may be to evaluate the PDE to see if can address your requirements. If there are deficiencies in the tools, file bugs and I'm sure Jeff's team will try their very best to address them. But this is not an assertion that non-GUI tools are unnecessary or undesirable. Clearly, many very good developers prefer that approach. It seems quite possible the Felix team may draw a distinction between the tools that you want to use within the team for Felix development (likely non-GUI, based on your comments) and the tools which you would like to make available to your consumers (likely GUI, based on the "Oscar's Studio" thread) to help encourage adoption. > -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: August 23, 2005 1:43 PM > To: [email protected] > Subject: Re: Tooling > > 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
