Skip to main content

Maven and Legacy Projects

Recently I've been helping a colleague introduce a dependency on a legacy project that hasn't been "Maven-ized". Often the "easy way" to add a legacy dependency is to throw the JAR into our Nexus repository and be done with it. But this legacy project was a little trickier and is my new poster child for why taking the easy way can lead to headaches and frustration.

Your legacy project might have compile-time dependencies you need.
Maybe your legacy project implements an external API, or maybe it uses a library and exposes that usage in its API. "So what", you say? "I'll find it at compile-time for my project and I'll add the dependency." Well, now every project that wants to use your legacy project is going to go through the same discovery and embed the dependency in their POM. The right way is to define this dependency in the pom.xml for your legacy project so all dependent projects retrieve it transitively.

Your legacy project might have run-time dependencies you need.
Similar to the last example, your legacy project might use a library but not expose it's use directly. You won't discover the missing dependency until you try and run your project. Here's where the power of the 'runtime' scope of a transitive dependency becomes obvious.

Your legacy project might include library classes within its JAR.
Now here's a real yuck factor when it comes to dealing with other people's code. Our example legacy project bundled a small subset of its dependencies right in its JAR. It wasn't until after we threw it into Nexus that we discovered this rather severe violation of Maven standards. The best solution, get access to the project's source, mavenize the project properly and release a 'pure' artifact. If you don't have access to the legacy project's source you'll need to strip the extra classes from the artifact and construct a pom that includes the right dependency.

Summary
So here's a really quick summary of why not to half-ass adding legacy projects into your Maven infrastructure:
  • Any transitive dependencies will be missing.
  • With legacy jars that embed the classes they depend on you risk class file collisions

Comments

That colleague must have been a real n00b!

Popular posts from this blog

3D Photo Viewer for Looking Glass

The Looking Glass I created my first Chrome extension, which is now live on the Chrome Web Store ! It's built for the Looking Glass , a holographic display that let's you view three-dimensional objects without glasses. I've also opened the source to the extension on GitHub. The Chrome extension allows you to view Facebook's "3D Photos", a feature they added in 2018 for displaying photos that include a depth map like those from phones with dual cameras, such as Apple's "Portrait Mode". Getting Started To use the extension, connect your Looking Glass to your computer, navigate to Facebook and open the viewer from the extension's popup menu. This will open a browser window on the Looking Glass display's screen in fullscreen mode. Opening the Viewer Once the viewer is open, the extension watches for any 3D Photo files being downloaded, so browse around Facebook looking for 3D Photos.  I recommend some of the Facebook groups de

Simplifying logging with Maven and SLF4J

UPDATE: Ceki commented below which prompted me to rewrite the third paragraph. UPDATE 2: I have a better way of configuring Maven and SLF4J now. The mismatch between logging frameworks always seems to come up in projects I've developed over the years. Little-by-little I've learned and relearned how to navigate the nest of runtime logging that occurs in non-trivial applications. With my latest project I think I finally converged on a solution that I'll carry forward to future projects. So what am I really talking about? Have you ever been stumped, even for a short time, about where a certain log message is going and why it might not appear in your log? Often this happens when you are trying to debug an issue with a third-party library that's using a different logging implementation them your application. If you are nodding from familiarity, skip the next paragraph. Let's start from the beginning. There are several logging implementations available for Java, th

Maven for Ant Users

My coworker asked me to describe how Maven compares and differs to Ant. I realized how hard it was for me to describe what a developer gets for moving their build process from Ant scripts to Maven. I can't make the argument that you can do X with Maven but not with Ant because I don't really have a valid example. However, I am inclined to make the argument that you can do X with both but with Maven it's easier. With Maven, you collect metadata about your project instead of writing scripts defining the steps your build will take. For example, if you look at an Ant script you'll immediately see that it is organized as targets which many developers use to define and group the steps of their build process. In a Maven POM file, you won't see similar build steps defined. This can be confusing for a new Maven user coming from the world of Ant. I know it was for me. Instead, you'll see lots of metadata about the project such as dependencies, Maven plugins to us