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