0

I maintain a large number of SpringBoot services, built with Maven. There are two transient artifacts where one of them breaks some common rules about jar contents, as it has some fully-qualified classes in that jar that are also in another jar, and that first jar really has no business including those classes. Also, the classes included in the first jar are from an older version, so they definitely cause problems if those classes are used.

There are many services that end up with the same two transient dependencies that have no problem with this, because for some reason SpringBoot decided to put the "good" jar in the BOOT-INF/lib directory before the "bad" jar. However, in one service it makes the opposite choice, putting them in an order that makes it fail to start up. I have no idea what the difference is between these two services that results in that different ordering.

I'm aware of the fact that supposedly I can construct a custom "classpath.idx" file that specifies the order that I want, and I have a different SO posting asking how I can actually do that.

However, I realized that there's another problem I have to deal with. The contents of the "classpath.idx" file specify the full jar file name, which includes the version number of the artifact. These artifacts are transient artifacts of top-level dependencies included in the pom.xml, and it's impossible to tell from the application's pom.xml what versions of those artifacts we will end up with. If I were able to figure out how to put a custom classpath.idx file into the fat jar, I still have to construct it with hardcoded version numbers, which will be a maintenance problem.

I had thought that perhaps the order of dependencies in the application's pom.xml could be used to control this, but I tried moving the "top-level" artifact that pulls in the "bad" jar, to both the beginning and end of the "dependencies" list, but it had no effect on the fat jar.

Is there any practical solution to these problems?

David M. Karr
  • 14,317
  • 20
  • 94
  • 199
  • Do you have an example somewhere... could you exclude the "bad jar" ? – khmarbaise Aug 25 '23 at 18:04
  • 1
    I don't know what would be useful. I certainly can't provide the entire application. There is a "thinclient" jar that is part of the WebSphere distro (we're using v8.5.0) that includes the "javax.el" and "javax.ws.rs" packages (not sure about the exact package name for the second one). These classes are old. If this jar ends up in the classpath order before the more recent artifacts owning those packages, the service fails. – David M. Karr Aug 25 '23 at 18:08
  • 1
    I was actually able to get past this problem, not by finding some way to change the classpath ordering, but by simply creating a new artifact I call "thinclient-minimized" where I simply removed the two problematic packages. For the services that are having this problem, I'm going to tell them to use that artifact instead. – David M. Karr Aug 25 '23 at 18:09
  • I would recommend to raise this with the Spring Boot team via an issue at https://github.com/spring-projects/spring-boot/issues to heat their thoughts on this. – Martin Lippert Aug 28 '23 at 10:12

0 Answers0