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]
