I’m looking for this new thread, but I don’t think it would invalidate this thread.
The scope of this thread is clear, and if you hang in Zulip you can see that users are completely lost with lack of any example…. I created my own example to help, but I don’t think this is the solution this community. I’d argue that the options are clear and also we defined, there’s an actionable plan and even commitment to execute. Alex On Thu, Jan 9, 2025 at 10:20 AM Paolo Bizzarri <pibi...@gmail.com> wrote: > Hi Alex, > > I do think that this is relevant for the discussion on the kogito examples. > > It is a necessary decision that we as a community we need to take before > making other modifications to the repo structure. > > Let's open a new thread so that first we can reach the consensus on which > should be the general structure of the KIE project - in term of > repositories - and then we can move forward identifying the actions > required to move into that direction and who can do this. > > Without this consensus things will keep getting discussed again and again, > which is something no one wants. > > Regards > > P. > > On Thu, Jan 9, 2025 at 2:36 PM Alex Porcelli <a...@porcelli.me> wrote: > > > Thank you, Tiago for steering back the thread to original problem. > > > > Please anyone feel free to open a new thread to discuss whatever you > > consider necessary. Just be thoughtful to write not only opinions, but > > detailed plans with actionable items. Ideally with some level of > commitment > > to an execution. > > > > - > > Alex > > > > On Thu, Jan 9, 2025 at 8:15 AM Tiago Bento <tiagobe...@apache.org> > wrote: > > > > > Hi everyone, > > > > > > Before I share my remarks about the "examples" topic in particular, > > > let me start by talking about a concept that I think is often > > > mistakenly used in this mailing list -- "users". Users are (the way I > > > see it at least) people who consume our software via our official > > > releases. They (mostly) DO NOT care about where or how the source code > > > is hosted, built, released, nor how "hard" or "inconvenient" it is to > > > develop the artifacts they actually depend on. Apache KIE users are > > > not Apache KIE developers. For a long time now, I think we might be > > > focusing our technical discussions too much on us (developers) and too > > > little on our users, who are the reason why we do all this in the > > > first place. In the end, we want our software to be used to solve > > > problems in the real world, and to help people outside of this little > > > inner circle of developers (us) to do so. > > > > > > Alex created a thread to discuss a real problem our users are facing, > > > and we quickly turned it into a discussion on what's best for us > > > developers. Alex also came up with a real solution to the problem, and > > > we started debating the entire architecture of the codebase, with all > > > sorts of arguments mixed into the conversation. We won't ever go > > > anywhere if we continue discussing things this way. We can't halt all > > > technical/architectural discussions because we don't have a "global" > > > plan that will solve all our problems. So let's PLEASE take a step > > > back and talk about our focused subject on this thread: "How can we > > > allow our users consume meaningful example applications in an easy > > > way, for each release we do?". > > > > > > I compiled the two options that have been shared so far: > > > > > > 1. Move the example applications from `kogito-examples` to > > > `kie-tools`'s `examples/` folder and create a new release job to > > > publish a ZIP containing each of the examples as a release artifact. > > > 2. Integrate `kogito-examples` into our release process so that it has > > > its versions properly updated and is tagged once a release is > > > approved, and keep everything else as is, without references to > > > artifacts coming from `kie-tools`. > > > > > > What I most like about option 1 is that there are no changes needed in > > > "the CI" (other than removing kogito-examples from it, of course, like > > > we did for kogito-images recently). Moving our examples to `kie-tools` > > > would also allow for them to correctly and safely depend on tools > > > artifacts, like the graphical Editors, Container images, and Quarkus > > > Dev UIs, which, as pointed out by Francisco, have become central to > > > the development of Decisions, Workflows, and Processes, and add a > > > great value for people exploring these examples applications. Users > > > would be able to consume these example applications in the same way > > > they consume other release artifacts, and we could even keep a > > > read-only repository where we publish these individual applications > > > for convenience (maybe `github.com/apache/incubator-kie-examples` > <http://github.com/apache/incubator-kie-examples> > > <http://github.com/apache/incubator-kie-examples>? > > > <http://github.com/apache/incubator-kie-examples?>). > > > IMHO, trying to make a repository satisfy both developers and users > > > will always yield a sub-optimal setup. > > > > > > This "CI" we're constantly referring to, to my best knowledge, is a > > > mix of PR checks (`build-chain` + GitHub Actions) and release > > > automations ("the Kogito framework" on Apache Jenkins) for the > > > `drools`, `optaplanner`, `kogito-runtimes`, `kogito-apps` (and more or > > > less `kogito-examples`) repos. I personally do not know how it all > > > works, but AFAIK `build-chain` was created by Enrique Cano back in Red > > > Hat days and has been referred to by our PR checks [1]; and "the > > > Kogito framework" on Apache Jenkins for release automation has always > > > imposed challenges to us in terms of maintainability. Rodrigo Antunes, > > > Alex, and I suffered quite a bit with it during the push for 10.0.0. > > > > > > While I believe both `build-chain` and "the Kogito framework" on > > > Apache Jenkins to have been created by talented contributors with > > > their best intentions in mind, both have evolved to be places where no > > > one wants to go; tools that no one really wants to maintain/evolve. In > > > my view, both have become an increasing risk to the sustainable growth > > > of the Apache KIE community, so suggesting we delegate the solution to > > > a "new" problem to these systems (and therefore depending more on > > > them) doesn't really resonate with me, so I wouldn't go with option 2. > > > > > > [1] > > > > > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/actions/build-chain/action.yml#L36 > > > > > > > > > On Thu, Jan 9, 2025 at 6:16 AM Gabriele Cardosi > > > <gabriele.card...@gmail.com> wrote: > > > > > > > > Hi all, > > > > I would like to quote: > > > > > > > > "So, first and foremost we should decide which is the ideal situation > > > where > > > > we want to move our repos - one repo, two repo, many repos. With > ideal > > > > situation I mean "what we think is the best architecture". > > > > > > > > There is a similar thread where we have been asked to approve a given > > > > proposal without having defined the overall strategy for code-base > > > > management. > > > > The lack of a clear architecture goal, IMO, affected a lot of our > > > > decisions, that at a given point became "unavoidable" while, > actually, > > > they > > > > were not. > > > > > > > > So, to further the previous remarks, before going on with this > > > discussion, > > > > there are two topics to tackle once and for all > > > > > > > > 1. multiple repo vs mono-repo (global concern) > > > > 2. What is exactly the scope of our examples ? (specific to this > > thread) > > > > > > > > About the latter, we also had a longish thread last summer, about > > > > "standalone" or similar, that basically ended up on nothing because, > if > > > the > > > > scope of something is not commonly clear and agreed upon, then it is > > > > impossible to get to a commonly shared solution. > > > > > > > > Best > > > > Gabriele > > > > > > > > Il giorno gio 9 gen 2025 alle ore 08:43 Jan Šťastný < > > > jstastn...@apache.org> > > > > ha scritto: > > > > > > > > > Hello, > > > > > > > > > > I'd like to add some high-level details of "the CI changes". > > > > > > > > > > From CI standpoint, adding kie-tools build into build-chain > > > configuration > > > > > for drools/optaplanner/kogito-runtimes/kogito-apps is possible. > There > > > would > > > > > be adjustments needed for the examples to reference a "local" image > > > created > > > > > during the same CI build, but that should be fine. The execution > > times > > > > > would be extended by the time needed to build kie-tools images due > to > > > > > repository changes up the stream (drools,...), but that's closing a > > > serious > > > > > gap we have in the builds, so I don't worry too much. > > > > > > > > > > What implications this would have on kie-tools pr-check/nightly > > builds > > > I > > > > > don't know, it's a different CI solution from the rest. > > > > > > > > > > But as mentioned by others here - we need to clarify what is our > > > ultimate > > > > > goal, which hugely affects CI. > > > > > > > > > > I have mentioned build-chain which is by many people regarded as > > > > > (un)necessary evil. I just want to highlight that when we keep many > > > > > repositories, then a solution without build-chain would be a > > > non-trivial > > > > > effort comparable to the initial CI configuration after the > > repository > > > > > transfer. Which I do not volunteer for. > > > > > > > > > > Regards > > > > > Jan > > > > > > > > > > On Thu, 9 Jan 2025 at 07:20, Paolo Bizzarri <pibi...@gmail.com> > > wrote: > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > I do not think this is the correct approach. > > > > > > > > > > > > If we have a window with a broken glass, we can decide to use a > > > newspaper > > > > > > to close the hole because we do not have the money to purchase a > > new > > > > > glass. > > > > > > But this does not mean that using a newspaper is a good strategy > to > > > fix a > > > > > > window. > > > > > > > > > > > > So, first and foremost we should decide which is the ideal > > situation > > > > > where > > > > > > we want to move our repos - one repo, two repo, many repos. With > > > ideal > > > > > > situation I mean "what we think is the best architecture". > > > > > > > > > > > > Then we decide which steps we want to take in which direction. > > > > > > > > > > > > WRT resources - i.e. time of people for fixing this or that. It > is > > > very > > > > > > hard to commit to "something" when it is not clear what is this > > > > > > "something". In our case, it is hard for me to commit to > > > "investigate CI > > > > > > options" when it is pretty unclear which is the situation we want > > to > > > > > > achieve. > > > > > > > > > > > > As far as I remember, there have been multiple threads in the > past > > > months > > > > > > where it is pretty clear that there is no agreement on the > general > > > > > > structure of repos and dependencies. > > > > > > > > > > > > Let's clarify first this, and then move forward. > > > > > > > > > > > > Regards. > > > > > > > > > > > > Paolo > > > > > > > > > > > > On Wed, Jan 8, 2025 at 9:53 PM Alex Porcelli <a...@porcelli.me> > > > wrote: > > > > > > > > > > > > > I'd agree to remove the link with tools if we'd remove the > tools > > > > > > > dependencies from the examples.... otherwise it creates the > > > cyclical > > > > > > > dependency - which was the reason Examples was excluded from > the > > > > > > > release. > > > > > > > > > > > > > > I'm also happy if anyone here volunteers to explore the > > adjustments > > > > > > > needed in the CI suggested by you... I'm also happy with that. > > > > > > > > > > > > > > But in the end I expect that we get into a solution, in a way > or > > > > > > > another. I'd like to propose to use the general 72 hours (as > > > commonly > > > > > > > used in Apache) to see if we get any volunteers to take on CI > > > work. If > > > > > > > we can't get it, I'd suggest narrowing the options to either > > adjust > > > > > > > examples (remove dependencies to artifacts produced by tools > > repo) > > > or > > > > > > > move the examples somewhere else. > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 3:41 PM Francisco Javier Tirado Sarti > > > > > > > <ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > > I would argue that examples depend more directly on runtimes, > > > apps or > > > > > > > > drools than in tools or images, basically because a > regression > > in > > > > > tools > > > > > > > > code will hardly make any example IT to fail, but a > regression > > in > > > > > > > runtimes, > > > > > > > > apps or drools will certainly cause almost all examples to > > > > > malfunction. > > > > > > > In > > > > > > > > fact, in most cases, tool dependency is just an optional > add-on > > > to > > > > > the > > > > > > > > example, it's not part of the core functionality of the > > example. > > > A > > > > > > proof > > > > > > > of > > > > > > > > that is that if the tool dependency is removed, most examples > > > will > > > > > > still > > > > > > > > work (without the fancy graphical tool, but will still work). > > So, > > > > > from > > > > > > > that > > > > > > > > point of view, it is kind of strange that examples are moved > > > > > precisely > > > > > > to > > > > > > > > the repo they have the weaker link to (I'm not arguing to > > remove > > > the > > > > > > > > dependency because I feel tools are a pivotal part of the > > > platform > > > > > that > > > > > > > > makes a difference and we want to showcase that in our > > > examples). We > > > > > > also > > > > > > > > have a couple of examples that, trying to illustrate k8s > usage > > > (which > > > > > > is > > > > > > > > also pivotal, but not strictly needed, because the platform > > also > > > runs > > > > > > on > > > > > > > > baremetal), are really required to be executed after > everything > > > else > > > > > > has > > > > > > > > been compiled, tested and deployed. > > > > > > > > With that in mind, I think that moving stuff to the last > > > repository > > > > > in > > > > > > > the > > > > > > > > chain (because I guess that's the reason Tools was the chosen > > > one) > > > > > > should > > > > > > > > be a kind of last resort, we need to explore the CI issue > > first. > > > > > Maybe > > > > > > it > > > > > > > > is not that hard (for a person with enough knowledge of the > > > internals > > > > > > of > > > > > > > > the CI pipeline, I'm clearly not that person) to execute > > > examples at > > > > > > the > > > > > > > > end of the CI pipeline. And definitely branching examples > repo > > > for > > > > > > > release > > > > > > > > at the same time than the other repos should not be a huge > > > problem > > > > > > either > > > > > > > > and I think it can be done independently of the CI order > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 8:17 PM Alex Porcelli < > a...@porcelli.me > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Francisco, I think some clarifications are needed. > > > > > > > > > > > > > > > > > > By “properly maintained,” I’m referring to examples that > are > > > fully > > > > > > > > > integrated into our CI pipeline and constantly updated to > > > track the > > > > > > > > > project’s versions, including release versions. In my view, > > > > > ensuring > > > > > > > > > that examples work not just with 999-SNAPSHOT but also > > released > > > > > > > > > versions is critical. > > > > > > > > > > > > > > > > > > Regarding Snapshot Usage, while having examples > automatically > > > point > > > > > > to > > > > > > > > > 999-SNAPSHOT is helpful for early testing, we need to be > > > cautious. > > > > > > > > > Apache guidelines discourage the promotion of snapshot > > > artifacts > > > > > as a > > > > > > > > > primary means of distribution. Hence, it’s important to > offer > > > > > > examples > > > > > > > > > that align with actual release versions as well. > > > > > > > > > > > > > > > > > > Current CI Limitations, although the examples repo is > > nominally > > > > > > > > > integrated into CI for the runtimes and apps, the setup is > > not > > > > > > > > > functioning as intended. Many examples require DevUI or > > > container > > > > > > > > > images built in the kie-tools repository, which aren’t > fully > > > > > captured > > > > > > > > > in the current pipeline. This makes it difficult to trust > CI > > > > > results > > > > > > > > > entirely. > > > > > > > > > > > > > > > > > > And finally, my last proposal includes relocating the > > examples > > > to > > > > > the > > > > > > > > > kie-tools repo (under an /examples folder) so they can be > > > > > developed, > > > > > > > > > built, and tested alongside the assets they depend on > (DevUI, > > > > > > > > > container images, etc.). And part of this move, I commit > > > myself to > > > > > > > > > adjust the release CI to produce a dedicated “examples > > > artifact”. > > > > > > This > > > > > > > > > should resolve the dependency and version-sync issues while > > > still > > > > > > > > > allowing us to release the examples separately. > > > > > > > > > > > > > > > > > > I hope these clarifications help. Please let me know if you > > > have > > > > > any > > > > > > > > > questions or concerns. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 4:55 AM Francisco Javier Tirado > Sarti > > > > > > > > > <ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > We need to define "properly maintained" ;). Currently, > > > examples > > > > > > repo > > > > > > > is > > > > > > > > > > integrated into the CI pipeline for runtimes and apps. > This > > > means > > > > > > > that if > > > > > > > > > > some change in runtimes or apps repos breaks an example, > > the > > > PR > > > > > > will > > > > > > > be > > > > > > > > > red > > > > > > > > > > and won't be merged. > > > > > > > > > > That's another layer of "security" from a quality > > > perspective and > > > > > > > forces > > > > > > > > > us > > > > > > > > > > to keep examples working. > > > > > > > > > > They are also a good way for community users to test the > > > latest > > > > > > > changes > > > > > > > > > on > > > > > > > > > > main before they are released. If they checkout main > > branch, > > > > > since, > > > > > > > by > > > > > > > > > > default, examples on main point to 999-SNAPSHOT version, > > they > > > > > will > > > > > > be > > > > > > > > > using > > > > > > > > > > latest snapshot, which is a good alternative for users > that > > > do > > > > > not > > > > > > > want > > > > > > > > > to > > > > > > > > > > wait for a release to perform experiments. > > > > > > > > > > Therefore, I think your latest proposal is great. We keep > > > > > > everything > > > > > > > as > > > > > > > > > it > > > > > > > > > > is and release examples separately. > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 1:17 AM Alex Porcelli < > > > a...@porcelli.me> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Thanks for sharing your perspective, Francisco. You > > raise a > > > > > valid > > > > > > > > > > > point about user experience; however having a dedicated > > > > > examples > > > > > > > repo > > > > > > > > > > > doesn’t necessarily help if it isn’t properly > > > maintained—what’s > > > > > > the > > > > > > > > > > > purpose of an examples repository if it doesn’t > reference > > > the > > > > > > > current > > > > > > > > > > > release? > > > > > > > > > > > > > > > > > > > > > > One idea to address this, which we could borrow from > our > > > IBM > > > > > > > > > > > colleagues, is to create a separate release artifact > for > > > the > > > > > > > examples. > > > > > > > > > > > We could then publish the artifact content into a > > dedicated > > > > > > > repository > > > > > > > > > > > manually whenever we cut a release. This way: > > > > > > > > > > > > > > > > > > > > > > - Maintenance & Integration: We still integrate the > > > examples in > > > > > > our > > > > > > > > > > > main build process (so they remain aligned with each > > > release). > > > > > > > > > > > - User-Friendly Browsing: At the same time, the > > standalone > > > > > > examples > > > > > > > > > > > repository remains easy to browse, avoiding the > > complexity > > > of a > > > > > > > large, > > > > > > > > > > > all-in-one codebase. > > > > > > > > > > > > > > > > > > > > > > This approach keeps the examples maintained in sync > with > > > > > releases > > > > > > > > > > > while offering a simpler path for users to find and > > explore > > > > > them > > > > > > > > > > > without wading through the entire repository > > > structure—which > > > > > can > > > > > > be > > > > > > > > > > > overwhelming. > > > > > > > > > > > > > > > > > > > > > > I volunteer myself to adjust the CI to produce this > > > artifact in > > > > > > the > > > > > > > > > > > release pipeline. > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 7, 2025 at 6:51 AM Francisco Javier Tirado > > > Sarti > > > > > > > > > > > <ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I can see why it is easier, from a technical point of > > > view, > > > > > > since > > > > > > > > > some > > > > > > > > > > > > examples rely on tooling, to move all examples to > > tooling > > > > > repo. > > > > > > > > > > > > However, I hardly see why this makes users' > experience > > > > > better. > > > > > > > > > > > > Let me elaborate, With examples repo, we currently > > have a > > > > > place > > > > > > > where > > > > > > > > > > > users > > > > > > > > > > > > can browse all examples starting from the repo root. > > > > > > > > > > > > With tooling repo, I guess they will start browsing > > under > > > > > > > examples > > > > > > > > > > > > directory? > > > > > > > > > > > > If we are going for technical simplicity, I guess it > is > > > > > > probably > > > > > > > > > time to > > > > > > > > > > > be > > > > > > > > > > > > coherent and move all KIE content under the same repo > > > (I'm > > > > > not > > > > > > > for > > > > > > > > > it, > > > > > > > > > > > but > > > > > > > > > > > > I have the feeling that there is a majority in favour > > of > > > > > that, > > > > > > so > > > > > > > > > > > probably > > > > > > > > > > > > time to vote?). > > > > > > > > > > > > Which I feel is really awkward is to have different > > > > > strategies > > > > > > > under > > > > > > > > > the > > > > > > > > > > > > same label (some content in some separate repos and > > > gradually > > > > > > > moving > > > > > > > > > > > > everything to a repo named "tools" which is not > really > > > just > > > > > > > "tools" > > > > > > > > > > > > anymore) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 6, 2025 at 5:26 PM Jason Porter > > > > > > > <jpor...@ibm.com.invalid > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > I know it makes for a larger repo, but I’m all for > > > fewer > > > > > > > > > repositories, > > > > > > > > > > > and > > > > > > > > > > > > > an easier setup for not only contributors, but all > > > users. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Jason Porter > > > > > > > > > > > > > Software Engineer > > > > > > > > > > > > > He/Him/His > > > > > > > > > > > > > > > > > > > > > > > > > > IBM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Alex Porcelli <porce...@apache.org> > > > > > > > > > > > > > Date: Monday, January 6, 2025 at 03:01 > > > > > > > > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > > > > > > > > > Subject: [EXTERNAL] [DISCUSS] Missing > kogito-examples > > > > > update > > > > > > > for > > > > > > > > > the > > > > > > > > > > > > > 10.0.0 release! > > > > > > > > > > > > > Happy new 2025, everyone! > > > > > > > > > > > > > > > > > > > > > > > > > > As we discussed when we started the 10.0.0 release > > > process, > > > > > > the > > > > > > > > > > > > > kogito-examples repository was neither included in > > the > > > > > > release > > > > > > > nor > > > > > > > > > > > fully > > > > > > > > > > > > > integrated into CI. Although some PR checks > consider > > > > > > > > > kogito-examples, > > > > > > > > > > > this > > > > > > > > > > > > > gap ultimately led to absent examples for the > 10.0.0 > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > Currently: > > > > > > > > > > > > > > > > > > > > > > > > > > - The stable branch remains on versions 1.44 and > 8.44 > > > > > > > > > > > > > - The main branch is on 999-SNAPSHOT > > > > > > > > > > > > > > > > > > > > > > > > > > Given that many of the kogito-examples rely on > > > container > > > > > > > images and > > > > > > > > > > > Dev UI, > > > > > > > > > > > > > we'd need to incorporate the repository into our CI > > > system > > > > > to > > > > > > > > > improve > > > > > > > > > > > the > > > > > > > > > > > > > current situation, which might take some time and > > will > > > > > likely > > > > > > > > > impact > > > > > > > > > > > the > > > > > > > > > > > > > upcoming releases. > > > > > > > > > > > > > > > > > > > > > > > > > > Alternatively, we could move the examples to > > kie-tools > > > (a > > > > > > repo > > > > > > > that > > > > > > > > > > > already > > > > > > > > > > > > > hosts all images and DevUI) so no CI changes would > be > > > > > > required. > > > > > > > > > > > > > > > > > > > > > > > > > > I would love to hear your thoughts, alternative > > ideas, > > > or > > > > > > > concerns > > > > > > > > > so > > > > > > > > > > > we > > > > > > > > > > > > > can have an actionable plan to do better in the > next > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > 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 > > > > > > > > >
