Thread: Jar Versioning with Eclipse

Hey guys,

My ultimate goal is to configure Java Webstart to download the newest version of a Jar instead of using the cached one. I'm pretty sure this is as simple as including a version number in the Jar's manifest.

My question is, how do I do that with Eclipse? I usually just do File > Export > Runnable Jar, and that has worked in the past (including with webstart, but without version updates). I can't find anywhere in the project properties window or in the export window to specify a version, but that seems like a pretty obvious thing to specify.

Any ideas?

Thanks in advance,

KevinWorkman

Do you mean something like the version control defined within the jnlp spec? Check out the following page to see if versioning in the JNLP might solve your issue...
Avoiding Unnecessary Update Checks (The Java™ Tutorials > Deployment > Deployment In-Depth)

That does look really promising, but it has one major drawback: now, my approach is to host one runnable Jar file, then link to that file for the applet, webstart, and runnable jar versions. So I'd rather not have to change the link to the Jar everywhere, plus I'd have to either host all old versions or risk breaking links upon update.

I thought there was a way to specify the Jar's version in the manifest, and I was hoping that webstart (and in a perfect world, applet, but I'm not holding my breath) would check that version and re-download the Jar when necessary.

I'm going off a few tutorials, this being one of them: Java Web Start (scroll halfway down to the "Versioning in Java Web Start" section. I might just be misunderstanding how things work.

I'll play with your suggestion later (I'm at work now, this is for home stuff), but I was hoping for something that's internal to the Jar, or at least doesn't require changing its name.

That is interesting though. I didn't know about that until now. Thanks.

Edit- Actually, the tutorial I linked to might be saying the same thing as yours, only less clearly. Gah. I could have sworn there was a way, but maybe I'm out of luck. I have some pretty annoying issues where I update the Jar on the server, but then clients continue to see their old cached versions (and telling them to clear their cache would make kittens cry). I've been looking for a way around this, and thought I was on to something with the webstart thing. Shucks.

I'm not sure if you could do this through the manifest (but I could be wrong). Since the cache is client side, it will see if it has the same named jar from the same source and if so load that puppy. Since the versioning above changes the name of the jar, there shouldn't be a cached version and it will download that one. You could look into seeing if there is a no-cache protocol (although that means longer download times). Alternatively, you might want to look into creating an ANT task build script that would automate this all for you - in which case you run the build script which will create your jar and jnlp with the appropriate versioning, which you then load to the server (the upload of which could also potentially be just another step in the ant build script as well).

Yeah, that's what I was afraid of. I've tried the no-cache approach, and if it worked, it would be perfect since very few of my programs take any time to load at all- actually, I tried that with a problem with HTML in Swing components not rendering properly in cached versions (remember?), but I had problems with clients simply ignoring that.

Anyway, it's a problem I've been looking for a solution to for quite some time. I'd like to find a way that didn't involve changing the Jar name, half for my own sanity and half to not break links I post to it on forums, etc. But it's not the end of the world either way, I suppose. Thanks again for the input though, I know next to nothing about deployment and web stuff.