Re: Eclipse And NetBeans
Arved Sandstrom wrote:
Lew wrote:
Robert Tomsick wrote:
I've worked on projects where different members of the team used
different
IDEs. Those projects did not exist in that state for long.
Why in the world would it matter that different people use different
editors or IDEs? That makes no sense.
I have worked on teams for years where people used different IDEs and
editors. It didn't cause problems unless either management objected
(never for any solid engineering reason) or people checked IDE artifacts
into source control.
There's absolutely nothing wrong with each team member using a different
editor or IDE, and much right.
Often enough - we are not necessarily discussing vanilla Java
development here - one IDE will do certain tasks better (maybe much
better) than other IDEs. These certain tasks are required by the job at
hand. Rather than allow some aficionado of IDE X to flail away trying to
make something work, when it would definitely work easily in IDE Y, you
simply step in as the team lead and mandate IDE Y.
I've never seen a situation where this was actually true, except for Mac an=
d iOS development via Xcode.
I acknowledge that it's theoretically possible.
As for IDE artifacts in source control, there is nothing wrong, IMO,
with checking in non-workstation-specific project configurations. I've
seen this practise, for example, substantially reduce the time needed to
get new devs up to speed. This can also be used to communicate other
standardizations, rather than having people read a wiki someplace and
manually set up team-mandated settings in their IDEs.
The key is "non-workstation-specific", and is largely unnecessary for Java =
projects anyway.
The major IDEs work just fine off command-line/scripted project builds usin=
g Ant or Maven or simply analyzing the code in the project. I've had substa=
ntial experience doing this with both NetBeans and Eclipse and have no issu=
e with either IDE's handling of "new project from existing code".
I do approve of checking in IDE artifacts to branches in the repository, bu=
t not the main build trunk. The trunk should comprise only scripts and sour=
ce.
IDE stuff in the branches makes life beautiful - you get the avowed advanta=
ges of quick ramp-up and you can even set up branches for every IDE in the =
shop. However, again, this should be unnecessary with IDEs that read Ant an=
d Maven build scripts.
This is obviously a hotly debated topic. There are quite a few Stack
Overflow threads dealing with it, and a mix of opinions. Some
vociferously argue for only source and libraries, others argue like me.
Some who are in the "no config files" camp also argue for using Maven to
generate these files: this is where my prejudices show, because I
dislike Maven and wouldn't urge its use on anyone.
I hate Maven, too.
You're right, sort of - there isn't anything inherently wrong, as a
rule, with team members using different IDEs...except when circumstances
don't promote that freedom of choice.
The only circumstances that don't promote that freedom of IDE choice that I=
've encountered involved ukases from management without anywhere near the d=
egree of logic and rational foundation you've presented.
No one has ever presented a scenario to me in the years I've tracked this d=
ebate that gave shared IDE artifacts the win. On the other hand, one major =
project (involving over a million lines of code and another million of XML)=
mandated shared Eclipse (well, Rational Developer) project files, that had=
to be hand-converted to Ant scripts by the deployment team for every build=
.. When the project upgraded to a new version of the IDE it took more manhou=
rs and more calendar weeks to fix the IDE project files team-wide than it d=
id to upgrade the project from Java 1.4 to Java 5 around the same time. The=
shared IDE files were a major problem for the project.
So no clear case for mandated IDE that I've ever seen or even heard of, sev=
eral clear cases I've seen where that practice caused damage.
Check the IDE files into a branch and my objections vanish like smoke.
--
Lew