felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Tooling
Date Tue, 23 Aug 2005 21:48:02 GMT
The problem of community coordination is difficult no matter what. 
Certainly there are setup and convention issues.  I believe this to be 
true of any community/society.  The current discussion on where to put 
what and how to arrange the repository is a perfect example.  This is not 
inherent in IDEs (GUI or otherwise).  The point of tooling, including 
IDEs, is to help the community to produce better output faster and with 
less pain.

Your message below highlights that there are different points of view on 
how to develop software and in fact, whether not IDEs help.  For example, 
the Eclipse tooling emphasizes developer experience in the code, compile, 
debug cycle to make this basically free.  No classpath maintenance, no 
building, no deploying, ....  Some people prefer to manage their 
classpaths, build JARs, deploy them and then debug them.  This, like 
formatting, is a religious discussion best left for beer time.

My main reason I sent the original message was to point out that there are 
many Eclipse developers out there.  Many of them are "plugin/bundle" 
developers.  In the process of building an OSGi community it seems that 
Felix would do well to embrace these people and not prohibit their 
participation through ignorance.  To that end, since you have complete 
freedom in setting up your conventions and structures, I suggest that you 
not set things up such that Eclipse users have a hard time living in this 
community.

Jeff

Niclas Hedhman <niclas@hedhman.org> wrote on 08/23/2005 01:43:28 PM:

> 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 
ofexisting, 
> and definately unsolved, issues around the "IDE as build tool", and to 
some 
> lesser degree "Eclipse for collaborative efforts". 
> 
> 
> Cheers
> Niclas

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message