Fixed the whiteline removal for the schemaLocations when already properly migrated

[Jenson3210]

Added some preconditional approach to the oldValue using regexes.

I am not sure though if this change is worth the "win" of not seeing the change happening.

Before this PR,

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
          https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
         version="6.0">
    <display-name>Unit testing</display-name>
</web-fragment>

Would be migrated to

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
         version="5.0">
    <display-name>Unit testing</display-name>
</web-fragment>

to than later be migrated back to version 6. (notice the newline diff resulting in the end causing unneeded reviewable change)

[Jenson3210]

@timtebeek As I mentioned above: not sure if we would even want this change. Introducing a bit "heavier" oldValue regex checks just for this purpose seems odd, no?

[timtebeek]

I think it's tolerable to have this change. optionally with a little less stringent prefix pattern on that particular faces 4 recipe.

[timtebeek]

This is where I wonder if for clarity (and less chance of mismatches) we can use a simpler pattern of replacements.

Suggested change

	oldValue: (?<prefix>https://jakarta\.ee/xml/ns/jakartaee\s+https://jakarta\.ee/xml/ns/jakartaee/web-app_)5_\d+(?<extension>\.xsd)
	oldValue: (?<prefix>.*https://jakarta\.ee/xml/ns/jakartaee/web-app_)5_\d+(?<extension>\.xsd)

[timtebeek]

A character group of [\S\s] would just mean anything right? Then .* feels more intuitive.

\s	A whitespace character: [ \t\n\x0B\f\r]
\S	A non-whitespace character: [^\s]

[Jenson3210]

.* does not match on \n where \s\S will match on these newline variations also. I did not get it to work with .* and the added unit test/newlines.

[timtebeek]

Ah guess that would require a multiline flag to be added; in that case we can go with this option, or prefix the regex with (?m) to make it explicit that we tolerate multilines as well

[Jenson3210]

the multiline, I indeed also tried.

That would work if we do not expect the entire string to match. That matches the line (so as of the newline) that matches the string, not the entire value.
I did find that the dotall flag does match the entire surrounding values.

[timtebeek]

Any reason you'd held off on a merge here @Jenson3210 ?

[Jenson3210]

Nope 🫣