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:
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