Hi, > 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.
PR is https://github.com/apache/incubator-kie-kogito-runtimes/pull/3290 As written in the PR comment, there are still several test failures. I'm not yet sure if they (or some of them) are caused by my local environment (RHEL 8, JDK17). Any help and thoughts would be welcome! Cheers, Toshiya On Thu, Nov 23, 2023 at 1:03 AM Francisco Javier Tirado Sarti < [email protected]> wrote: > 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] > > > > >
