This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
"You must put everything required for a build in the source control system, however you may also put other stuff that people generally work with in there too. IDE configurations are good to put in there because that way it's easy for people to share the same IDE setups."
This is quite contradict with my personal believe that IDE-specific configurations shouldn't be check-in to source repository. Doesn't it mean that team members have no freedom in choosing their IDE? Even they agree to use the same IDE, how can you manage the compatibility of IDE configuration files across various versions. Different team members may prefer different version of the IDE. Even with the same version, the IDE configuration files are very easy to get modified by all sort of actions. Do all those changes should be check-in to the repository?
I am re-organizing my repository so I am interested to know whether you keep your IDE-specific files in your repository. If you do, please share with me how you deal with the above problems.
We have had several fairly complicated applications and found it easier to check everything into version control and enforce a standard operating environment than trying to debug different build configurations.
There are ways to provide a middleground, such as using 'variables' in Eclipse, but again it is easier to install Java, ant, Tomcat in same location on each machine. IMO.
Our whole team is using Eclipse, and we check in all the configuration files. That way when someone changes a build path, everyone else gets it updated automatically.
I don't remember any problems with different version of Eclipse.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Thanks very much for all replies. I have to admit I am quite surprise with all the replies above. I thought we developers are a kind of creature who doesn't like to work under a restricted environment.
I agree that it will make setting up project in IDE easier but the IDE-specific configuration files are very easy to be intentionally/accidentally modified e.g. you install a plug-in that add/change project configuration or you create a new compiler profile to point to a newest JDK to test if a bug has been fixed in that JDK version or you create a new server runtime profile to try testing your product on Glassfish. How do you prevent team members to check-in this kind of changes to repository?
Joined: Jul 11, 2001
Originally posted by chatchai chailuecha: I thought we developers are a kind of creature who doesn't like to work under a restricted environment.
We are also quite lazy, and don't like to do things manually that could happen automatically. Having necessary changes automatically reflected in all workspaces is quite attractive to us.
the IDE-specific configuration files are very easy to be intentionally/accidentally modified e.g. you install a plug-in that add/change project configuration or you create a new compiler profile to point to a newest JDK to test if a bug has been fixed in that JDK version or you create a new server runtime profile to try testing your product on Glassfish. How do you prevent team members to check-in this kind of changes to repository?
*I* don't prevent that. When these things happen, as they do from time to time, we sit together and decide how to best deal with it. We are a team, after all. [ April 07, 2008: Message edited by: Ilja Preuss ]
There are 2 parts of the IDE environment (well, sometimes 3).
One part is invariant. It defines the basic shape of the project and how it gets built. In Eclipse, this is the .project and .classpath files. In IntelliJ, it's the XML project files excluding the IWS file. These I check into version control.
In Eclipse, the user's current view of the IDE is stored external to the project, so it can't be checked in. In IntelliJ, it's the IWS file, and I put it in the CVS file exclusion list. The user's current view is not only meaningless to any other user, it can actually damage their IDE in some cases, since it's more closely tied to the user's own computer configuration.
There's also often some sort of metadata that may be stored in various ways and locations (such as XML schema catalogs, run/test configurations or common JAR libraries). When it needs to be shared, ideally there's going to be a way to share it, even if it means exporting it from the IDE into some sort of shared-resource project. Ideal and real, however, aren't always the same, so sometimes each user has to build their own.
Customer surveys are for companies who didn't pay proper attention to begin with.
In my project we're generating Eclipse project files on the fly based on our regular AND build.xml using a custom ANT target. That way we could just make another target to generate IDEA or Netbeans projects if we wanted.