Monday, May 23, 2011

Eclipse and sources under control...

Of late, I've set up a team source code-control repository from scratch for my work group. This is the first time I've done this for anyone but myself; it's always already been done by the time I joined a team. I haven't been too pleased with the uncertainty at the places I've worked so far--always policy, but never understanding why that policy. Hence my saying something to clear the smoke. There are two camps out there on the web: one for committing the hidden files to source-code control and the other for not committing them. Both are wrong in my opinion.

It seems clear now to me that the following should be the way to do things regarding the “hidden” files in the Eclipse project source base. I'm using Git; the same holds for CVS and Subversion.

It appears you don't want to commit .project to source-code control. You want to create the initial project, then make a copy of this file as .project.sample, and commit that. As each checks out the project source, he or she copies .project.sample to .project, then imports the project in Eclipse.

.project should be marked “ignore” by listing it in the .gitignore at the root of the project. Also in this file are build, bin, etc. since we do not want to include build subdirectories and .class files. I think it’s not a bad idea to include the ignore file, but by doing so, we’d be precluding that anyone maintain a separate, different copy.

This is modified by each user's Eclipse, but only when changes such as the addition of a new JAR are made. Therefore, this file should be committed. However, care must be taken not to corrupt this file by adding JARs just any which way.

Addition of new JARs
This must not be done except via copying the new JAR to an internal subdirectory such as WebContent/WEB-INF/lib or other adding via Build Path -> Configure Build Path -> Libraries -> Add JARs (and never Add External JARs).

This ensures a) that the JAR is in the project (there might be a reason not to do it this way with ivy: there certainly is with Maven, but I'm talking old-fashioned stuff here) and b) no full path is added to .classpath.

It's a simple matter thereafter to check out the project (git clone, svn co, etc.), copy .project.sample to .project, then import into Eclipse (File -> Import -> General -> Import existing...) and away you go.

While there are somewhat analogous things going on in NetBeans, and they just may have done it the right way, nevertheless, Eclipse rules. Yes it does.

August 2011 update:
There's little to add except that based on some really bad experiences, I've learned that you absolutely do want to keep the .settings subdirectory under source-code control (in Git or anything else). At very least, the Eclipse Dynamic Web Project is so complex, that gone missing what's in there will make sharing a project pretty much impossible. I tried doing it and not doing it. This is what I learned.

No comments:

Post a Comment