Thank you Mario for triggering this! I will try to get some time this week to take a look into kogito-apps, I'm pretty sure those patches will require a lot of changes...
On Wed, 22 Nov 2023 at 12:01, Tibor Zimányi <[email protected]> wrote: > 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]
