+1 for that from me too. Sounds reasonable. Tibor
-------- Pôvodná správa --------Od: Jason Porter <lightguar...@apache.org>
Dátum: 22. 11. 2023 17:10 (GMT+01:00) Komu: dev@kie.apache.org Predmet: Re:
[URGENT] Finalizing Quarkus 3 migration I like Alex's approach to sticking to
LTS for now and having a larger discussion later.On 2023/11/22 14:25:25 Alex
Porcelli wrote:> Mario,> > In my opinion we, as a community, should avoid
trying to to be on the> cutting edge of any external dependencies/runtimes.
Being on cutting> edge forces constant alignment burning a lot of dev cycles to
just> keep up. The same cycles could be better invested in the project's>
features and stability.> > By adopting LTS versions of external dependencies,
we have more> previsibility, stability and security (less CVEs!!).> > Based on
the above, I really would prefer that we always take the LTS> approach in
regarding any external dependencies.> > Of course, there’s going to be cases
where to implement something we> may need a cutting edge feature of an external
dependency, but I’d say> this should be the exception not the norm… and would
be better> discussed case by case.> > I'd like to suggest that, to avoid a
contentious topic for now, we> stick with LTS and once we have a release out we
start discussing LTS> and cutting edge in possible different streams.> > On
Wed, Nov 22, 2023 at 7:04 AM Pere Fernandez <pere.fernan...@gmail.com> wrote:>
>> > 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 <tibor.zima...@gmail.com> 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 <mariofu...@apache.org>> > > Dátum: 22. 11. 2023 11:30
(GMT+01:00) Komu: dev@kie.apache.org 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: dev-unsubscribe@kie.apache.orgFor additional> > >
commands, e-mail: dev-h...@kie.apache.org> >
---------------------------------------------------------------------> To
unsubscribe, e-mail: dev-unsubscr...@kie.apache.org> For additional commands,
e-mail: dev-h...@kie.apache.org> >
---------------------------------------------------------------------To
unsubscribe, e-mail: dev-unsubscribe@kie.apache.orgFor additional commands,
e-mail: dev-h...@kie.apache.org
