Re: Eclipse And NetBeans
Arved Sandstrom wrote:
Lew wrote:
Arved Sandstrom wrote:
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 t=
o
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=
and iOS
development via Xcode.
I acknowledge that it's theoretically possible.
It's absolutely possible. We've had this discussion. Depending on what
your specific needs are you may find that one, some, all or none of
Eclipse, NB and IDEA do the trick for a given job.
Nothing is impossible in any IDE, of course. But for some jobs you may
find that one IDE is all tooled up, where another isn't much more than a
text editor with no "awareness".
Just in the last 6 months, with one project involving VB6, another
involving a very non-standard project in C and C++ (non-standard in all
ways, you would not believe), and another involving Oracle Forms, and
yet another involving Pascal written with IDE artifacts specific to one
Pascal IDE, I can think of 4 cases easily where there was a very obvious
and common-sense IDE choice. Other choices ultimately could have been
made to work, but with some degree of unnecessary effort.
None of those are Java, so I don't guess I'd pick NetBeans or Eclipse for a=
ny of those scenarios. For the C, C++ situation I'd likely opt for emacs.
I was talking about Java projects, but I see how in the cases you describe =
a given IDE might not help. But since this is a Java newsgroup I'd like to =
hear of examples pertinent to Java development.
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 t=
o
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 Ja=
va projects anyway.
Well, if you're not sharing IDE config files there's nothing to worry
about. If you _are_, you probably don't want your buddy's colorizing and
font choices foisted on you. Some developers swear by their choices in
this regard; I'm not particularly fanatical but I do like my chosen font
and microscopic point size. :-)
Exactly so. This is part of why I suggest not sharing IDE files in the proj=
ect trunk.
The major IDEs work just fine off command-line/scripted project builds u=
sing Ant or
Maven or simply analyzing the code in the project. I've had substantial =
experience doing
this with both NetBeans and Eclipse and have no issue with either IDE's =
handling of "new
project from existing code".
I do approve of checking in IDE artifacts to branches in the repository=
, but not the main build trunk. The trunk should comprise only scripts and =
source.
IDE stuff in the branches makes life beautiful - you get the avowed adv=
antages 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 An=
t and Maven build scripts.
We're on the same sheet of music here. I'm talking IDE artifacts for
developers, on developer branches.
Most organized places I've worked have developer branches, test
branches, and production branches. Test and production don't care about
IDEs, and as you note you're talking build scripts and automation here.
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 circumstanc=
es
don't promote that freedom of choice.
The only circumstances that don't promote that freedom of IDE choice th=
at I've encountered involved ukases from management without anywhere near t=
he degree of logic and rational foundation you've presented.
No one has ever presented a scenario to me in the years I've tracked th=
is debate that gave shared IDE artifacts the win. On the other hand, one ma=
jor 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 b=
uild. When the project upgraded to a new version of the IDE it took more ma=
nhours and more calendar weeks to fix the IDE project files team-wide than =
it did 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,=
several clear cases I've seen where that practice caused damage.
That was a problem with mandating the sharing of Rational Developer
config files, not necessarily with requiring the uniform use of Rational
Developer. No?
Check the IDE files into a branch and my objections vanish like smoke.
I've seen both good and bad situations result from sharing IDE
artifacts. It's quite dependent on knowing your IDE artifacts if you go
down the road of committing selected IDE files. I've seen some disasters
or just annoyances myself where folks didn't know what they were
checking in. This might range from using absolute paths in an IDE config
file that otherwise would be an OK choice to place under source control
(an annoyance to others) to committing config files that never ought to
have been considered (always a PITA and sometimes really frustrating).
In large-scale projects or ones with team-member churn, you can count on su=
ch fubars if you
permit checking IDE files into the trunk.
To be fair I've also seen bad situations resulting from sharing Ant
build files and requiring those. One example comes to mind: a guy who
otherwise knew Ant quite well, and was one of the few to make
substantive changes to a particular project's build scripts, mainly
because most of the devs didn't know Ant that well. Just so happened
that buddy made some tweaks and went home for the weekend with a
vacation after. The tweaks were ill-advised and not sufficiently tested,
not at all by anyone except the original editor. That caused some
anguish start of the next work-week.
No, it wasn't me: I don't get vacations.
Just sayin'. Anything can be made to work...or not work. Although my
objections to Maven still stand. :-)
Let's be clear: I am no more _recommending_ IDE artifacts under source
control, across the board and for everyone, than I'd recommend that
everyone universally use Ant or Maven.
I do recommend that Java projects universally use Ant, though by "universal=
ly" and "always" I never mean universally or always (and never mean never b=
y "never"). Maven blows chunks and nothing else works as well.
I do not recommend using *only* Ant for builds and deployment. Feel free to=
add glue scripts (bash, Python, whatever), as indicated by circumstances.
I suggest that your colleague's ill-advised changes should have undergone t=
he rigors of review and test before commitment that all code changes must u=
ndergo. The problem wasn't with Ant there, any more than it would have been=
Java's fault if they'd changed Java code, failed to test it adequately or =
even to have it reviewed, checked it in, and disappeared.
But your examples are telling, if not pertinent to Java. Have you more to s=
ay on this specific to Java projects?
--
Lew