Hi Mario, Thanks for the hard work and the lengthy description. Just one doubt, Is there going to be a runtimes PR that we are going to have time to review? I was guessing how we can help Toshiba on that. Thanks again
On Wed, Nov 22, 2023 at 11:28 AM Mario Fusco <[email protected]> wrote: > 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/quarkus3 > > We'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-R17 > > 2. 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-R48 > > 3. 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-R1418 > > 4. 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] > For additional commands, e-mail: [email protected] > >
