Gabriele, Thanks. I'll proceed in this way then while we collectively decide which way to go for the JIT Executor native binaries replacement.
Regards, Tiago Bento On Fri, Jun 20, 2025 at 11:17 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
