Take the 2-minute tour ×

I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:

  1. Do you check in all the Netbeans project files into the repository, normally?

  2. If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).

Thanks for any tips.

share|improve this question
add comment

4 Answers

up vote 2 down vote accepted
  1. No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.

  2. You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc. Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script. As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed. Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).

share|improve this answer
The app itself is a standalone J2SE app (no frameworks, just some external libs are used) which runs from the command line on a Linux platform. The cfg files are simple files containing name value pairs and their content change regularly. The directories must exist or the app will fail to run. –  Haes Mar 15 '09 at 9:48
Focus on a command line ant build. Create a deploy target in that build file that will bundle all of the elements together: creates required directories, creates the jar file, copies everything to the proper directories, etc. Write a shell script that will run ant and call that specific target. –  pb169 Mar 17 '09 at 18:45
For the version number, I wouldn't put it in the config files that are available on the file system. Put it in a compiled class somewhere so it can be accessed within the app but can't be modified (to falsify which version is deployed) without rebuilding the application. –  pb169 Mar 17 '09 at 18:48
add comment

Ideally, you should not tie down your application sources and config to a particular IDE.


  • I suggest you do not. Keep you repository structure independent of the IDE
  • You might have to change your application so that it's structure is very generic and can be edited in any IDE.

    Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.

share|improve this answer
Good point, but since Netbeans is already using ant for it's build/test mechanisms I thought that at least checking in the build.xml files could make sense (even if their structure looks quite complicated). –  Haes Mar 13 '09 at 13:29
As long as the build xmls do not have anything specific to Netbeans (can they?) it should be ok to check them in. But I have seen Netbeans generate some odd stuff in build.xmls, so I would be wary of such a thing. –  talonx Mar 13 '09 at 14:07
add comment

We don't check in the /build or the /dist directories.

We tend to use this structure for our Netbeans projects in SVN:


When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.

By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.

I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.

share|improve this answer
Can you clarify the "extra complication" part? What is the exact benefit that you get from storing IDE specific files? –  talonx Mar 13 '09 at 15:10
I added to the text above as I ran out of comment space here. –  Steve Claridge Mar 13 '09 at 16:14
Your clarifications make sense. But only if all the developers use the same IDE (or one of each of them checks in his or her settings). Also, devs mostly have it already setup - this becomes a problem for new developers only. –  talonx Mar 14 '09 at 4:46
I don't check IDE files into CSS, because unless you have a completely homogeneous environment (same IDE and version of IDE, same plugins, same project file structure) it's fairly common for something as simple as a full path in an IDE file to cause some very confusing problems in building your project. In general ANT build files are safer to put in source control (because you edit them yourself, and can follow rules about relative paths, etc.). –  Rob Whelan Mar 20 '10 at 2:28
add comment

To answer question #2 -- who's your consumer for this app? If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.

If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.

Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.

share|improve this answer
add comment

Your Answer


