Hi Mario,thank you for the effort. I will try to find time to help with this by
the end of this week. As far as LTS, I think the ideal scenario is to have two
streams, similarly as Quarkus, or JDK. One stable and second one LTS. That
topic is for a separate thread though. Best regards, Tibor
-------- Pôvodná správa --------Od: Mario Fusco <[email protected]> Dátum:
22. 11. 2023 11:30 (GMT+01:00) Komu: [email protected] Predmet: [URGENT]
Finalizing Quarkus 3 migration Hi all,Sorry if I try to rush this, but weeks
and months are passing and we really really need to finalize the migration to
Quarkus 3 asap.Yesterday I created a branch of Drools that bumps it to the
latest Quarkus (3.5.2), see
https://github.com/apache/incubator-kie-drools/compare/quarkus3We're also
discuss this on zulip ( please join the conversation here
https://kie.zulipchat.com/#narrow/stream/381961-drools-dev/topic/Quarkus.203.20migration
) and Alex noted that it would be probably better to migrate to the Quarkus
LTS instead. Personally I'm not strongly opinionated about this, even though I
don't see any relevant reason for us to stay on the LTS. I'd rather prefer to
stay on the latest stable quarkus release, especially for the community
version, and if necessary having a branch for product that is on the LTS
instead. Anyway please also provide your feedback about this and let's take a
definitive decision on it.As you can read in that zulip thread, Toshiya is now
trying to do the same migration for kogito-runtimes, but neither him nor me are
completely knowledgeable on some parts of that project, so please try to be
proactive and help him if necessary.Regarding the migration of the Drools
project, that was not straightforward as I hoped also because the existing
script was made to run against an alpha version of Quarkus 3.0 and however its
nightly build didn't run for the latest 2 months or a little more. For this
reason, and also because I don't want to go through this painfully long
migration process again, from now on I will consider that quarkus3 branch the
drools "effective main" branch. I don't expect any change in the drools code
base in the next days, but if we will have any I will forward port any changes
to that branch.For the remaining part of this email I will list the issues that
I found in the Drools migration and how I fixed them, hoping that this will be
useful also for the migrations of other downstream projects:1. The internal
Quarkus migration recipes have been moved to a different package, see
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL15-R172.
Also the URL of the yaml file used by the Quarkus migration script is
different, see
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL48-R483.
The Quarkus migration also implies a bump of the JavaParser version in use.
The only relevant difference that I found in our code related to this is that
the ClassDeclaration constructor is changed to accommodate the sealed classes
introduced in Java 17, see
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-7d5b9cbee13948b86436fc081410cb6d1a75870617072a40d66c5a6546f612f6L1416-R14184.
The Quarkus classloading mechanism is a little different now. The most
relevant change is that the deployment and augmentation phases are clearly
separated and use 2 independent classloaders. Due to this change I had to
introduce this fix
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR50-R58
that basically performs a lookup of a type of a variable of a rule unit in the
same classloader where the DataSource class has been loaded. Without this fix
the method checking if that type is actually a DataSource (
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR67
) wouldn't work anymore thus preventing the rule unit to be correctly
complied. I honestly don't know if this fix could have some implication
downstream in kogito or more likely if it will have to be propagated somewhere
also there.5. The same Quarkus classloading changes also required a fix in the
kie services lookup mechanism, see
https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-030652eeecd63a0d44385d02b3c362fdda79600785d5e817380daf62e29d3cffL50-R50
Actually there I implemented a hack to make Quarkus 2 to work (it was
necessary to perform the service implementations lookup in the same classloader
of the service interface) and I'm happy that this is no longer needed.My goal
is to have also kogito-runtime migrated to Quarkus 3 before the end of this
week and make those quarkus3 branches our main branches at the beginning of the
next. I understand that this would eventually break other downstream projects,
but I believe that it will be easier to fix them and anyway I don't see any
alternative to push this forward. Please let me know if you have any feedback
or question on
this.Thanks,Mario---------------------------------------------------------------------To
unsubscribe, e-mail: [email protected] additional commands,
e-mail: [email protected]
