Tiago, I'll start working on that on Monday. If I found some blockers or any kind of delay, I'll inform all of you immediately.
I'll also try to give an estimated delivery time ASAP. Best Gabriele Il giorno ven 20 giu 2025 alle ore 17:12 Tiago Bento <tiagobe...@apache.org> ha scritto: > 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 > >
