views:

1165

answers:

5

We normally use Eclipse for a particular Java project, but recently I imported the project into NetBeans to use its dialog building features. Since I'll probably come back to this, I wanted to store the NetBeans project files into version control. However, I don't want to commit files that are "mine" versus "project", i.e., files with my own settings that would conflict with another user's.

NetBeans created the following structure in the top-level project area:

nbbuild
nb-build.xml
nbproject
    <various files>
    configs
    private

Clearly nbbuild is build output, so that won't go in. The nb-build.xml file seems likely, as does most of nbproject. However, nbproject/private suggests it's "mine". Peeking at "configs", it's not clear to me if that's mine or project...

Anyone have some guidelines?

Thanks!

+2  A: 

None.

Only source files, build scripts, and documentation that is not automatically generated (e.g. - the output of tools such as JavaDoc and Doxygen) should be checked into a repository. Things like project files, binaries, and generated documentation should not be checked in.

The reason is two-fold. First, you don't want to overwrite another developer's project settings with your own. Second, other developers might not be using the same IDE as you (or even an IDE at all), so don't give them any more than they need to build (the project or its associated documentation) or run the project.

Thomas Owens
Clearly not going to add build output (including JavaDocs). But I doubt the best answer is "none". Each developer would then need to setup common project settings locally, including simple things like which dirs are source, or what JDK level to build for. Not sharing that sort of project setup information would set us up for trouble. For example, I write code that works for 1.6 but our project ships for 1.5. I commit that, and break the build.
When I import a project with Eclipse, it's trivial for me to identify source directories and the JDK to build for. Besides, there should be a build script that does that for me, since I might not be using an IDE at all (but rather a text editor - Notepad++, emacs, vim). Every job that I've ever had that used source control only committed source files and human-generated documentation to the repository and I've never seen a problem.
Thomas Owens
I don't agree with this. I think it makes things a lot easier if all devs on a project are using the same IDE and version. Project files should be checked in - it means each dev does not have to jump through hoops setting up their environemnt each time they need to work on the source. If everyone checks out projects and dependent projects and JARs into the same location or relative path structure then they should be able to checkout and click build in one step. Too much time wasted if everyone has to re-configure a project and fix broken dependencies all the time
Steve Claridge
+4  A: 

netbeans knowledge base article on project files & version control discusses the NetBeans project files, with loose advice about which files are project specific (i.e. can be shared via version control), and which are user specific.

+1  A: 

It turns out that both Thomas & Petercardona are correct, in a way. NetBeans recommends that you only import source code and/or documentation. Oh and the nbproject folder but not the *nbproject/private** folders.

From the NetBeans Knowledge Base article on importing Eclipse projects:

Version Control Considerations

If the project is checked out of a version control system, the build (or nbbuild), dist (or nbdist), and the nbproject/private folders should not be checked into that version control system.

If the project is under the CVS, Subversion, or Mercurial version control systems, the appropriate "ignore" files are created or updated for these directories when the project is imported.

Though nbproject/private should be ignored, nbproject should be checked into the version control system. nbproject contains project metadata that enables others users to open the project in NetBeans without having to import the project first.

RNHurt
That's the same link I posted above, no?I think there's a distinction between *importing* only source and *checking in* project files. As I read it, the former means bringing files into the NetBeans IDE, the latter means putting files into version control, and includes project setup files.My question was regarding the latter. I want to share files that control how the build is produced (standardized jar locations, jdk level), but don't control things like formatting preferences, IDE window layouts, etc.
A: 

I agree with Steve Claridge that when Thomas Owens is manually setting up source paths, paths to makefiles, to build scripts or other build settings in whatever IDE, he's actually loosing some time. Such general setting may go in the source repository.

bohan
A: 

As tested with Netbeans 6.8, only the project.xml, configurations.xml and the main makefile (the customisable one in the parent dir of the 'nbproject' dir, with pre/post target definitions) must be distributed via the repository. All other files will be automatically (re)generated by Netbeans (Makefile-impl.ml, Makefile-variables.ml, all the Makefile-$CONF, Package-$CONF.bash). The 'private' dir should also be ignored, obviously.

bohan