Library upgrades: Must I include both versions of the library in the recipe jar?

[crankydillo]

Hi, I know you have this doc on the topic. However, it talks a lot about tests. I want to make sure that these should go into src/main/.. and should be available at runtime in order to provide appropriate types. I know I can test, but hopefully this will be useful for others/tidy up doc/etc:)

Currently, rewrite-spring has a lot of these embedded.

Let's say I'm upgrading a Maven project that has lib-a:1 to lib-a:2. I'll primarily be doing 2 things:

1. Changing the GAV in pom files.
2. Changing code to address breaking changes (we'll ignore adopting to new backward-compatible APIs)

Are lib-a:1 and lib-a:2 generally supposed to come from before-after pom states such that code-rewriting will have appropriate types (both old and new)? Or do I need to include one or both of these in src/main/.. of my upgrade recipe?

I get why this might be needed in a recipe test (where we don't care that it's going to be used in a Maven project), but I'm a little hazy on this applies in a 'real' environment. Both the doc and rewrite-spring make me think these need to be there. What we've been doing for test purposes is to put these into src/test/resources/META-INF/.

[crankydillo]

I did search your slack for this:) Only found this.

[timtebeek]

hi! In short the .jars need to be added to src/.../resources/META-INF/classpath only when referenced from a JavaParser call to classpathFromResources, either from a unit test, or in a JavaTemplate. classpathFromResources specifically (as opposed to classpath(...) ) is only necessary when there could potentially be multiple major versions of a framework or library supported at any one time. So for Spring Boot we support v1, v2, and v3 in parallel, while we need all three of those for recipes and tests across all of those major versions. Elsewhere we might leave out the classpath resources if not immediately needed.

In your case you will likely want to .classpath(...) as much as possible, especially for your tests, just for simplicity. The .classpathFromResources is safest for use with JavaTemplate when you conceivably expect to support multiple major versions. You can then also leverage those for tests, if you want to have tests in the same source set verify against different major versions. If you use separate source sets then src/test/resources/META-INF/classpath might not be necessary.

/cc @mike-solomon to maybe add some of the above to the docs.

[crankydillo]

In short the .jars need to be added to src/.../resources/META-INF/classpath only when referenced from a JavaParser call to classpathFromResources, either from a unit test, or in a JavaTemplate.

So in my case, let's say I have LibA1to2Recipe, and it uses JavaTemplate directly, then I'd need add lib-a:1.0.0 and lib-a:2.0.0 in that module that contains LibA1to2Recipe?

I guess the thing I'm trying to understand is the Java-based upgrade recipes often work with types, right? Those types have to come from somewhere. If they aren't embedded in the recipe, they must be coming from a before-after pom change..

Regardless, I suppose we can figure it out as we go:). I can look at rewrite-spring a little more closely.

[timtebeek]

in your LibA1to2Recipe I'd only expect you to have to add lib-a:2.0.0 to the parserClasspath, as the type information for v1 would already be provided by parsing your target project with Maven or Gradle. It's when you insert new LST elements from v2 that you need that new dependency available through classpath resources.