Open ppkarwasz opened 5 months ago
Hi @ppkarwasz ; thanks for the offer to help! Agree that we can split these concerns and make each of those available as a separate recipe, with perhaps a combined yaml recipe that executes both for convenience. Naming each of these without confusing users might be the hardest part to all of this, but I'm sure we can work out something there. We'll want to differentiate between the logging backend and the logging API, and ensure folks get results that match their expectations when running a recipe.
The second set of migration rules could be refactored into a separate (and faster) recipe.
If the problem is trying to speed up the recipe running, the bottleneck is not in the recipe running but in building LST to process. So it's not going to be faster.
We tend to gather all recipes together to migrate you to the latest no matter what your starting point is, but people do create their own custom recipes for just a subset of recipes (to help review the changes in parts primarily or to exclude optional changes that they don't like).
What problem are you trying to solve?
The Migrate Log4j 1.x to Log4j 2.x recipe, provides steps that:
The second set of migration rules could be refactored into a separate (and faster) recipe.
Nowadays most applications don't use Log4j API in their code: since 2002 JCL and SLF4J have replaced the usage of Log4j 1 in code almost entirely. However there is a niche of users that kept using Log4j 1 (and its clone Reload4J) as logging backend. These users might be interested in a recipe that only reconfigures their runtime classpath and converts their configuration files.
Describe the solution you'd like
I would like to move the rules that change dependencies from the
Log4j1ToLog4j2
recipe to a newLog4j1ToLog4j2Core
recipe and use the latter in the former.Are you interested in contributing this feature to OpenRewrite?
I will contribute this feature in late Q3 2023, enhanced with a Log4j 1 to Log4j 2 configuration format converter.