ArC - transform unproxyable bean classes by default

[mkouba]

• new transformations: remove final flag from a bean class, change
  visibility of private no-args constructor
• deprecate quarkus.arc.remove-final-for-proxyable-methods
• introduce quarkus.arc.transfrorm-unproxyable-classes
• this should also help kotlin developers where classes are final by
  default

[geoand]

I can't really tell if the TCK failure is related or not... The error is rather obscure. Can you give it a check @mkouba ?

[mkouba]

That's a bug in the TCK: eclipse/microprofile-config#543

We do transform the ConfigObserver class but there is obviously some class loading problem, most probably related to our arquillian adapter.

I think I'll try to disable the transformation for MP Config TCK fow now...

[geoand]

OK, thanks

[geoand]

I like it a lot, +1. The implementation also looks straight-forward but I'll let @manovotn comment on that since this is his wheelhouse :)

[manovotn]

Looks really good, this actually fixes quite a few proxyability cases where we wouldn't pass TCK's exception expectations (deployment versus definition) :-)
Added just some minor questions/remarks.

[geoand]

Github UI is reporting a conflict

[mkouba]

@geoand Yep, just in the middle of rebasing and testing ;-).

[geoand]

Given how much this will improve the Kotlin experience (especially on Gradle where we can't yet propagate the correct plugins to dev mode), perhaps we should backport this to 1.3.x?
WDYT @mkouba @gsmet ?

[geoand]

I am actually thinking that this type of transformation could be applied in other areas that affect Kotlin as well...
That way we will be able to solve a lot of Kotlin issues in the Quarkus codebase itself and not have to rely on glue code in the build tool plugins which we may or may not be able to do (for Gradle we are facing issues that stem from the design of the Kotlin compiler that we obviously can't control).

[manovotn]

perhaps we should backport this to 1.3.x?

I am not working in Kotlin so I cannot say how much of an issue is this. But if it's a biggie then I see no reason not to backport it.

[geoand]

At the moment, Kotlin + Gradle (which is what most Kotlin users use), does not work nice at all in dev-mode.
This PR really improves the situation.

We always knew this, but after actually witnessing this in action I am convinced that this approach is great.

[mkouba]

+1 for the approach but I'm not so sure about backporting. (1) it's a breaking change. (2) we modified a lot of files so it might not be that easy to backport this PR.

[geoand]

I see, in that case if we are not sure about the feasibility of backporting, then I won't insist :)

[stuartwdouglas]

If possible I would like to backport, but I understand that it might not be practical.