Enrique, unfortunately this is not entirely possible. The only reason to move the examples under the kie-tools repo is because of examples depending on kie-tools artifacts, so to properly build the examples you have first build the dependencies.
To work with the examples the steps would be something along the following lines: $ git clone kie-tools $ cd kie-tools $ pnpm bootstrap -F runtime-examples... $ cd examples/runtime-examples (to some extent at this point you can interact with the examples as a standalone thing) $ idea/code/eclipse . $ mvn clean compile, (this is not 100% precise because it depends on how the examples are moved etc... but hopefully you get the idea). On Fri, Jan 10, 2025 at 5:55 AM Enrique Gonzalez Martinez <egonza...@apache.org> wrote: > > Hi, > > Regarding this topic as some of the people mentioned before this is a > matter of proper pipeline. Moving the examples to kie tools should be > a temporary solution but we know that there is nothing more permanent > than a temporary solution as everybody will get back to deadlines, TO > DO list and so forth. > > In any case if we cannot find a proper solution in the pipeline, I am > not against moving those examples to kie-tools with some conditions. > > 1. they should offer the same level of independence as it is now. > Meaning that if I go to the folder of kie-tools/examples (or whatever > it is) and I do mvn clean install it should be able to build with the > 999-SNAPSHOT like other projects and take my local changes without any > further configuration. > 2. it should support the same level of CI per PR like we have now. Now > examples are one repo but the CI execution is split in 2 (quarkus and > spring boot) > 3. any other tool used by kie-tools like pnpn should be unnecessary to > build the examples. > 4. any version or snap version set by kie tools building tool can > override during building but cannot set on pom. > 5. any change in that structure without proper discussion should be > result in an inmediate rollback without any approval required. > > Doing this mantain the kogito-examples independence even if we have > them in kie-tools and for backender will have the same outcome and > daily work. If those criteria are not met, I am against moving > examples. > > Cheers :) > > > El jue, 9 ene 2025 a las 16:56, Alex Porcelli (<porce...@apache.org>) > escribió: > > > > 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 > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > 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
