HI all, The upgrade to Quarkus 3.20 has not been fully concluded yet, as `kie-tools` is still pointing to its dependency repos (drools, optaplanner, kogito-runtimes, kogito-apps) using commits from 2025-05-11 (still on Quarkus 3.15). The need `kie-tools` had for timestamped SNAPSHOTs to be published somewhere has been lifted in this PR (https://github.com/apache/incubator-kie-tools/pull/3170), thus allowing us to have more flexibility and control over when to upgrade, and which commit hashes to use for each repo. It's also one less automation for us to maintain ("weekly" jobs for producing timestamped SNAPSHOTs on Jenkins can be deleted now, as far as I'm concerned.)
In order for us to move to newer commits of the dependency repos to upgrade `kie-tools` to Quarkus 3.20 (LTS), however, we need to solve a historical problem we've been dragging along for a while now–JIT Executor's native builds. The whole reason we have it was to enable users to use KIE Sandbox with static validation and DMN Runner capabilities without needing to install and/or manage Java or any other tools locally, so we started releasing native binary versions of Extended Services (KIE Sandbox's "backend", which embeds JIT Executor) for all three major operating systems on each release. Although we were able to manage the complexity of building those binaries overtime, it wasn't without challenges and many hours spent to try and continue providing this convenient distribution of Extended Services. Important to mention is that on 10.0.0, Extended Services native binaries for macOS and Windows were not correctly published due to a problem in the release pipelines. With `kie-tools` moving away from timestamped SNAPSHOTs and building its dependent repos ""locally"" during its builds, compiling native binaries for Extended Services becomes impractical, as native binary builds take a non-negligible amount of time, and require a somewhat complicated local setup for it to succeed. For that reason, I propose we take the following action items: 1. (blocker for Quarkus 3.20) Update KIE Sandbox with instructions for users to run Extended Services as a Container image instead of downloading and running Extended Services' native binaries (thus requiring users to have a local Docker installation, as already suggested to users here [1]); 2. (blocker for Quarkus 3.20) Delete `packages/extended-services` on `kie-tools`. (which depends on native binaries of JIT Executor to be available from apache.snapshots, Maven central etc); 3. (cleanup) Update our release jobs not to trigger any JIT Executor-related jobs on GitHub actions anymore; 4. (cleanup) Delete GitHub Actions workflows to build/upload JIT Executor native binaries on `kie-tools`; 5. (cleanup) Delete `jitexecutor-native` modules on `kogito-apps`; 6. (cleanup) Delete "weekly" jobs to publish timestamped SNAPSHOTs 7. (optional, future) Try and find out how to use Apache's infrastructure to have Extended Services running somewhere so that KIE Sandbox can point to it, allowing users to use DMN Runner and static validations on KIE Sandbox without running and managing anything on their machines. Making 1. a fallback solution for when this Extended Services deployment might become unavailable for any reason; Solving 1. and 2. would be required for us to be able to move forward with `kie-tools` and upgrade it to Quarkus 3.20. Looking forward to hearing your feedback on the above. Regards, Tiago Bento [1] https://kie.zulipchat.com/#narrow/channel/232659-general/topic/.E2.9C.94.20Issue.20with.20Sandbox.20Extended.20Services.20downloads/with/509959779 On Sat, May 31, 2025 at 4:27 PM Tiago Bento <tiagobe...@apache.org> wrote: > > Ricardo, > > Probably not brand new information as some people are already looking into it > AFAIK, just wanted to raise awereness in a more general sense, since Quarkus > has picked up a good pace in releasing often, so this kind of upgrade will be > a recurrent task for us. > > Regards, > > Tiago Bento > > On Fri, May 30, 2025 at 17:54 ricardo zanini fernandes > <ricardozan...@gmail.com> wrote: >> >> Tiago, is this additional information, or are you replying to my previous >> email? >> >> Cheers! >> >> On Fri, May 30, 2025 at 1:11 PM Tiago Bento <tiagobe...@apache.org> wrote: >> >> > Timestamped SNAPSHOTs have not been published for the last two weeks, >> > potentially impacting the Quarkus 3.20 upgrade on `kie-tools`. A new >> > timestamped SNAPSHOT publish job will be automatically triggered this >> > Sunday, but if it fails we'll need to understand why it's failing and >> > fix it so that the Quarkus 3.20 upgrade can be considered complete. >> > >> > On Fri, May 30, 2025 at 12:14 PM ricardo zanini fernandes >> > <ricardozan...@gmail.com> wrote: >> > > >> > > Hi Tibor, >> > > >> > > Additionally, I think I mentioned to you that now our CI is breaking due >> > to >> > > Keycloak devservices issues in tests. Can you please take a look? I >> > > believe we should disable these services since they are enabled by >> > default >> > > by Quarkus 3.20 IIRC. >> > > >> > > Cheers! >> > > >> > > On Wed, May 28, 2025 at 1:22 PM Tibor Zimányi <tzima...@apache.org> >> > wrote: >> > > >> > > > Yes, makes sense. Thank you Pere for noticing this. >> > > > >> > > > Best regards, >> > > > Tibor >> > > > >> > > > Dňa st 28. 5. 2025, 19:09 Pere Fernandez <pere.fernan...@gmail.com> >> > > > napísal(a): >> > > > >> > > > > Hi @Tibor (and all), >> > > > > >> > > > > I did a quick test today and I got a warning during startup regarding >> > > > some >> > > > > of our Config classes we are using in our extensions / addons. IRC >> > > > > since Quarkus 3.15 Quarkus started deprecating the @ConfigRoot >> > > > annotations >> > > > > we are using in our configs in favor of Smallrye. So far everything >> > works >> > > > > fine because they keep backwards compatibility (we are using a >> > specific >> > > > > flag in our extensions to enable the legacy mechanism) however it >> > would >> > > > be >> > > > > nice if we migrate to the new mechanism. >> > > > > >> > > > > Some of the affected configs are: >> > > > > >> > > > > - org.kie.flyway.quarkus.KieFlywayQuarkusRuntimeConfig >> > > > > - org.kie.kogito.index.addon.config.DataIndexBuildConfig >> > > > > - org.kie.kogito.index.addon.config.DataIndexRuntimeConfig >> > > > > - org.kie.kogito.index.addon.config.DataIndexUIClientRuntimeConfig >> > > > > - >> > org.kie.kogito.job.http.recipient.JobHttpRecipientRuntimeConfiguration >> > > > > - >> > org.kie.kogito.job.sink.recipient.JobSinkRecipientRuntimeConfiguration >> > > > > - org.kie.kogito.quarkus.config.KogitoBuildTimeConfig >> > > > > - org.kie.kogito.quarkus.config.KogitoRuntimeConfig >> > > > > - >> > > > > >> > > > > >> > > > >> > org.kie.kogito.quarkus.workflow.deployment.config.KogitoWorkflowBuildTimeConfig >> > > > > >> > > > > I raised this ticket >> > > > > https://github.com/apache/incubator-kie-issues/issues/1983 to fix >> > it. >> > > > I'll >> > > > > try to find time to tackle it during next week. >> > > > > >> > > > > Cheers! >> > > > > >> > > > > >> > > > > On Wed, 28 May 2025 at 16:17, ricardo zanini fernandes < >> > > > > ricardozan...@gmail.com> wrote: >> > > > > >> > > > > > Thanks Tibor! >> > > > > > >> > > > > > On Wed, May 28, 2025 at 7:10 AM Tibor Zimányi <tzima...@apache.org >> > > >> > > > > wrote: >> > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > the PRs for drools, optaplanner, kogito-runtimes, kogito-apps and >> > > > > > > kogito-examples were merged. I will continue with kie-tools when >> > > > there >> > > > > > is a >> > > > > > > new weekly build of the libraries. >> > > > > > > >> > > > > > > Best regards, >> > > > > > > Tibor >> > > > > > > >> > > > > > > On Mon, May 26, 2025 at 10:23 AM Tibor Zimányi < >> > > > > tibor.zima...@gmail.com> >> > > > > > > wrote: >> > > > > > > >> > > > > > > > Hi, >> > > > > > > > >> > > > > > > > I resubmitted the PRs for the Quarkus upgrade. There is one >> > problem >> > > > > > with >> > > > > > > > serverless workflow test yamls. Some of those contain a field >> > > > > > > > "lastTransitionTime", like here (1). There is a current fabric >> > bug >> > > > > > around >> > > > > > > > this (see the link in the comment). How important are those >> > > > datetime >> > > > > > > > fields, please? Because the tests pass without those. Can >> > someone >> > > > > from >> > > > > > > > serverless take a look at those problems? I tried to override >> > > > > > > > kubernetes-client to 7.2.0, however that doesn't work as >> > Quarkus >> > > > uses >> > > > > > > > 7.1.0. >> > > > > > > > >> > > > > > > > Best regards, >> > > > > > > > Tibor. >> > > > > > > > >> > > > > > > > (1) >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > https://github.com/apache/incubator-kie-kogito-runtimes/pull/3935/files#diff-df1637d3c414626b6682e77385559f33418b41f02c0ea46a6c472699a270bf1dR57 >> > > > > > > > >> > > > > > > > On Tue, Mar 25, 2025 at 7:00 PM Luiz Motta <ljmo...@apache.org >> > > >> > > > > wrote: >> > > > > > > > >> > > > > > > >> +1 >> > > > > > > >> >> > > > > > > >> On 2025/03/24 09:53:01 Tibor Zimányi wrote: >> > > > > > > >> > Hi, >> > > > > > > >> > >> > > > > > > >> > Quarkus 3.20.x should be a new LTS stream of Quarkus. I see >> > > > 3.20.0 >> > > > > > > >> > artifacts already public, however there is still no public >> > > > > > > announcement >> > > > > > > >> > yet. Based on this, I think the release is imminent. >> > Therefore I >> > > > > > > >> propose to >> > > > > > > >> > start working on the upgrade so it is prepared as soon as >> > > > possible >> > > > > > > after >> > > > > > > >> > the Quarkus release. >> > > > > > > >> > I know we are in the middle of the 10.1 release work, so I >> > asked >> > > > > one >> > > > > > > of >> > > > > > > >> the >> > > > > > > >> > people in the IBM team contributing to KIE (Ann Joy) to >> > take a >> > > > > look >> > > > > > at >> > > > > > > >> the >> > > > > > > >> > work currently, to not slow down any progress on the >> > release. If >> > > > > we >> > > > > > > >> agree >> > > > > > > >> > it would be good to have this being worked on, I will try to >> > > > > manage >> > > > > > > >> this so >> > > > > > > >> > it doesn't block the release work in any way. >> > > > > > > >> > >> > > > > > > >> > Is there anyone opposing this, please? What do you think? >> > > > > > > >> > >> > > > > > > >> > Best regards, >> > > > > > > >> > Tibor >> > > > > > > >> > >> > > > > > > >> >> > > > > > > >> >> > > > > --------------------------------------------------------------------- >> > > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org >> > > > > > > >> For additional commands, e-mail: dev-h...@kie.apache.org >> > > > > > > >> >> > > > > > > >> >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Tibor Zimanyi >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org >> > For 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
