+1 for Tiago's proposal! Thank you, Tiago, for the clarification and the clear proposal.
@Gabriele, you have a point, but I also believe the goal is to avoid creating new artifacts and reuse existing ones as much as possible. With that in mind, reusing containers makes a lot of sense. On Thu, Jun 19, 2025 at 3:28 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
