3

I have a lot of small-ish Java command-line apps that have to use a vendor set of jars to make their connection to the servers, and while writing these apps has been pretty easy, maintaining them is turning out not to be.

I built them using Maven and some templates that gave me a pretty quick turnaround on development time, but these are all standalone command-line apps so far.

The pain comes from the updates to the vendor servers. Whenever it happens, it forces me to recompile all of these applications with the new jars in play, otherwise I'd get SerialVersionUID Exceptions and borked apps.

What I'm considering

I was thinking that it would be possible to use Maven to generate the app and then throw it in an app server with the server providing a set of shared vendor .jars in whatever /shared classpath it provides. That way I could just update the .jars, restart the server, and everything will likely continue without error.

However, I'm not sure what is required to get that working. They aren't .war's, and most of these apps use other .jars besides my code that isn't usually shared.

Questions

  1. What kinds of deployments work like this?
  2. Are there other ways to do this that I'm missing?
  3. Any tutorials, frameworks, etc., that would make this simpler?
Nick Klauer
  • 5,893
  • 5
  • 42
  • 68

2 Answers2

0

I could just share from my experience. We have 3 ways of overcoming this at the moment. The first way, was our old way, which we still use.

  1. Create a base project which we link to with all our external JARs. The user project when compiled/deployed checks for a newer tag of the base project than it is currently using, and if there's a newer tag, it will fail and force the user to check for the updates and recompile. The benefit of this is that at compile time you can check for new jars, and we get a list of what changed, and reload the jars. In our IDE we can quickly see if anything changed from the API - it has been known to happen, then we can fix and recompile. Also because we're aware of the changes, we can read the changelogs and see if any of the changes affect us, and we then retest parts of the application that depend on these libraries.

  2. We use Maven, but instead of the public repositories, we maintain our own repository, where we only move a library into our local repo after it has been tested - so no surprises for us.

  3. This method is unique to a Tomcat deployment, but we also load libraries via the Context using a classloader. It's not my favorite way to load external jars, but this one works without a deploy. Of course since the compiler isn't there to help you, the new jar can not be 100% compatible with your code, and you can end up with some runtime NoSuchMethodError or ClassNotFoundException expections.

KappaMax
  • 324
  • 2
  • 10
0

I might be misunderstanding your situation, but if the interface you use in the vendor libraries does not change between versions, couldn't you just keep the jar-files in the classpath of your command-line applications and thereby just overwrite the vendor files when necessary? In that way you would only need to recompile when the interfaces change in a way to break your code?

erikxiv
  • 3,965
  • 1
  • 23
  • 22
  • I had tried that initially, but for whatever reason, the vendor must be changing the `serialversionUID`, because the API will not change, yet exceptions are thrown by not matching up. It uses JAX-RPC to make the calls, so it could just be the way that they are or aren't managing their client API. – Nick Klauer Feb 23 '12 at 14:02
  • Well, I guess I'm not knowledgeable enough on serialization. I would've expected that you wouldn't need recompilation to get the new vendor serialversionUIDs as long as the new jar-files were used. – erikxiv Feb 23 '12 at 20:09