Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.help Subject: Re: Eclipse And NetBeans Date: Thu, 26 Apr 2012 16:31:54 -0700 (PDT) Organization: http://groups.google.com Lines: 173 Message-ID: <15568844.17.1335483114031.JavaMail.geo-discussion-forums@pbbpg8> References: <19468953.569.1335477755814.JavaMail.geo-discussion-forums@pbts20> <0skmr.24278$mL3.16210@newsfe23.iad> NNTP-Posting-Host: 69.28.149.29 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1335483114 31801 127.0.0.1 (26 Apr 2012 23:31:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 26 Apr 2012 23:31:54 +0000 (UTC) In-Reply-To: <0skmr.24278$mL3.16210@newsfe23.iad> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Received-Bytes: 9914 Xref: csiph.com comp.lang.java.help:1784 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. >>=20 >> I've never seen a situation where this was actually true, except for Mac= and iOS=20 >> development via Xcode.=20 >>=20 >> I acknowledge that it's theoretically possible. >=20 > 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. >=20 > 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". >=20 > 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. >>=20 >> The key is "non-workstation-specific", and is largely unnecessary for Ja= va projects anyway. >=20 > 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=20 >> Maven or simply analyzing the code in the project. I've had substantial = experience doing=20 >> this with both NetBeans and Eclipse and have no issue with either IDE's = handling of "new=20 >> project from existing code". >>=20 > > 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. > >=20 > > 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. >=20 > We're on the same sheet of music here. I'm talking IDE artifacts for > developers, on developer branches. >=20 > 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. >=20 > >> 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. > >=20 > > I hate Maven, too. > >=20 > >> 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. >=20 > That was a problem with mandating the sharing of Rational Developer > config files, not necessarily with requiring the uniform use of Rational > Developer. No? >=20 > > Check the IDE files into a branch and my objections vanish like smoke. > >=20 > 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=20 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. >=20 > No, it wasn't me: I don't get vacations. >=20 > Just sayin'. Anything can be made to work...or not work. Although my > objections to Maven still stand. :-) >=20 > 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? --=20 Lew