How to generate a new source file depending on a condition in TreeVisitor?

[BalusC]

I've a TreeVisitor impl (actually, a XmlVisitor). Once a specific condition is met (a specific XML attribute was rewritten a specific way), then I'd like to trigger the generation of a new source file (actually, a Java source file).

How exactly can I achieve this using OpenRewrite 8.x? All the answers I found on Internet and all suggestions provided by AI say that I should be using doNext(new CreateTextFile(...)) but this 7.x method doesn't anymore exist in 8.x.

I also tried a ScanningRecipe which searches for the rewritten attribute, but it appears to be executed before all normal recipes instead of after, even when I append it as last one in buildRecipeList().

[timtebeek]

To generate a new file you'll indeed want to use a ScanningRecipe; you'll want to adjust your scanning visitor to check the specific condition you're after in the "before" state of your code, and then you can use the generate phase to create a new file, and the edit phase to make further adjustments to your xml file. Hope that helps!

[BalusC]

I could get it to kind of work by returning the same ScanningRecipe in getRecipeList() of every specific recipe. But that in turn causes the ScanningRecipe to be executed multiple times, for each specific recipe, instead of only 1 time. Doesn't seem optimal to me. There could be hundreds of recipes.

[BalusC]

More context: there are already literally hundreds of recipes which rename a specific (namespaced!) xml tag and/or process its children (I already wrote a custom XML recipe base class for this) and/or rename attribute of a specific (namespaced!) xml tag and/or change its value (I already wrote yet another custom XML recipe base class for this). Note that the existing XML/text/find'n'replace recipes are insuitable because they are not namespace aware and are therefore brittle/unreusable when the source project follows a different convention than the "standard" one, e.g. xmlns:pf instead of xmlns:p for PrimeFaces.

Some of them would also like to adjust the Java class associated with a specific attribute value. Let's say one in 10 recipes would like to do that (actually less, but alas). So the idea is to collect all these Java classes by their identifier in a single ScanningRecipe. Only once. And then run all these XML based recipes and have them if necessary set some flag/instruction/whatever to adjust a specific method of the associated Java class. And finally basically run the visitor of ScanningRecipe to perform the desired adjustments.

I guess we ultimately need a new type of ScanningRecipe for this which runs after all the recipes instead of before, and that OpenRewrite collects these ScanningRecipe instances in a Set instead of a List so we can simply use equals to uniquely idenfity them in case multiple recipes return the same instance or even class in getRecipeList().

[shanman190]

I think what you're after is achievable with a single ScanningRecipe, but it does mean thinking about how you'd go about the changes differently.

Some advanced tricks that can help are that you can compose visitors (top level visitor can invoke several in a sequence, then return the final result) and this can also be done by calling getVisitor() on an existing recipe as well to reuse anonymous visitors just as equally (callout: this means that a recipe and a visitor can both stand alone or together). A visitor's context can be anything, such as Atomic* or you can use effectively final variables to capture additional interesting state. There are Trait classes that you could craft to encapsulate some of your conditioning for selecting relevant elements throughout multiple phases.

During the SCAN phase, you'd want to identify the data to change (capture Java classes of interest that will need to be edited, capture Java classes that will need to be created, capture the fact that you'd want to change a namespaced xml tag, etc) and record these within your accumulator of this ScanningRecipe.

During the GENERATE phase, you'd create any of those files that you identified needed to be created.

Finally in the EDIT, phase you'd modify all of the Java files, XML files, etc by delegating by type to inner visitors that could handle the specific changes for each of the specific file types.

As a set examples of recipes in which we take advantage of these more advanced patterns, I'd recommend taking a look at these recipes and their internal implementations to get a feel for some of these compositions that I spoke about earlier:
https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/UpdateGradleWrapper.java (contending with scanning, generating, and editing multiple file types in a single recipe)

https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/UpgradeDependencyVersion.java#L294-L317 (delegating to inner visitors by type)

https://github.com/openrewrite/rewrite/blob/main/rewrite-java/src/main/java/org/openrewrite/java/format/AutoFormatVisitor.java (chaining visitors together to enact many smaller changes as part of a much larger effort)

https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/plugins/AddPluginVisitor.java#L124-L126 (using effectively final atomic classes to capture additional interesting state)

https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/plugins/AddPluginVisitor.java#L171 (expose a custom finder method off of a recipe instance)

https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/trait/GradleDependency.java (example of the Trait API; can be used as a visitor or a predicate)

https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle/src/main/java/org/openrewrite/gradle/AddDependency.java#L258-L259 (visitor reuse)

[BalusC]

Thank you for the examples but I can't tight-couple all these hundreds of existing independent/reusable XML tag+attribute recipes into a single big recipe because only a few of them want to modify a Java class. I would then need to create copies of that single big recipe for each recipelist (e.g. upgrading PrimeFaces from 7 to 15 is split into multiple reusable recipelists: 7 to 8, 8 to 10, 10 to 11, 11 to 12, 12 to 13, 13 to 14 and 14 to 15, which in turn can be re-composed for e.g. upgrading 10 to 14, 8 to 11, etc).

[shanman190]

Why don't we start with a concrete example that way Tim and I can help you build a workable solution rather than speaking about concepts at a meta level?

I wasn't meaning to individually compose each singular component, but there is certainly a higher order recipe that is missing for some specific example(s) that you have and we should be more than able to help build a workable solution. That specific instance probably needs to be a ScanningRecipe that them composes the general purpose XML recipe/visitor alongside an imperative Java recipe/visitor.