On Sep 8, 2006, at 6:19 AM, Frank Budinsky wrote:
Well, even the most fanatical VI user I know has moved to using an
Eclipse
VI plugin now, so I really can't imagine very many (other than
people that
also spend their weekends carving wheels out of stone :-) really
using it
these days.
Strange enough a good friend of mine (an architect at Macromedia/
Adobe) still uses it because he says VI is "burned into his brain".
The point is, we need to accommodate a heterogeneous development
community. For example, if you took a poll of the people involved in
the Java SCA project, I think you will find at least 6 of us who use
IDEA. This is of course a balancing act but it is something we should
be aware of.
As far as Emacs is concerned, I must admit that I myself still
use it when I'm doing bulk editing (my fingers just automatically hit
those ctrl keys), but it's not my IDE (it's just an editor). I know
that
Emacs is still used as a Java IDE by a few people, but not very many.
I'm sure we could discuss the pros and cons of various tools
indefinitely,
but the bottom line is that Eclipse is used by LOTS of people, not
just a
few. Jeremy may not want to alienate non-Eclipse users, but
avoiding that
by alienating the large (Eclipse users) group doesn't make sense
either.
I don't think this is a discussion of the pros and cons of Eclipse or
another IDE. It's about how to deal with all of the "hidden"
requirements Eclipse seems to be placing on our build process, and
from what Jeremy says, these requirements cause serious problems with
Maven.
Jim, you said this:
If we find that Maven consistently
causes problems for a wide variety of developers, then we should
change to something better.
But more sensible would be to say "causes problems for a large
percentage
of developers", which is the case.
Then could you propose an alternative? One of the groups at BEA threw
out Maven and created their own build system using rsync. Should we
do the same?
I don't know exactly how to handle this, but just saying all you crazy
Eclipse users are on your own, isn't going to help. I don't think
Jeremy's
portrayal of Eclipse as some piece of junk with an ongoing stream of
problems is really the case either,
I didn't read Jeremy's portrayal of Eclipse as that of a piece of
junk. FWIW, I think it's not bad but it isn't "great" either. I was a
fairly long-time user (before 2.0) but switched because I was running
into problems and, more importantly, IDEA was better for me. I did
the same thing before with other Java IDEs, moving from TextPad to
Visual Cafe to JBuilder.
it just seems to me that the bottom
line is that Eclipse has a few problems integrating with Maven that
need
to be addressed. I'm sure both the Eclipse and Maven communities
have a
vested interest in seeing that happen.
We should definitely do that. Has anyone filed a bug with Eclipse on
this? In the meantime, I don't think we should bork our build system
because of this (assuming this is a real problem, which Jeremy says
it is). Perhaps the easiest solution is to do one of the following:
1. Suggest an alternative to Maven
2. Place workaround instructions on the sire for Eclipse users where
the getting started instructions are. Eclipse artifacts such as
".project" could be there for download as well. I don't like the idea
of these going directly into the trunk as they are bound to become
out of sync.
Jim
Frank
Jim Marino <[EMAIL PROTECTED]> wrote on 09/07/2006 10:02:35 AM:
On Sep 7, 2006, at 6:03 AM, ant elder wrote:
I completely agree with Frank.
Also whether or not it is possible to get free copies of IDEA is
beside the
point, a lot of people use Eclipse so we need to embrace that if we
want to
encourage them to contribute to Tuscany.
And a lot of people use IDEA, Emacs, VI, etc. For example, most of
the developers I know use IDEA and Emacs, not Eclipse (even though
the Eclipse juggernaut has significantly more market share) . The
point is twofold. We need to accommodate as many as possible, not
just Eclipse users. The second is checking in unverifiable artifacts
is bound to lead to a break at some point.
...ant
On 9/7/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
I would say that thinking about Eclipse as just one of a many IDEs
that
people may be using is totally off the mark. In reality, there are
only a
very few popular Java IDEs (two, actually), and Eclipse is the
free one.
So, in my opinion, not accommodating Eclipse seems ludicrous - it
will
inconvenience a lot of people. I would think that the more
productive
route would be to say that we officially support Eclipse and that
we file
Eclipse bug reports and/or create (temporary) workarounds to make
sure
that it works. Saying that people have an alternative (simply
shelling out
$500 for IDEA) doesn't sound very convincing to me either.
I'm sorry but I believe thinking about Eclipse as just one of the
many IDEs is completely valid. We need to be as open as possible,
particularly since there is no good reason in my mind why we should
"anoint" a particular IDE for Tuscany developers (and that goes for
IDEA too). For me, the question is not about accommodating Eclipse
but having a build process that works with the tool we chose, Maven,
and making it easy for developers using a variety of tooling
environments. Otherwise, we should use Eclipse to do the build and
mandate that it is run prior to checkin ;-)
The need to accommodate a variety of development environments is a
balancing act. In the specific case that prompted Jeremy's rant, a
problem in Eclipse resulted in the introduction of a change to the
build process that makes working with Maven, particularly for
distributions, extremely difficult. I think we should err on the side
of Maven. Another example would be a hypothetical bug in, say, the
IDEA compiler. If it only occurs in one place, maybe we could put a
work-around in the code as long as it did not impact performance or
cause drastic changes for others. If it required something like a
performance hit or not using an important language feature, IDEA
users would need to accommodate. If we find that Maven consistently
causes problems for a wide variety of developers, then we should
change to something better.
Jim
Frank.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
