Hi all, please bear with me, but what I'm getting from last messages (correct me if I'm wrong) is that on one side there is a circular dependency between two components (kie-tools and kogito-images), and on the other side the proposed solution is to put them all in the same repo. My doubt is that a circular dependency is a matter of code, not of repo. I.e. if module A depends on module B for some code/import, and the other way around, putting the two in the same repo does not solve the issue. In the maven world this is clearly forbidden, because during the build of the overall repo it would not be possible to know which of the two should be built before. Could someone clarify this detail, please ?
Thanks! Il giorno gio 7 mar 2024 alle ore 11:38 Francisco Javier Tirado Sarti < [email protected]> ha scritto: > What I'm trying to say is that changing the streams is probably better than > doing again what we did with tooling and data-index in the past (in > kogito-apps repo), putting unrelated stuff into the same repo (image and > tooling in this case) > > > > On Thu, Mar 7, 2024 at 11:29 AM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > So, is it possible to have the following build order (regardless of kie > or > > kogito prefix)? > > 1) drools 2) runtimes 3) tools 4) images > > > > > > > > On Thu, Mar 7, 2024 at 10:51 AM Francisco Javier Tirado Sarti < > > [email protected]> wrote: > > > >> Hi Tiago, > >> Let's rewind a bit, if we ignore the kie and kogito name controversy it > >> makes perfect sense that the final image that is delivered for users > >> (whatever the name) includes tooling (whatever the name). > >> I think we need to assume that fact and devise a solution that honors > it. > >> > >> > >> On Wed, Mar 6, 2024 at 6:50 PM Tiago Bento <[email protected]> > wrote: > >> > >>> Dominik and Ricardo, > >>> > >>> I understand your concern with removing features from users. Too much > >>> has grown around the circular dependency we had between `kogito-apps` > >>> and `kie-tools`. We're fixing it now, and it is a challenging task. > >>> > >>> Rather than stating the "need" of `kogito-images` depending on > >>> `kie-tools`, let's keep the focus on the end result. IMHO it is > >>> irrelevant on which repo something is hosted, as long as we can do > >>> atomic releases and kick-off our release train with Apache KIE 10. > >>> That means defining a clear topology of repos during an Apache KIE > >>> build, which, by definition, can't contain cycles. > >>> > >>> Now, `kogito-images` either is part of the `drools` and `kogito-*` > >>> streams, or it's not. > >>> > >>> This PR [1] > >>> https://github.com/apache/incubator-kie-kogito-images/pull/1734 > >>> introduces a cycle, even without the changes proposed by me on the > >>> first email of this thread, so merging this PR would be introducing a > >>> blocker for the Apache KIE 10 release (and for future releases too). > >>> > >>> If we really wanted to have `kogito-images` depending on `kie-tools`, > >>> though, we would need to: > >>> > >>> 1. Make sure `kie-tools` doesn't depend on `kogito-images`; > >>> 2. Create a third development stream, just for `kogito-images`, > >>> leaving a buffer for `kogito-images` to be updated with the latest > >>> `kie-tools` version during a release. Analogous to what we do with > >>> `kie-tools` and the `drools` and `kogito-*` stream; > >>> 3. Create a mechanism to do timestamped SNAPSHOT releases of > >>> `kie-tools`, analogous to what we have on the `drools` and `kogito-*` > >>> streams now. > >>> > >>> This, IMHO, introduces a lot more complexity to our already convoluted > >>> release process, so I wouldn't go on that route. > >>> > >>> With all that said, and to be clear regarding the topology of the > >>> repository, to successfully build and release Apache KIE 10, we need > >>> to take all 22 repositories [1] we have in Apache right now, and sort > >>> them in a way that we can build them one by one, only once, without > >>> referencing older versions of any 1st-party > >>> package/module/image/artifact. > >>> > >>> We can't think about our repos in the same way we used to. KIE Tools > >>> won't have a release published before nor after a Drools or Kogito > >>> Runtimes release. Everything will be released at the same time. That's > >>> the mindset shift we all need to get used to if we want to do atomic > >>> releases of Apache KIE. > >>> > >>> I hope it is clearer now why we can't have `kogito-images` depending > >>> on `kie-tools` if `kogito-images` continues to be part of the `drools` > >>> and `kogito-*` development streams. > >>> > >>> The way I see it, Dominik came to this mail thread with an important > >>> and valid concern, which now we need to solve together, as a > >>> community. > >>> > >>> I'll keep my suggestions of either moving the image from > >>> `kogito-images` to `kie-tools`, or removing the dependency of SWF > >>> Quarkus Dev UI from it. Of course, the PR [1] can't be merged, as it > >>> will introduce a dependency cycle, so I'm -1'ing that PR too, given > >>> the blocker it will introduce to the Apache KIE 10 release. > >>> > >>> Is this image being used anywhere else? Or is `kn-plugin-workflow` the > >>> only place using it? Why does it need to stay at `kogito-images` and > >>> can't go to `kie-tools`? Same questions for the image being introduced > >>> by [1]. > >>> > >>> Let me know if I'm missing something, but I feel like our best course > >>> of action now would be moving the images to `kie-tools`. > >>> > >>> Regards, > >>> > >>> Tiago Bento > >>> > >>> > >>> [1] > >>> > https://github.com/orgs/apache/repositories?language=&q=incubator-kie&sort=&type=all > >>> > >>> > >>> On Wed, Mar 6, 2024 at 9:59 AM Alex Porcelli <[email protected]> wrote: > >>> > > >>> > Ricardo, > >>> > > >>> > Here's a better description [1] of the dependency that KIE Tools has > >>> > with the images. If we have kogito images moved to after KIE Tools, I > >>> > think we'd create a new circular dependency. > >>> > > >>> > [1] - > >>> > https://github.com/apache/incubator-kie-issues/issues/821#issuecomment-1896206199 > >>> > > >>> > On Wed, Mar 6, 2024 at 9:43 AM ricardo zanini fernandes > >>> > <[email protected]> wrote: > >>> > > > >>> > > Alex, > >>> > > > >>> > > I'm not aware of any dependencies in KIE Tools for images. > >>> > > > >>> > > On Wed, Mar 6, 2024 at 9:44 AM Alex Porcelli <[email protected]> > >>> wrote: > >>> > > > >>> > > > Ricardo, > >>> > > > > >>> > > > IIRC, there’s a dependency in KIE Tools for serverless workflow > >>> with > >>> > > > images… if this is correct, your proposal will introduce a new > >>> circular > >>> > > > dependency. > >>> > > > > >>> > > > > >>> > > > On Wed, Mar 6, 2024 at 7:39 AM ricardo zanini fernandes < > >>> > > > [email protected]> wrote: > >>> > > > > >>> > > > > Hi! > >>> > > > > > >>> > > > > A strong -1 from my side moving the images to kie-tools. We can > >>> release > >>> > > > the > >>> > > > > images after a kie-tools release or patch the images with a new > >>> kie-tools > >>> > > > > release if that comes out. It's ok to depend on it, I just need > >>> help to > >>> > > > > setup the pipelines and CI. > >>> > > > > > >>> > > > > So, when releasing SonatFlow images, we can grab the latest > >>> available > >>> > > > > kie-tools version, pack it and ship it. If a new release comes > >>> up and we > >>> > > > > need the fix, we can of course do a patch release. > >>> > > > > > >>> > > > > We just need to automate the process. > >>> > > > > > >>> > > > > Cheers! > >>> > > > > > >>> > > > > On Wed, Mar 6, 2024 at 9:33 AM Alex Porcelli < > >>> [email protected]> > >>> > > > wrote: > >>> > > > > > >>> > > > > > Dominik, > >>> > > > > > > >>> > > > > > The plans and course of action for removing the circular > >>> dependency has > >>> > > > > > been exhaustively discussed in the mailing list and Zulip > >>> channel among > >>> > > > > > community and key stakeholders, I don’t think we have room to > >>> revisit > >>> > > > the > >>> > > > > > decision that has been already agreed. > >>> > > > > > > >>> > > > > > With that being said, I don’t think the current plans removes > >>> any > >>> > > > > > functionality, we are just moving things from one repository > to > >>> > > > another. > >>> > > > > > > >>> > > > > > > >>> > > > > > On Wed, Mar 6, 2024 at 2:19 AM Dominik Hanak < > >>> [email protected]> > >>> > > > > > wrote: > >>> > > > > > > >>> > > > > > > Hi Tiago, > >>> > > > > > > > >>> > > > > > > that is a problem, we are removing an important > >>> functionality for our > >>> > > > > SWF > >>> > > > > > > users, imho it is a killer feature in this case. > >>> > > > > > > I am against it, there needs to be a solution where we can > >>> depend on > >>> > > > > > > kie-tools with kie-kogito-images. > >>> > > > > > > > >>> > > > > > > Another thing that is currently open as a PR [2] that makes > >>> images > >>> > > > > depend > >>> > > > > > > on kie-tools. Here we are following > >>> > > > > > > the approach you started in kiegroup and we were not aware > >>> of any > >>> > > > > > changes, > >>> > > > > > > now with the unexpected and sudden changes it is > irrelevant? > >>> > > > > > > Do you have a proposal on how to achieve what we have in > [2] > >>> after > >>> > > > the > >>> > > > > > > circular dependency issue is fixed according to the > proposal > >>> > > > > annoucement? > >>> > > > > > > > >>> > > > > > > Dominik > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > [2] > >>> https://github.com/apache/incubator-kie-kogito-images/pull/1734 > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > On Wed, 6 Mar 2024 at 02:10, Tiago Bento < > >>> > > > > [email protected]> > >>> > > > > > > wrote: > >>> > > > > > > > >>> > > > > > > > Hi Dominik, > >>> > > > > > > > > >>> > > > > > > > That is indeed an oversight on our part. Thanks for > >>> pointing that > >>> > > > > out. > >>> > > > > > > > > >>> > > > > > > > Unfortunately, given the two development streams > (`drools` > >>> and > >>> > > > > > > > `kogito-*`, and `kie-tools`), we can't have > `kogito-images` > >>> > > > depending > >>> > > > > > > > on packages that will start being hosted on `kie-tools`, > >>> since > >>> > > > > > > > `kogito-images` is part of the `drools` and `kogito-*` > >>> development > >>> > > > > > > > stream, which is upstream from `kie-tools`' perspective. > >>> > > > > > > > > >>> > > > > > > > Since all Dev UI packages are moving to `kie-tools`, > >>> images on > >>> > > > > > > > `kogito-images` can't depend on them. > >>> > > > > > > > > >>> > > > > > > > I'm not familiar with the structure of `kogito-images`, > >>> nor the > >>> > > > > > > > purpose of this image that uses SWF's Quarkus Dev UI, but > >>> following > >>> > > > > > > > the same reasoning we did for `kogito-management-console` > >>> and > >>> > > > > > > > `kogito-task-console`, my suggestion would be moving this > >>> image to > >>> > > > > > > > `kie-tools`. Another option I can see is simply removing > >>> the > >>> > > > Quarkus > >>> > > > > > > > Dev UI dependency on this image. > >>> > > > > > > > > >>> > > > > > > > I'd wait for other opinions, though, as I'm not the best > >>> person to > >>> > > > > > > > answer SWF-related questions. > >>> > > > > > > > > >>> > > > > > > > Regards, > >>> > > > > > > > > >>> > > > > > > > Tiago Bento > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > On Tue, Mar 5, 2024 at 9:31 AM Dominik Hanak < > >>> > > > [email protected]> > >>> > > > > > > > wrote: > >>> > > > > > > > > > >>> > > > > > > > > Hi Tiago, > >>> > > > > > > > > > >>> > > > > > > > > Thanks for moving this forward. > >>> > > > > > > > > > >>> > > > > > > > > I have one thing to highlight with > >>> > > > > > > > > https://github.com/apache/incubator-kie-kogito-images > >>> > > > > > > > > I noticed [1], where the swf devui is being used in an > >>> image. > >>> > > > Imho > >>> > > > > > that > >>> > > > > > > > > would require adjustments to the nightly pipelines & > >>> release > >>> > > > > process. > >>> > > > > > > > > Would it be possible to add tasks to the plan that > ensure > >>> > > > required > >>> > > > > > > > > adjustments to our CI once the migration is done? > >>> > > > > > > > > > >>> > > > > > > > > Best regards, > >>> > > > > > > > > > >>> > > > > > > > > Dominik > >>> > > > > > > > > > >>> > > > > > > > > [1] > >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-images/blob/ce62b9d86c2ea0385ab85c3ef5339afe5ecdea72/modules/kogito-swf/devmode/build-config/module.yaml#L30 > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > On Fri, 1 Mar 2024 at 05:54, Tiago Bento < > >>> [email protected]> > >>> > > > > > > wrote: > >>> > > > > > > > > > >>> > > > > > > > > > Hi everyone, > >>> > > > > > > > > > > >>> > > > > > > > > > Following up on the status of this effort. > >>> > > > > > > > > > > >>> > > > > > > > > > I know I'm a bit late on the email, but it paid off, > >>> as we just > >>> > > > > had > >>> > > > > > > > > > our first green build [1] of KIE Tools with Java 17, > >>> Quarkus > >>> > > > > 3.2.9, > >>> > > > > > > > > > Maven 3.9.6 and Kogito 999-20240218-SNAPSHOT. We > ended > >>> up > >>> > > > > deciding > >>> > > > > > to > >>> > > > > > > > > > do items 1. and 2. together after all, but we > couldn't > >>> use the > >>> > > > > > latest > >>> > > > > > > > > > timestamped SNAPSHOT due to > >>> > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-25546, > >>> which > >>> > > > > prevented > >>> > > > > > > the > >>> > > > > > > > > > publication of the timestamped SNAPSHOT to succeed. > >>> That's why > >>> > > > we > >>> > > > > > > > > > picked 20240218, not 20240225. > >>> > > > > > > > > > > >>> > > > > > > > > > We will proceed with some manual checks now to > confirm > >>> that > >>> > > > > > > everything > >>> > > > > > > > > > is working properly, and I hope on the next status > >>> update we > >>> > > > will > >>> > > > > > > have > >>> > > > > > > > > > the big blocker removed and that we have already made > >>> some > >>> > > > > progress > >>> > > > > > > on > >>> > > > > > > > > > items other than 1. and 2.. > >>> > > > > > > > > > > >>> > > > > > > > > > It's been great seeing everyone working together to > >>> move this > >>> > > > > > forward > >>> > > > > > > > > > as fast as possible. Thanks a lot Eder, Thiago, > >>> Rodrigo, Alex, > >>> > > > > > > > > > Fabrizio, Paulo, and Yeser! > >>> > > > > > > > > > > >>> > > > > > > > > > [1] > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-tools/actions/runs/8105498131/job/22153897965 > >>> > > > > > > > > > > >>> > > > > > > > > > On Mon, Feb 26, 2024 at 5:59 AM Francisco Javier > >>> Tirado Sarti > >>> > > > > > > > > > <[email protected]> wrote: > >>> > > > > > > > > > > > >>> > > > > > > > > > > Hi Tiago, > >>> > > > > > > > > > > It was a nice morning reading ;) Thanks for all the > >>> time > >>> > > > > invested > >>> > > > > > > on > >>> > > > > > > > such > >>> > > > > > > > > > > detailed writing. > >>> > > > > > > > > > > @Ricardo Zanini <[email protected]> @Walter > Medvedeo > >>> > > > > > > > > > > <[email protected]> I guess dev ui can be > >>> removed > >>> > > > > from > >>> > > > > > > > current > >>> > > > > > > > > > > examples, at least from the ones I'm familiar with, > >>> since > >>> > > > their > >>> > > > > > > > README > >>> > > > > > > > > > > files do not really require any graphical tool. But > >>> to be > >>> > > > > honest, > >>> > > > > > > > since I > >>> > > > > > > > > > > have focused my work on SWF simple showcase > >>> examples, I'm > >>> > > > not > >>> > > > > > 100% > >>> > > > > > > > sure > >>> > > > > > > > > > > that's the same case for more elaborate ones, can > >>> you please > >>> > > > > > check > >>> > > > > > > > that > >>> > > > > > > > > > it > >>> > > > > > > > > > > is fine to remove dev ui? If this is not the case, > >>> maybe > >>> > > > those > >>> > > > > > > > examples > >>> > > > > > > > > > can > >>> > > > > > > > > > > be moved to the tools repository (points 9 and 10 > of > >>> Tiago's > >>> > > > > > email) > >>> > > > > > > > > > > Thanks in advance. > >>> > > > > > > > > > > > >>> > > > > > > > > > > On Fri, Feb 23, 2024 at 2:29 AM Tiago Bento < > >>> > > > > > [email protected] > >>> > > > > > > > > >>> > > > > > > > > > wrote: > >>> > > > > > > > > > > > >>> > > > > > > > > > > > DISCLAIMER: this is a long email. Feel free to > >>> jump to the > >>> > > > > > bottom > >>> > > > > > > > for > >>> > > > > > > > > > > > the concrete task list. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This email aims to explain the issue and lay out > >>> the > >>> > > > efforts > >>> > > > > > that > >>> > > > > > > > are > >>> > > > > > > > > > > > in place to fix it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Before we start digging into the problem, we need > >>> to > >>> > > > > > understand a > >>> > > > > > > > > > > > little bit of the history of the KIE community > and > >>> the > >>> > > > Kogito > >>> > > > > > > > > > > > initiative, at least from the part I started > >>> contributing > >>> > > > to > >>> > > > > it > >>> > > > > > > > anyway > >>> > > > > > > > > > > > :) > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Back in Business Central days, we had a single > >>> stream of > >>> > > > > > > > development. > >>> > > > > > > > > > > > We had robust CI jobs that would build the entire > >>> stack, > >>> > > > from > >>> > > > > > > > `drools` > >>> > > > > > > > > > > > to `kie-wb-distributions`. When Kogito came > about, > >>> there > >>> > > > was > >>> > > > > a > >>> > > > > > > > fission > >>> > > > > > > > > > > > in our pipelines. Kogito started to release > >>> independently > >>> > > > > from > >>> > > > > > > > > > > > everything else, and because of the organic way > >>> things > >>> > > > > started > >>> > > > > > to > >>> > > > > > > > > > > > organize themselves, the Kogito Tooling > initiative > >>> needed > >>> > > > to > >>> > > > > > have > >>> > > > > > > > its > >>> > > > > > > > > > > > own release cycle as well. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Up until we started the migration to Apache, > >>> Business > >>> > > > Central > >>> > > > > > > > > > > > continued on its `7.x` stream, Kogito was at > `1.x` > >>> stream, > >>> > > > > and > >>> > > > > > > > Kogito > >>> > > > > > > > > > > > Tooling (which was already called KIE Tools) was > >>> still on > >>> > > > > > `0.x`. > >>> > > > > > > > > > > > Drools started its own release stream as well, > >>> with `8.x`, > >>> > > > > and > >>> > > > > > > > > > > > OptaPlanner I believe had jumped to `9.x` > already. > >>> This > >>> > > > > > > > fragmentation > >>> > > > > > > > > > > > had technical implications, which we are trying > to > >>> overcome > >>> > > > > > right > >>> > > > > > > > now > >>> > > > > > > > > > > > with Apache KIE 10. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The Apache KIE 10 release is aimed to be an > atomic > >>> release, > >>> > > > > > where > >>> > > > > > > > the > >>> > > > > > > > > > > > entire Apache KIE community follows a single > >>> release > >>> > > > stream. > >>> > > > > > This > >>> > > > > > > > > > > > means we need to make sure our code base is in > >>> sync, from > >>> > > > > > > `drools` > >>> > > > > > > > to > >>> > > > > > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This whole conversation of course doesn't come > >>> without a > >>> > > > > > > > background of > >>> > > > > > > > > > > > CI pipelines, organizational perspectives of what > >>> Apache > >>> > > > KIE > >>> > > > > > is, > >>> > > > > > > > and > >>> > > > > > > > > > > > even poly- vs. mono-repo discussions. This is not > >>> the focus > >>> > > > > of > >>> > > > > > > this > >>> > > > > > > > > > > > issue, and I believe with time we'll converge > into > >>> > > > something > >>> > > > > > > > everyone > >>> > > > > > > > > > > > is comfortable with and that ultimately serves > our > >>> users > >>> > > > > well. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Due to the lack of unification and flexibility > >>> while > >>> > > > > > > bootstrapping > >>> > > > > > > > new > >>> > > > > > > > > > > > efforts, KIE Tools had to come up with a way to > >>> depend on > >>> > > > the > >>> > > > > > new > >>> > > > > > > > > > > > stuff (i.e. Kogito) without sacrificing its own > >>> integrity > >>> > > > and > >>> > > > > > > > > > > > stability. KIE Tools, as many of you know, > evolved > >>> to be a > >>> > > > > > > polyglot > >>> > > > > > > > > > > > monorepo, hosting Java, JavaScript/TypeScript, Go > >>> and > >>> > > > Docker > >>> > > > > > > > images. > >>> > > > > > > > > > > > There's a multitude of technologies at play on > KIE > >>> Tools, > >>> > > > > which > >>> > > > > > > > > > > > ultimately gives our users KIE Sandbox, VS Code > >>> and Chrome > >>> > > > > > > > Extensions, > >>> > > > > > > > > > > > and Standalone Editors that can be used as > regular > >>> > > > libraries > >>> > > > > on > >>> > > > > > > web > >>> > > > > > > > > > > > applications. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The technical solution we found on `kie-tools` > was > >>> > > > depending > >>> > > > > on > >>> > > > > > > > Kogito > >>> > > > > > > > > > > > as if it were a 3rd party dependency. We have a > >>> single, > >>> > > > fixed > >>> > > > > > > > version > >>> > > > > > > > > > > > of it and we manually upgrade it to the latest > one > >>> > > > available > >>> > > > > > when > >>> > > > > > > > we > >>> > > > > > > > > > > > need to. This has worked amazingly well, allowing > >>> us to own > >>> > > > > the > >>> > > > > > > > > > > > codebase and avoid random breaks coming from > >>> SNAPSHOT > >>> > > > > > artifacts. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This allowed the `drools` and `kogito-*` > >>> repositories to > >>> > > > > evolve > >>> > > > > > > > > > > > independently of `kie-tools`. This also made > >>> `kie-tools` > >>> > > > > > > > responsible > >>> > > > > > > > > > > > for adapting itself to changes coming from > >>> `drools` and > >>> > > > > > > `kogito-*`. > >>> > > > > > > > > > > > Luckily, we didn't have many incompatibilities, > >>> but right > >>> > > > now > >>> > > > > > we > >>> > > > > > > > have > >>> > > > > > > > > > > > an important one, that we'll discuss below. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Note that at this point, and for this issue in > >>> particular, > >>> > > > it > >>> > > > > > is > >>> > > > > > > > > > > > unimportant to discuss why things were done the > >>> way they > >>> > > > > were, > >>> > > > > > or > >>> > > > > > > > what > >>> > > > > > > > > > > > we should've done instead. I'm laying out the > >>> facts so that > >>> > > > > we > >>> > > > > > > can > >>> > > > > > > > > > > > understand how we're moving forward now. Of > >>> course, I would > >>> > > > > > > > personally > >>> > > > > > > > > > > > love to debate this on a separate thread :) > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > One of the most impactful features of KIE Sandbox > >>> is the > >>> > > > DMN > >>> > > > > > > > Runner. > >>> > > > > > > > > > > > It allows people to rapidly interact with their > >>> Decisions > >>> > > > as > >>> > > > > > they > >>> > > > > > > > > > > > author them, and this was all made possible > >>> because of the > >>> > > > > JIT > >>> > > > > > > > > > > > Executor (hosted at `kogito-apps`). KIE Sandbox > >>> also > >>> > > > started > >>> > > > > to > >>> > > > > > > > allow > >>> > > > > > > > > > > > users to deploy their Decisions to OpenShift, > then > >>> later to > >>> > > > > > > > > > > > Kubernetes, and now recently we allow users to > >>> deploy > >>> > > > > anything > >>> > > > > > to > >>> > > > > > > > > > > > OpenShift and Kubernetes, with a very high level > of > >>> > > > > > > customization. > >>> > > > > > > > All > >>> > > > > > > > > > > > these features depend on `kogito-*`, Quarkus, and > >>> all the > >>> > > > > > things > >>> > > > > > > > that > >>> > > > > > > > > > > > come with them. Including the Java version. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Logically, `kie-tools` depends on `drools` and > >>> `kogito-*`, > >>> > > > as > >>> > > > > > > > `drools` > >>> > > > > > > > > > > > and `kogito-*` can (and do!) exist and function > >>> without > >>> > > > > Tools, > >>> > > > > > > but > >>> > > > > > > > not > >>> > > > > > > > > > > > the other way around. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > As `kie-tools` started growing, maturing, and > >>> releasing > >>> > > > some > >>> > > > > > > > pieces of > >>> > > > > > > > > > > > technology that were useful to other domains > (i.e. > >>> > > > > Multiplying > >>> > > > > > > > > > > > Architecture), it became a dependency for other > >>> projects. > >>> > > > > Users > >>> > > > > > > > > > > > started depending on our Standalone Editors, but > >>> also on > >>> > > > the > >>> > > > > > > > > > > > Multiplying Architecture packages. One good > >>> example is > >>> > > > Kaoto, > >>> > > > > > > which > >>> > > > > > > > > > > > released a VS Code extension aligned with our > >>> architecture. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The capability of encapsulating web components in > >>> any > >>> > > > > > technology > >>> > > > > > > > > > > > behind a well defined, statically typed API was > >>> really > >>> > > > > > appealing, > >>> > > > > > > > and > >>> > > > > > > > > > > > when the Kogito initiative started to design > their > >>> Runtime > >>> > > > > > Tools > >>> > > > > > > > > > > > (i.e., Quarkus Dev UIs, Management Console, and > >>> Task > >>> > > > Inbox), > >>> > > > > > > using > >>> > > > > > > > the > >>> > > > > > > > > > > > Multiplying Architecture was the way to go. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > That's when the circular dependency started. We > had > >>> > > > > > > > > > > > `kogito-apps/ui-packages` depending on > >>> `kie-tools`. Note > >>> > > > that > >>> > > > > > it > >>> > > > > > > > was > >>> > > > > > > > > > > > also logical for these packages to be part of the > >>> > > > `kogito-*` > >>> > > > > > > > > > > > repositories and release stream. Users upgrading > >>> to a new > >>> > > > > > version > >>> > > > > > > > of > >>> > > > > > > > > > > > Kogito would also need to have their Task Inbox, > >>> Management > >>> > > > > > > > Console, > >>> > > > > > > > > > > > and Quarkus Dev UIs aligned with the new version > >>> of Kogito. > >>> > > > > Not > >>> > > > > > > to > >>> > > > > > > > > > > > mention Job Service, Data Index etc. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > For many months (or years!), this was not an > >>> issue, as the > >>> > > > > > > > Multiplying > >>> > > > > > > > > > > > Architecture packages were very stable and very > >>> rarely were > >>> > > > > > > > modified. > >>> > > > > > > > > > > > The last big change we had was 3 years ago, with > >>> the > >>> > > > > > introduction > >>> > > > > > > > of > >>> > > > > > > > > > > > Shared Values [1], which did not impact the > >>> fire-and-forget > >>> > > > > and > >>> > > > > > > > > > > > Promise-based mechanisms we already had in place. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Although we were aware of this circular > dependency > >>> from the > >>> > > > > > > > beginning, > >>> > > > > > > > > > > > it was not that big of a deal for `kogito-apps` > to > >>> depend > >>> > > > on > >>> > > > > an > >>> > > > > > > > older, > >>> > > > > > > > > > > > dephased version of `kie-tools`. We didn't have > >>> plans of > >>> > > > > > unifying > >>> > > > > > > > the > >>> > > > > > > > > > > > streams anyway, and it was the best solution for > >>> our users > >>> > > > to > >>> > > > > > > have > >>> > > > > > > > > > > > their Runtime Tools packages released together > >>> with the > >>> > > > > Kogito > >>> > > > > > > > stream. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > That of course changed after the migration to > >>> Apache. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > If you reached this point, thank you for your > >>> interest in a > >>> > > > > > > little > >>> > > > > > > > bit > >>> > > > > > > > > > > > of the history of KIE, and I hope you can now > >>> understand > >>> > > > why > >>> > > > > > > things > >>> > > > > > > > > > > > are the way they are. Let's talk about what > >>> changed and > >>> > > > what > >>> > > > > we > >>> > > > > > > are > >>> > > > > > > > > > > > doing to adapt to the new requirements. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Hinting a little bit to what I mentioned above, > >>> this > >>> > > > > discussion > >>> > > > > > > is > >>> > > > > > > > > > > > very intertwined with the CI pipelines and > >>> > > > > versioning/releasing > >>> > > > > > > > > > > > strategies subjects, as we are essentially > >>> discussing code > >>> > > > > > > > > > > > organization, coupling/decoupling and granularity > >>> of stuff, > >>> > > > > and > >>> > > > > > > to > >>> > > > > > > > > > > > make things easier at least for a while, `drools` > >>> and > >>> > > > > > `kogito-*` > >>> > > > > > > > will > >>> > > > > > > > > > > > continue being a separate stream from > `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > `drools` and `kogito-*` will continue being able > >>> to evolve > >>> > > > > > > > > > > > independently of `kie-tools`, and `kie-tools` > will > >>> continue > >>> > > > > > > > adapting > >>> > > > > > > > > > > > itself to whatever changes on `drools` and > >>> `kogito-*`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > At the same time, Apache KIE 10 (and the next > >>> releases > >>> > > > too!) > >>> > > > > > will > >>> > > > > > > > be > >>> > > > > > > > > > > > atomic. And for our users, a single release > stream. > >>> > > > > `drools@10 > >>> > > > > > ` > >>> > > > > > > > and > >>> > > > > > > > > > > > `kogito-*@10` will be used on `kie-tools@10`. We > >>> started > >>> > > > > this > >>> > > > > > > > effort a > >>> > > > > > > > > > > > while ago, and although we should've been more > >>> open about > >>> > > > it > >>> > > > > > from > >>> > > > > > > > the > >>> > > > > > > > > > > > beginning, we are also learning how to properly > >>> communicate > >>> > > > > > > inside > >>> > > > > > > > the > >>> > > > > > > > > > > > Apache structure. Better late than never :) > Thanks > >>> for the > >>> > > > > tip > >>> > > > > > > > Tibor! > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Here's how we'll do it: > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 1. A couple of weeks ago, one of our newest > >>> committers. > >>> > > > > Rodrigo > >>> > > > > > > > > > > > Antunes, created automated jobs to weekly > publish a > >>> > > > > timestamped > >>> > > > > > > > > > > > SNAPSHOT version of `drools` and `kogito-*`. This > >>> will > >>> > > > allow > >>> > > > > us > >>> > > > > > > to > >>> > > > > > > > > > > > have a persistent, immutable version to point to > on > >>> > > > > > `kie-tools`, > >>> > > > > > > > even > >>> > > > > > > > > > > > without having a full release. Timestamped > >>> SNAPSHOTs, as > >>> > > > > we're > >>> > > > > > > > calling > >>> > > > > > > > > > > > them, are a little bit different than normal > Maven > >>> > > > SNAPSHOTs, > >>> > > > > > as > >>> > > > > > > > there > >>> > > > > > > > > > > > is no `updatePolicy`, so as time passes, the > >>> downloaded > >>> > > > > > artifacts > >>> > > > > > > > do > >>> > > > > > > > > > > > not change. This allows `kie-tools` to be stable > >>> and > >>> > > > > > incorporate > >>> > > > > > > > > > > > changes done to `drools` and `kogito-*` at its > own > >>> pace. We > >>> > > > > > also > >>> > > > > > > > moved > >>> > > > > > > > > > > > the publication of > `@kie-tools/jitexecutor-native` > >>> to this > >>> > > > > new > >>> > > > > > > > job, so > >>> > > > > > > > > > > > we won't have to maintain it on the `kie-tools` > >>> side > >>> > > > anymore. > >>> > > > > > > > Thanks > >>> > > > > > > > > > > > Rodrigo! > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 2. When we define the code freeze prior to > >>> releasing Apache > >>> > > > > > KIE, > >>> > > > > > > > > > > > `drools` and `kogito-*` will need to be frozen a > >>> little bit > >>> > > > > > > earlier > >>> > > > > > > > > > > > than `kie-tools`, leaving a buffer for > `kie-tools` > >>> to start > >>> > > > > > > > pointing > >>> > > > > > > > > > > > to the latest timestamped SNAPSHOT and adapting > >>> itself to > >>> > > > the > >>> > > > > > > > changes. > >>> > > > > > > > > > > > My initial thoughts are around 2 weeks, but with > >>> constant > >>> > > > > > updates > >>> > > > > > > > and > >>> > > > > > > > > > > > proper alignment between the two streams, I see > >>> this time > >>> > > > > > > reducing > >>> > > > > > > > to > >>> > > > > > > > > > > > a couple of days for upcoming releases. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 3. After `kie-tools` is fully functional pointing > >>> to the > >>> > > > > latest > >>> > > > > > > > > > > > timestamped SNAPSHOT of `drools` and `kogito-*`, > >>> we can now > >>> > > > > > start > >>> > > > > > > > > > > > preparing for the actual release. We will cut new > >>> branches > >>> > > > > for > >>> > > > > > > the > >>> > > > > > > > > > > > next version (i.e. 10.0.0) and update all > >>> configuration > >>> > > > files > >>> > > > > > > that > >>> > > > > > > > we > >>> > > > > > > > > > > > have to. This will be done on `drools`, > >>> `kogito-*`, and > >>> > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > Every module/package will declare the same > >>> version, and > >>> > > > will > >>> > > > > > > > depend on > >>> > > > > > > > > > > > the upstream modules/packages with the same > >>> version as > >>> > > > well. > >>> > > > > We > >>> > > > > > > can > >>> > > > > > > > > > > > proceed with this staging phase as normal. > Running > >>> > > > > > > automated/manual > >>> > > > > > > > > > > > tests and eventually signing off that everything > >>> is good to > >>> > > > > go. > >>> > > > > > > > (I'm > >>> > > > > > > > > > > > not 100% on the timeline for the Apache release, > >>> but with > >>> > > > > this > >>> > > > > > > > process > >>> > > > > > > > > > > > we can guarantee that we will vote on branches > >>> that won't > >>> > > > > > change > >>> > > > > > > > when > >>> > > > > > > > > > > > we decide to release. It will be a matter of > >>> pushing tags > >>> > > > > > > pointing > >>> > > > > > > > to > >>> > > > > > > > > > > > these release branches). > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > With the release process defined, we can now > >>> discuss the > >>> > > > > exact > >>> > > > > > > > actions > >>> > > > > > > > > > > > we're taking to remove the circular dependency we > >>> have > >>> > > > > between > >>> > > > > > > > > > > > `kie-tools` and `kogito-apps`. All of which will > >>> need to be > >>> > > > > > > > addressed > >>> > > > > > > > > > > > prior to starting the release process. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 1. (Fabrizio - IN PROGRESS) Make sure `kie-tools` > >>> is on > >>> > > > Java > >>> > > > > > 17, > >>> > > > > > > > Maven > >>> > > > > > > > > > > > 3.9.6, and Quarkus 3. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/960 > >>> > > > ) > >>> > > > > > > > > > > > There's a complication here, since we still > >>> have three > >>> > > > > big > >>> > > > > > > > > > > > packages (Serverless Workflow Diagram Editor, > >>> BPMN, DMN, > >>> > > > and > >>> > > > > > > SceSim > >>> > > > > > > > > > > > Editors, and DashBuilder) on `kie-tools` that > need > >>> GWT, and > >>> > > > > as > >>> > > > > > > you > >>> > > > > > > > > > > > know, GWT together with Java upgrades usually > >>> require some > >>> > > > > > work. > >>> > > > > > > > We're > >>> > > > > > > > > > > > on GWT 2.10, which should already support Java > 17, > >>> but > >>> > > > we'll > >>> > > > > > know > >>> > > > > > > > more > >>> > > > > > > > > > > > once we try it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 2. (Fabrizio - NOT YET STARTED) Make sure > >>> `kie-tools` is > >>> > > > > using > >>> > > > > > > the > >>> > > > > > > > > > > > latest timestamped SNAPSHOT from `kogito-*`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/965 > >>> > > > ) > >>> > > > > > > > > > > > We have them built and published every Sunday > >>> EOD, so > >>> > > > on > >>> > > > > > > Monday > >>> > > > > > > > > > > > (Feb 25th, 2024) we'll have a brand new one to > >>> start > >>> > > > working > >>> > > > > > > with. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 3. (Thiago - IN PROGRESS) Move > >>> `kogito-apps/ui-packages` to > >>> > > > > > > > > > > > `kie-tools`. ( > >>> > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/833) > >>> > > > > > > > > > > > We started a couple of weeks ago, and we > >>> should be ~80% > >>> > > > > > done > >>> > > > > > > > with > >>> > > > > > > > > > it > >>> > > > > > > > > > > > by now. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 4. (Fabrizio - PR SENT, but blocked by 1. and 2.) > >>> Move the > >>> > > > > SWF > >>> > > > > > > > Quarkus > >>> > > > > > > > > > > > Dev UI package from `kogito-apps` to `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-tools/pull/2167) > >>> > > > > > > > > > > > This can only be done after 1. and 2. are > >>> merged, since > >>> > > > > > this > >>> > > > > > > > move > >>> > > > > > > > > > > > will require `kie-tools` to be ready to build > >>> packages with > >>> > > > > > Java > >>> > > > > > > > 17, > >>> > > > > > > > > > > > Maven 3.9.6, and Quarkus 3. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 5. (Thiago - NOT YET STARTED) Move the BPMN > >>> Quarkus Dev UI > >>> > > > > > > package > >>> > > > > > > > > > > > from `kogito-apps` to `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/966 > >>> > > > ) > >>> > > > > > > > > > > > We'll follow the lead of Fabrizio's PR from > 4. > >>> That's > >>> > > > > > > > essentially > >>> > > > > > > > > > > > doing exactly the same thing for the BPMN Quarkus > >>> Dev UI > >>> > > > > > module. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 6. (Rodrigo - NOT YET STARTED) Change the Jenkins > >>> release > >>> > > > > jobs > >>> > > > > > to > >>> > > > > > > > > > > > include publishing both Quarkus Dev UI modules to > >>> Maven > >>> > > > > central > >>> > > > > > > as > >>> > > > > > > > > > > > part of the Apache release. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/964 > >>> > > > ) > >>> > > > > > > > > > > > Should be pretty straight-forward, as we > >>> already have > >>> > > > > > > > experience > >>> > > > > > > > > > > > doing this for other repos. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 7. (Thiago - NOT YET STARTED) Change the > ownership > >>> of > >>> > > > > > > > `task-console` > >>> > > > > > > > > > > > and `management-console` images from > >>> `kogito-images` to > >>> > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/963 > >>> > > > ) > >>> > > > > > > > > > > > KIE Tools already hosts and publishes several > >>> images, > >>> > > > and > >>> > > > > > > since > >>> > > > > > > > > > > > the content of those images will now be hosted at > >>> > > > > `kie-tools`, > >>> > > > > > we > >>> > > > > > > > can > >>> > > > > > > > > > > > only host them there. > >>> > > > > > > > > > > > This also means we'll get rid of the two > >>> Quarkus apps > >>> > > > [2] > >>> > > > > > > that > >>> > > > > > > > > > > > wrap both consoles' static assets. We could be > >>> wrong about > >>> > > > > the > >>> > > > > > > > purpose > >>> > > > > > > > > > > > of those apps, so if anyone has more information, > >>> please do > >>> > > > > > reach > >>> > > > > > > > out. > >>> > > > > > > > > > > > Otherwise, we'll skip the Quarkusification of > >>> those static > >>> > > > > > assets > >>> > > > > > > > and > >>> > > > > > > > > > > > we'll ship images with `httpd` directly, like we > >>> do for KIE > >>> > > > > > > > Sandbox. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 8. (Assignee TDB - NOT YET STARTED) Deleting > >>> everything > >>> > > > that > >>> > > > > > was > >>> > > > > > > > moved > >>> > > > > > > > > > > > to `kie-tools` from `kogito-apps`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/962 > >>> > > > ) > >>> > > > > > > > > > > > That will be the point where we actually get > >>> rid of the > >>> > > > > > > > circular > >>> > > > > > > > > > > > dependency and remove the blocker for the > release. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 9. (Assignee TDB - NOT YET STARTED) Adapt > >>> `kogito-examples` > >>> > > > > to > >>> > > > > > > all > >>> > > > > > > > the > >>> > > > > > > > > > > > changes we mentioned above. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/961 > >>> > > > ) > >>> > > > > > > > > > > > Kogito Examples keeps being part of the > >>> `drools` and > >>> > > > > > > `kogito-*` > >>> > > > > > > > > > > > stream, meaning that example modules won't be > able > >>> to use > >>> > > > > > neither > >>> > > > > > > > of > >>> > > > > > > > > > > > the Quarkus Dev UIs, as `kie-tools` is downstream > >>> in > >>> > > > relation > >>> > > > > > to > >>> > > > > > > > the > >>> > > > > > > > > > > > `drools` and `kogito-*` stream. > >>> > > > > > > > > > > > The same would be true for Management Console > >>> and Task > >>> > > > > > > Console > >>> > > > > > > > > > > > images, but for them, we can use the `daily-dev` > >>> tag we > >>> > > > > publish > >>> > > > > > > > daily > >>> > > > > > > > > > > > from `kie-tools@main`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 10. (Assignee TDB - NOT YET STARTED) Create some > >>> example > >>> > > > apps > >>> > > > > > > that > >>> > > > > > > > use > >>> > > > > > > > > > > > the Quarkus Dev UIs directly on the `examples` > >>> directory of > >>> > > > > > > > > > > > `kie-tools`. ( > >>> > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/959) > >>> > > > > > > > > > > > This is to serve the same purpose of packages > >>> that did > >>> > > > > that > >>> > > > > > > on > >>> > > > > > > > > > > > `kogito-examples`, but now hosted on `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Pheew! That's a lot of things to do, but it is > the > >>> result > >>> > > > of > >>> > > > > > two > >>> > > > > > > > > > > > intense weeks assessing and planning how we would > >>> address > >>> > > > > this > >>> > > > > > > > issue > >>> > > > > > > > > > > > in a way that the Apache KIE 10 release can be > >>> done in a > >>> > > > way > >>> > > > > > that > >>> > > > > > > > > > > > feels atomic to our users, who are ultimately the > >>> most > >>> > > > > > important > >>> > > > > > > > part > >>> > > > > > > > > > > > of the community. There's an open EPIC too at > >>> > > > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/967. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > I appreciate it if you reached this point, and > >>> hope you > >>> > > > feel > >>> > > > > > > > welcome > >>> > > > > > > > > > > > to contributing to solving this lengthy and > >>> historical > >>> > > > > problem > >>> > > > > > if > >>> > > > > > > > you > >>> > > > > > > > > > > > feel like doing so. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > I'll personally send updates to this thread every > >>> week, on > >>> > > > > > > Thursday > >>> > > > > > > > > > > > nights. Do not hesitate to contact me or any of > >>> the people > >>> > > > > > > > involved in > >>> > > > > > > > > > > > this effort if you have questions, or simply want > >>> to chat > >>> > > > > about > >>> > > > > > > it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Thanks a lot Alex, Paulo, Fabrizio, Thiago, > >>> Rodrigo, and > >>> > > > > others > >>> > > > > > > > that > >>> > > > > > > > > > > > somehow helped so far. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Kind regards, > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Tiago Bento > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > P.S.: You might've noticed we left Trusty out of > >>> the > >>> > > > picture > >>> > > > > > for > >>> > > > > > > > now. > >>> > > > > > > > > > > > Thiago is conducting an investigation to > >>> understand what > >>> > > > > would > >>> > > > > > be > >>> > > > > > > > the > >>> > > > > > > > > > > > best course of action for it. As much as we have > >>> plans to > >>> > > > > > revive > >>> > > > > > > > it, > >>> > > > > > > > > > > > right now our focus has to be on getting Apache > >>> KIE 10 out. > >>> > > > > We > >>> > > > > > > can > >>> > > > > > > > > > > > always rely on Git to bring it back in the > future, > >>> if we > >>> > > > > > > ultimately > >>> > > > > > > > > > > > decide that wiping out Trusty is the best > strategy > >>> for this > >>> > > > > > > moment. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > [1] > >>> https://github.com/apache/incubator-kie-tools/pull/691 > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > [2] > >>> > > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-apps/tree/main/task-console > >>> > > > > > > > > > > > and > >>> > > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-apps/tree/main/management-console > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > >>> > > > > >>> --------------------------------------------------------------------- > >>> > > > > > > > > > > > To unsubscribe, e-mail: > >>> [email protected] > >>> > > > > > > > > > > > For additional commands, e-mail: > >>> [email protected] > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > >>> --------------------------------------------------------------------- > >>> > > > > > > > > > To unsubscribe, e-mail: > [email protected] > >>> > > > > > > > > > For additional commands, e-mail: > >>> [email protected] > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > >>> --------------------------------------------------------------------- > >>> > > > > > > > To unsubscribe, e-mail: [email protected] > >>> > > > > > > > For additional commands, e-mail: [email protected] > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: [email protected] > >>> > For additional commands, e-mail: [email protected] > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> >
