[MNG-6829] Replace trimmed StringUtils#isEmpty(String) and #isNotEmpy #183
Conversation
…y(String) Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk Co-authored-by: Moderne <team@moderne.io>
|
shouldn't we have a corresponding SCM- issue rather than MNG- as it's not a core change? |
|
We agreed that it's not cost effective to write tools to create Jira per project with this automation |
timtebeek
deleted the
refactor/replace-any-string-utils-is-empty-string-and-is-not-empty-string
branch
Fine. but where is this agreement? Do you know if something was talked about it on a mailing list? |
|
Hi @olamy ; Thanks for voicing your concern with regards to consistently tagging issues with an appropriate Jira ticket as per the project. It's a valid concern, and it's come up before; I'll link to a few earlier discussions here.
I'll give a bit more context about these changes here, as I don't think we've met before. I work on OpenRewrite, which allows folks to make safe automated code changes. Together with the Moderne platform, that allows me to apply changes broadly with ease. I'm using these two tools to for instance work on
There's a few others I'd like to tackle in the future with automated changes, such as for instance
All of these are small individual changes, that have often been applied to a subset of projects already, some by hand, some with tooling support. But given that there's some ~90 Apache Maven repositories, you'll find projects in various states. What I hope to do is lift all projects up to a common consistent state, such that they are all easier to maintain going forward. As per an earlier request I'm pushing frequent small PRs such that they are easier to review & troubleshoot if ever needed. That does mean a lot of PRs will be created, especially when replacing individual Plexus/Shared/Commons utilities methods. The parts that are automated right now are making the code changes, and creating PRs through the Moderne platform, both of which already existed before this effort. There's no easy way to hook in Jira issue creation right now, and for a lot of these changes an issue per project would only amount to as much as the PRs title & body already contain. That's why in the earlier discussions we'd arrived at using a common issue across projects for reference, such that they are all linked back to a single effort across many projects. Does that help put the above changes into context? And would you then agree with us continuing in the manner? |
|
@timtebeek I'm definitely fine with doing so for such trivial changes BUT this need to be agreed/recorded somewhere on a mailing list so nobody will get back on this complaining about the lack of Jira for this. |
|
@timtebeek Just assign me as a reviewer on any PR you want me to look at. Otherwise I'm likely to miss them. Of course, it's 100% fine if someone else reviews and merges these first. |
|
Thanks all! I'll resume creating PRs, create issues for new overarching themes, and use my best judgement when a change grows beyond trivial for a particular project. |
Additional replacements as compared to #169, now also replacing where the input was trimmed.
@elharo would you mind having look at this one and a few to follow? I want to start this up again. :)