Speed up Flyway by preventing it from doing classpath scanning

[geoand]

This PR essentially takes the substitution we had for native mode
and turns it into a class transformer.
This way even in JVM mode our Flyway integration take advantage of
the fact that the migration script locations are known at build time,
thus no classpath scanning is needed.

This solution isn't ideal from a maintenance perspective, but the
transformation is relatively straightforward and our test suite for
Flyway pretty extensive, so we should easily be able to adapt to future
Flyway updates (ideally we would be able to remove this if /when
flyway/flyway#2822 is done)

Relates to: #9428

[geoand]

It seems like our QuarkusPathLocationScanner doesn't work well on Windows, so I'll have to fix that as well.

[geoand]

Windows issue fixed - PR is now ready

[Sanne]

hum.. it's a cool approach but it bothers me to set such a precedent.

Do we really want to "hot patch" libraries this way? If they are bad let them be bad.. or have them accept a patch?

I suppose there might be situations in which projects aren't reactive while we need a critical fix, but I'd rather us consider forking a project in such a case.

Did you send a PR? At least give them a chance..

[geoand]

@Sanne I share your concerns. I definitely wouldn't have done it had there been a better way.

Here is the ticket I opened at Flyway, but so far no response. I don't want to submit a PR there until they at least agree that it's something they want.

The reasons I went ahead with this PR here are:

1. It's a relatively small monkey-patch that we can very easily take away when we have proper upstream support
2. We can move so much faster than upstream
3. We have people complaining about Flyway being slow :)

[Sanne]

We have people complaining about Flyway being slow :)

Have people complain / contribute fixes to Flyway ? Are we going to fix and improve any project we integrate with?

[geoand]

Of course we can't fix everything, but some commonly used things we can, wouldn't you agree?

Moreover, this isn't just a simple speed up, it's, it brings the advantages of our powerful build time processing to the integration with a popular library.

[geoand]

I also need to mention that this monkey patch is the same one we already use for the native image.

[Sanne]

Sure, good points @geoand . Don't take my comments as a negative review - just don't be surprised if you'll have to fix more bugs this way going forward :-P

[geoand]

I completely understand @Sanne and I definitely appreciate the scrutiny 👌

[gsmet]

I'm leaning towards backporting this to 1.5 Final. @geoand WDYT?

[geoand]

It's should give a nice speed boost and given our extensive Flyway testsuite, I think it's safe

[sirAlexanderT]

Thanks @geoand for pushing this forward as I can see 'flyway' aren't being as responsive

[geoand]

You are welcome