-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 > >
