2

Dears,

We are migrating a legacy project from ant to maven.

There are a lot of dependencies, and we would like to do a clean up of them.

This question (especially the first comment) does raise some worries...

It's a big project with usage that differs throughout the calendar year and we don't have a lot of test coverage, so 'just running the tests' is something we can't do.

If the project compiles, with maven, and deploys, are there ways for it to fail at runtime?

If so, are there ways to mitigate this 'somehow'?

Thanks for thoughts and insights, all input is greatly appreciated...

SanThee
  • 2,301
  • 3
  • 23
  • 35
  • If you're concerned about runtime dependencies, [build a fat JAR](https://stackoverflow.com/questions/19150811/what-is-a-fat-jar) – Michael Nov 15 '18 at 11:02
  • Well, any build tool such as maven, ant or even gradle can result in runtime problems, especially with the classpath. In most cases it's a matter of missing, duplicate or just wrong versions of libraries and how those are handled depends a lot on your project and how you use the build tool. If an application compiles successfully that would mean that the dependencies are on the compile classpath but that doesn't have to mean they are on the runtime classpath. If the application can be started successfully then most likely not all libs/classes have been loaded, so that's no guarantee either. – Thomas Nov 15 '18 at 11:03
  • The most important thing is to have good tests which shows things like missing deps etc. If you don't have you need to do it manually...and there is no other way to go.... – khmarbaise Nov 15 '18 at 11:25

2 Answers2

1

For the economy of this conversation, let's suppose there are no existing bugs.

What things can break in an unpredictable way?

  • Even if you are able to compile the project, you will never be 100% sure that you have migrated everything correctly. Default values may not be handled in the same way with Ant and Maven. So, you may have used a dependency (transient or not) that works in a slightly different way than your original.
  • Maven is way more standardized than Ant and this means that you will not always be able to do exactly the same in Maven and Ant. Ant may use a script, while Maven may use a plugin which you have no control on. This can lead to different behaviors on your application.

What can you do to remedy the problem?

  • Invest some time and write some integration tests, at least the happy path, plus a couple of common red paths.
  • Test, test and test. Manual testing can reveal unexpected behavior.
  • Roll-out your new version gradually. If you deploy your solution to plenty of servers, try deploying first only at one of them and monitor for anomalies. If you can spin-up a new server and only feed a little traffic there (e.g. 5%), to monitor for bugs using real data while not massively compromising your availability, you should do that too.

Always keep in mind that migrations come with a risk. Also, this is probably a good reason to embrace unit and integration testing from now on. :)

Sofo Gial
  • 697
  • 1
  • 9
  • 20
  • 1
    I choose this as the 'best' answer, of course because it's a 'good' answer, but the other one as well, but it's the 'best' because it gives us a strategy we can actually apply, I can not give all the details but enjoy :D – SanThee Nov 15 '18 at 14:27
1

Yes, there are multiple ways any project that compiles can fail during runtime e.g. by running against different library versions.

At the very least you must compare the output artifact because at the end of the day both Ant and Maven build a deployable artifact: WAR or JAR with dependencies. Check the library versions in both, it's very likely that they will be different because Ant doesn't handle dependency resolution (unless you used Ivy).

Karol Dowbecki
  • 43,645
  • 9
  • 78
  • 111