HI Tiago Bento, glad to see that finally we get to this topic 😀. While I understand the ratio behind docker images, it seems to me to contradict the very first reason for native image, i.e. "without needing to install and/or manage Java or any other tools locally". If we have to ask users to install the Docker environment (which is a complex tool, IMO), then I fail to see the problem of installing a JRE, in the first place. Please take in account that docker environments on different OS (and different security restrictions) are pretty problematic. But, pretending that it is legitimate to ask for docker setup and not for JRE installation, I think a viable alternative could be the build of embedded java executable, using jpackage/jlink tools to create a trimmed down, optimized executable jre image. I started experimenting with it some time ago, but it never became a priority. Anyway I think it should be considered.
Best Gabriele Il giorno gio 19 giu 2025 alle ore 03:22 Tiago Bento <tiagobe...@apache.org> ha scritto: > 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 > >
