Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #1782

Re: Eclipse And NetBeans

Show all headers | View raw

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 and 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 using 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 advantages 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 and 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 degree of logic and rational foundation you've presented.

No one has ever presented a scenario to me in the years I've tracked this debate 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 manhours 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.

Check the IDE files into a branch and my objections vanish like smoke.

-- 
Lew

Back to comp.lang.java.help | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Eclipse And NetBeans Steve <tinker123@gmail.com> - 2012-04-19 16:35 -0400
  Re: Eclipse And NetBeans William Colls <william.colls@rogers.com> - 2012-04-19 17:18 -0400
    Re: Eclipse And NetBeans Lew <lewbloch@gmail.com> - 2012-04-19 17:36 -0700
  Re: Eclipse And NetBeans Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-19 19:42 -0300
    Re: Eclipse And NetBeans Robert Tomsick <robert@tomsick.net> - 2012-04-25 17:09 -0400
      Re: Eclipse And NetBeans Lew <noone@lewscanon.com> - 2012-04-26 07:30 -0700
        Re: Eclipse And NetBeans Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-26 18:05 -0300
          Re: Eclipse And NetBeans Lew <lewbloch@gmail.com> - 2012-04-26 15:02 -0700
            Re: Eclipse And NetBeans Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-26 20:00 -0300
              Re: Eclipse And NetBeans Lew <lewbloch@gmail.com> - 2012-04-26 16:31 -0700
                Re: Eclipse And NetBeans Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-27 16:15 -0300
          Re: Eclipse And NetBeans Robert Tomsick <robert@tomsick.net> - 2012-04-27 13:07 -0400
        Re: Eclipse And NetBeans Roedy Green <see_website@mindprod.com.invalid> - 2012-05-10 15:28 -0700
        Re: Eclipse And NetBeans Roedy Green <see_website@mindprod.com.invalid> - 2012-05-10 15:33 -0700
  Re: Eclipse And NetBeans Allen l <debare21@gmail.com> - 2012-04-26 18:38 -0700
  Re: Eclipse And NetBeans Roedy Green <see_website@mindprod.com.invalid> - 2012-05-09 19:11 -0700
    Re: Eclipse And NetBeans Steve <tinker123@gmail.com> - 2012-05-15 09:43 -0400
    Re: Eclipse And NetBeans Steve <tinker123@gmail.com> - 2012-05-15 09:45 -0400

csiph-web