Gluster blog stories provide high-level spotlights on our users all over the world
Your code is only as good as its worst library.
|The lamest thing in the world is getting a “NoSuchMethodException” because you deploy an executable which puts the wrong version of the right libraries on the classpath… Or alternatively, because the JVM you are running already has another version of the same library which supercedes your applications required dependency. The more libraries you have, and the more environments you run your code in, the more likely this may be. Solve this problem once and for all by excluding old dependencies in your less-up-to-date jars.|
Ivy is a dependency manager that makes Ant work with maven repositories, transparently managing and accumulating all your jar’s for you, under the hood. The awesome thing about these dependency managers is that they manage transitive dependencies for you, so that you don’t have to worry about the dependencies of your dependencies.
90% of the time this is perfect, — but what happens when you have a transitive dependency that references an old version of a jar, while your source code needs the same library’s updated version ?
Not necessarily in your IDE, but quite possibly in Ant. Or maybe vice-versa. In my case, specifically, I had an old version of commons-io referenced from a jar which my source code depended on. This is a “transitive dependency” (A referenced B which referenced C, making A transitively dependant on C).
So how do you solve these sorts of issues ?
1) Track down the bad jar version by inspecting the javac classpath in ant. This can be done by running ant in verbose mode (ant -v) and simply grepping for the library name. In may case, this meant doing something like this (an old version of commons-io was messing up my compilation step):
2) Once grep confirmed that, indeed, ant was putting an old jar file (that broke my compile) at the beggining of the classpath, I simply had to find out where that jar was coming from. This, again, is easy if you look at the verbose output of your dependency resolution.
3) Finally, in your ivy.xml file, go to the dependency whose transitive dependency is causing the collision. For example, and inside its dependency declaration, add an “exclude” block, which will force ivy NOT to download certain dependencies :
You should now be able to re run your resolve/build step in ant, and this time, the “old” jar won’t stand in the way of your compiler – and you should be able to confirm this by again looking at the output of “ant -v”.
2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...
It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...
The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...