Gabriele, Ok, since you seem to feel strongly about this direction, I personally don't have any more comments about this transition from native binaries to normal JAR + local JRE setup. What I'll say is that we move forward with the Quarkus 3.20 upgrade on `kie-tools` but keep using the last timestamped SNAPSHOT native build of JIT Executor (999-20250511-SNAPSHOT) in the `extended-services` package while you sort things out with everyone else and maybe implement the changes you want to, depending on people's feedback, of course. Once the direction is clear and you have KIE Sandbox adapted to using this new release artifact (or existing ones, depending on where this goes), you can then delete the `extended-services` package, finally removing the dependency with the last timestamped SNAPSHOT build of JIT Executor native binaries (999-20250511-SNAPSHOT) and concluding this matter.
Let us know. Regards, Tiago Bento On Fri, Jun 20, 2025 at 3:48 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > Tiago, > about wrapping the jar inside executables, I already did that in the past, > so I just need to verify if I may reuse that approach, or if something > different is needed. > About collaborating with the CI, no problem at all, I would be glad to do > that. > The only thing I would like to have is a sort of opinion/feedback from the > rest of the community because, regardless of the choice, the burden to > maintain it and the consequences will fall on everyone. > Said differently: I think it is needed that, for this kind of choices with > general impact, the community should understand the matter, provide > feedback, and share commitment, even if it is a single one that actually > implements it. > > If no one jumps in, I'll start working on that next week, I'll share > results/findings, and then I'll ask a "poll for feature". > > Best > > Gabriele > > > > Il giorno ven 20 giu 2025 alle ore 01:18 Tiago Bento <tiagobe...@apache.org> > ha scritto: > > > Gabriele, > > > > Native binaries are packaged into clickable executables for Windows > > (.exe) and macOS (.dmg) (and I guess for Linux too, IIRC), so no > > command-line needed. > > > > I understand your points. Then I guess it comes down to whether or not > > you are willing to execute your counter-proposal by doing changes on > > the builds and CI yourself. If that's the case, I honestly have no > > objection that you move it forward to unblock us, even though I'd > > still prefer having us not add yet another release artifact. (Not sure > > what others think about this JRE approach, though). > > > > Otherwise I thank the feedback, but I'll keep my original proposal of > > moving forward with already-existing parts to unblock the Quarkus 3.20 > > upgrade on `kie-tools`, while of course waiting on others to comment > > in case someone sees any problems with it. > > > > Let us know. > > > > Regards, > > > > Tiago Bento > > > > On Thu, Jun 19, 2025 at 10:54 AM Gabriele Cardosi > > <gabriele.card...@gmail.com> wrote: > > > > > > - `By kie-tools` you meant KIE Sandbox. <- yes > > > - `By kie-services` you meant Extended Services. <- yes > > > "Would it be a JAR that users download directly then `java -jar` it > > > to execute" <- yes (maybe fired by a simple script, as currently happens > > > for native binaries, IINW). > > > > > > Yes, the main disagreement is on what is the better pros/cons ratio. > > > I see your point in the current CI, but at the same time I think that we > > > have to consider possible issues when such a solution is made available > > to > > > the broadest audience. > > > On one hand, I think that modify the CI to provide the jit-executable jar > > > should not be that hard: it is already built by CI, and the "only" things > > > to modify would be: > > > 1. Currently, the extended service downloads the native binaries > > > "on-demand" (IIRC); instead of them, it should download jar > > > 2. currently, there is a command that is invoked to actually execute the > > > native binaries; this should be modified to invoke the "java -jar..." > > > command > > > So, again if I do not miss something, it does not seem a big change to > > me. > > > > > > On the other hand, we are already facing a lot of big and small issues > > > related to docker environments, with all the different implementations, > > the > > > security policies of companies, etc etc.... > > > That's why I think that, in the bigger perspective, the good ol' plain > > java > > > approach could be easier to manage, taking everything in consideration. > > > > > > > > > Cheers > > > > > > Gabriele > > > > > > Il giorno gio 19 giu 2025 alle ore 16:09 Tiago Bento < > > tiagobe...@apache.org> > > > ha scritto: > > > > > > > These are my assumptions based on your last message: > > > > - `By kie-tools` you meant KIE Sandbox. > > > > - `By kie-services` you meant Extended Services. > > > > > > > > With those assumptions, to your first two points: > > > > 1. Yes, that's what users do today with the native binaries for > > > > Extended Services. > > > > 2. Not sure what you mean by "if runtime check is required", but we > > > > can ignore this part I guess. > > > > > > > > My proposal is that users run a Docker image locally instead of > > > > the native binaries for Extended Services. > > > > > > > > Your counter-proposal is that users run a normal JAR instead of the > > > > native binaries for Extended Services. > > > > > > > > I wouldn't have a problem with your suggestion (although I still think > > > > for KIE Sandbox users, managing Docker installation is easier then > > > > managing a JRE installation, but we can disagree in that part, since > > > > it's a personal thing I guess), wasn't it for the fact that it > > > > requires more work to adapt the codebase and release pipelines > > > > to produce a new artifact, whereas the Docker image is already > > > > available and ready to use for the `main`, `10.0.0` and `10.1.0` > > > > streams. Also, it's not clear to me how you would pack and distribute > > > > it. Would it be a JAR that users download directly then `java -jar` it > > > > to execute? > > > > > > > > Regards, > > > > > > > > Tiago Bento > > > > > > > > On Thu, Jun 19, 2025 at 9:46 AM Gabriele Cardosi > > > > > > > > <gabriele.card...@gmail.com> wrote: > > > > > > > > > > Tiago, > > > > > I may misunderstand something, but what I get is that you suggested > > using > > > > > the docker image as "on-the-fly" backend for kie-tools, i.e. > > > > > 1. user fire kie-services locally > > > > > 2. if runtime check is required, they download the docker image (or - > > > > > anyway, they start the docker image in their local docker > > environment) > > > > that > > > > > contains the jit executor. > > > > > > > > > > If this is your proposal, to avoid the native image, then my > > > > > counter-proposal is to > > > > > 1. build jit-executor as normal jar > > > > > 2. ask users to install JRE > > > > > 3. download and execute the jit-executor jar as normal java > > application > > > > > > > > > > because, IMO, jar artifacts, and JRE installation, are easier (or - > > > > > somewhat - more predictable) to manage than docker environments. > > > > > > > > > > It may be that I completely misunderstand something in all this > > thread, > > > > in > > > > > which case I apologize and please correct me if some of my > > assumptions > > > > are > > > > > wrong. > > > > > > > > > > Cheers > > > > > > > > > > Gabriele > > > > > > > > > > > > > > > > > > > > Il giorno gio 19 giu 2025 alle ore 15:15 Tiago Bento < > > > > tiagobe...@apache.org> > > > > > ha scritto: > > > > > > > > > > > Gabriele, > > > > > > > > > > > > Not sure what are you suggesting to unblock the Quarkus 3.20 > > upgrade > > > > > > then, can you please clarify? > > > > > > > > > > > > On Thu, Jun 19, 2025 at 8:50 AM Gabriele Cardosi > > > > > > <gabriele.card...@gmail.com> wrote: > > > > > > > > > > > > > > -1 on my side > > > > > > > > > > > > > > > > > > > > > @Alex > > > > > > > the point is not if we have already built artifacts or not, the > > real > > > > > > > problem is if we need them in this situation. > > > > > > > > > > > > > > The main point behind that "JITExecutor native" approach has > > always > > > > been > > > > > > to > > > > > > > avoid the users to install "tools" as in " > > > > > > > *without needing to install and/or manage Java or anyother tools > > > > > > locally*" > > > > > > > (quot.) > > > > > > > > > > > > > > Docker is a "tool", and so requiring users to install it clearly > > > > breaks > > > > > > the > > > > > > > above constraint. > > > > > > > So, instead of asking them to install Docker and rely on a > > sort-of > > > > > > > contrived setup, I think we should just ask them to install > > > > compatible > > > > > > JRE, > > > > > > > and that would solve the problem at its root. > > > > > > > > > > > > > > Sorry, but going the docker way (or also what I suggested) is > > simply > > > > > > > building unneeded workarounds around a constraint that we > > created and > > > > > > does > > > > > > > not exist anymore, as a matter of fact. > > > > > > > So, let's be simple and pragmatic, remove that unneeded and > > > > problematic > > > > > > > "constraint", and make things simple. > > > > > > > > > > > > > > M2C > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > > > > > > > > > > Il giorno gio 19 giu 2025 alle ore 14:02 Alex Porcelli < > > > > > > porce...@apache.org> > > > > > > > ha scritto: > > > > > > > > > > > > > > > +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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
