57

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?

Hexaholic
  • 3,299
  • 7
  • 30
  • 39
Peter Cardona
  • 2,061
  • 1
  • 14
  • 14

6 Answers6

59

The 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.

Here is the section on version control:

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 other users to open the project in NetBeans without having to import the project first.

Community
  • 1
  • 1
Peter Cardona
  • 2,061
  • 1
  • 14
  • 14
  • 4
    The provided ink is broken. It essentially makes this answer useless. – Kenneth Mar 23 '14 at 15:41
  • 2
    Found a copy of the link archived at https://web.archive.org/web/20090216193025/http://www.netbeans.org/kb/docs/java/import-eclipse.html. – Nathan2055 Mar 26 '14 at 17:12
  • 1
    What about `nbactions.xml`? – Benny Code Mar 24 '15 at 11:01
  • 1
    This answer does not fully apply anymore. If you have a Maven or Gradle managed project, never commit that nbproject directory. Netbeans should autogenerate that directory upon project import. – Michael-O Aug 27 '15 at 15:51
  • 1
    I fully agree with @Michael-O Pom.xml or whatever Gradle uses should be the single source of truth for any information that is contained in them. Whatever NetBeans need but can autogenerate from the former files, should perish from source control. Different language, same situation: In C++ only CMake (and Conan if it exists) files should be source controlled, not the miriad of IDE specific trash. – Krisztián Szegi Apr 29 '21 at 08:20
19

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.

Richard Hurt
  • 2,049
  • 24
  • 32
  • 2
    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. – Peter Cardona Aug 26 '09 at 14:45
2

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
  • 114,398
  • 98
  • 311
  • 431
  • 9
    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. – Peter Cardona Aug 12 '09 at 17:12
  • 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 Aug 12 '09 at 17:16
  • 6
    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 Aug 25 '09 at 12:31
  • 8
    It doesn't hurt to have project files from each IDE checked in. NetBeans, IntelliJ, and Eclipse project files can co-exist. If you aren't using a particular IDE, the other files are not going to hurt you. On the other hand, if you are using the same IDE, having a common set of project files can be very helpful. – David J. Sep 23 '11 at 03:17
  • Now, that said, it is also very useful for a project to agree to support one or more build processes. Every commit should keep the build in order. This may mean updating your IDE build files or Ant or Maven. Whatever. If you break the build, you get in trouble. Having a continuous integration server can help a lot in this regard. – David J. Sep 23 '11 at 03:20
  • 1
    @David Having all those files, IMO, clutters the repository. Ideally, you should only have a single IDE-neutral build system (Ant, Maven, Make, etc.) and use and maintain that. – Thomas Owens Sep 23 '11 at 10:40
  • 1
    @Thomas "Clutter" is a relative term. More important is team and developer productivity. Is it more important to require that a whole team use just one IDE or is it more important to let them use an IDE that they are more productive in? (I don't think there is one right answer to this question.) – David J. Sep 25 '11 at 02:00
  • 1
    @David To me, the answer is simple. They use the IDE that they are most productive in. Because everyone's configuration is optimized for their productivity, you don't check in any IDE specific files ever. – Thomas Owens Sep 25 '11 at 03:11
  • @Thomas So are you saying that if you have 2 or 3 members of a team that use the same IDE, they should setup their build processes independently? I think that is asking for trouble. It is one thing to allow for developers to use different GUI's, but for the ones that are using the same one, I think it is smarter to setup their build process similarly. Otherwise, they are spending unnecessary time tweaking the build that someone else has already done. – David J. Sep 25 '11 at 22:00
  • @David No, saying that the build script should always be independent of IDE, captured by tools such as Ant, Maven, Make, or scripts (shell scripts, Python, Ruby, etc). These files should be checked in. However, using Eclipse as an example, the .classpath and .project files and .metadata directories should never be checked in as those contain user-specific settings and plugin information. It's trivial for most IDEs to generate the files as needed based on the source structure of the project, perhaps even reading these build files. – Thomas Owens Sep 25 '11 at 22:12
  • 2
    @Thomas I agree that an IDE-independent build process is wise, but this isn't an either/or decision. Checking in useful IDE-specific files can significantly help some (e.g. shared settings) without significantly bothering others (call it 'clutter' if you must). My position (after abusing this comment thread) is (1) a team has to make a decision that makes sense to them and (2) it is not accurate to answer this question with a categorical 'no IDE project files belong in source control'. Thanks for the discussion; I was probing to see if your underlying argument might change my mind. – David J. Sep 27 '11 at 01:38
2

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.

Ataur Rahman Munna
  • 3,887
  • 1
  • 23
  • 34
Johan Boulé
  • 1,936
  • 15
  • 19
0

You can check also
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore

This open source project contains
A collection of useful .gitignore templates

Ahmed Nabil
  • 17,392
  • 11
  • 61
  • 88
0

Toptal has a useful tool for developers wanting to find out what should go on a .gitignore file.

https://www.toptal.com/developers/gitignore

For netbeans, just search Netbeans and it should return a template something like

**/nbproject/private/

**/nbproject/Makefile-*.mk

**/nbproject/Package-*.bash build/

nbbuild/

dist/

nbdist/

.nb-gradle/

Copying and pasting this into a .ignore file on your project's directory should solve your problem.

William Medina
  • 1