I'm developing a web application in Java and I'm using several third party JAR files in my lib folder. I also have Subversion as my version control tool.
My question is, while checking in my project files, should I check-in the JAR files also or is it not needed to version the JAR files as I'm not modifying them anyway?
This is a pretty subjective question...I typically apply the following rule of thumb: if I have the code to build a binary, check in the code, and never the binary; if a binary is required to run my code and it comes from an external source, check in the binary.
Note that you'll want to conform to whatever legal conditions might come along with checking in some third party binary to your repository..
I would recommend that wherever possible, you should use Maven. Then you wouldn't need to check third-party JARs into your repository to share them amongst your development team (most of the time).
If you're not already aware, Maven performs two major tasks: build automation and dependency management. Each project has a descriptor file that configures, among other things, which JARs you use as dependencies. The nice thing about that is that Maven will automatically resolve for you the dependencies of those JARs, and their dependencies, and so on.
Hi Veera,
I manage the SVN repositories for a medium sized development team and for ease of use, we check-in binaries that we need, even our own in some instances.
I think this is still relevant, but SVN has historically performed poorly with binaries. A Java developer at IBM ran into this issue, investigated, and wrote up his findings. You might find it useful:
Performance tuning Subversion: Store and handle binaries without the performance drag
-Zachary
Personally I would try to avoid checking in the dependencies of a project into the SCM version control repository. Typically that would be by using Maven as suggested in another answer and deploying a company-internal Maven repository which has the advantage of making this resource local to the development team and to provide a location where your own project's completed/versioned/released artifacts can reside.
The problem I see with Jars being the SCM is that first and foremost, the SCM is for managing the source code and they are optimised for that purpose. Compiled artifacts aren't source code and being binaries, when you typically branch or update the binary you are making a copy of the binary, as most SCMs can't 'diff' a binary file.
Another consideration is what do you do if you have two projects that need dependencies checked in? Do you check in the deps separately into each project and wear the duplication? Or do you make a third project that contains just the dependencies? And now you're manually managing the jar files in that project. What if your two projects require mutually incompatible dependencies?
Third, how do you manage inter-project dependencies (where one of your projects depends on the other one)? Is the jar file from one checked into the other? What about versioning and other change control? Do you just have to have the two projects checked out and require them to be built in strict order?
In my experience and opinion, these problems are usually sufficient enough in a development of only moderate complexity to answer the question definitively: No, it is not acceptable to check in jar file dependencies. Use a build system such as Maven or Ant+Ivy (or another alternative) that provides a way to externalise the management and storage of the dependencies from the source code control system.