Should we store JRE in CVS/SVN?

Question

I want to bundle JRE 6.0 together with my java application. All my source code reside in CVS. My client will check-out the code and build it themselves. Should I store JRE in CVS?

Answer 1

I normally advocate putting most everything in source control, but this seems a little excessive. Why ?

1. the JRE is readily available from http://java.sun.com
2. it doesn't change that often. I'd expect you to specify a minimum version for your code to run against (e.g. 1.5, 1.6 etc.)

Answer 2

I see nothing wrong with storing the JRE in CVS.

However, it's not so important whether you do or not as long as your script can pull it as part of the build. For example, if you want to host a downloadable jre.zip on an HTTP server, or point to it in a Maven repo, that's just as good.

Answer 3

Well won't your client all ready have the JRE if you expect him to compile the code before running it? The JDK contains the JRE.

Answer 4

As best practice, you shouldn't keep any binary files in the source control system. For Java developers there is maven that does it's work better in versioning jar files. The reason is that we want to keep our source repository as small as possible so it is faster for those that checks out our code for the first time.

But if you still want to keep binary files in the source control, it would be best to avoid using CVS, because CVS is bad in versioning binary files. You can search with google, why it is bad. If you use SVN, then it still okay because SVN handles binary files much better than CVS.

Answer 5

I would not put a JDK or JRE into a source code repository:

• It is bad practice to put externally versioned things into your version control because it usually leads to over-constraining, obscuring and/or hard-wiring your app's external dependencies. (Maven or Ivy are good solutions for dealing with external dependencies, though not in this case,)
• Putting binaries into version control is a bad idea for some version control systems.

But I think your real problem (actually, your user's organization's problem) is the IT folks who refuse to contemplate upgrading the JRE:

• They need to be made aware of the fact that they can install multiple JRE versions on the one machine, and configure apps to launch with the JRE version they require. (It is trivial on Linux ...)
• They need to be made aware of the fact that their policy is an impediment to progress.
• They need to be made aware of the fact that their policy is a potential security issue. If they force users to deploy their own copies of JDKs / JREs in random places, it will be difficult to ensure that JRE security patches get applied. (Besides, 1.4.2 is due to be end-of-life'd soonish, and security patches for it will cease.)

EDIT: and there is also the legal question of whether "redistributing" a JRE out of your source code repository is a violation of Sun's click-through JRE/JDK download license. (I don't know ...)

Answer 6

Depends a lot on what you use to handle dependencies. If you use Maven, then create a maven package with the stuff you need, and host it on a local repository.

If you just have CVS (like we do) then it is fine to create big binary packages (since you will need them) which you can then put in CVS. Just be aware that they should be static for best CVS performance.

ALso note that the jsmooth package can create an EXE file of your jar with an JRE embedded in it. This might solve your deployment problem.

For remote compilation, Eclipse can work with a plain JRE. You just need to tell Eclipse where JRE you already have prepared above is located on the disk. There is also a folder inside the Eclipse distribution where the launcher looks automatically.

Answer 7

I'm wondering about the client building the application themselves. It will require some kind of Java compiler, most probably javac wich is part of the JDK. So your client will not only need a JRE, but a JDK as well (unless they will be using Jikes or another alternative compiler).

javac is capable of generating bytecode for previous versions of Java, so using a newer compiler should not pose any problems.

Personally, I would not include large binaries like a JRE as part of my own repository. The JRE can be considered very stable and just listing the minimum version required should be enough. Installing a JRE is also something quite different than installing a single Java application. The two activities should not be mixed.