[QUESTION] Removing Management Console usage from `incubator-kie-kogito-examples` examples

[Luiz Motta <lu...@gmail.com>]

I couldn't attend today's Apache KIE call, but I watched the recording.
Before the meeting, I was already preparing a PR to remove the Management
Console from incubator-kie-kogito-examples [1] to eliminate the kie-tools
dependency. However, after watching the call, I'm uncertain whether we
should proceed with the PR. I might have overlooked something during my
changes, but I believe this is the last remaining coupling to KIE Tools.
[1] https://github.com/apache/incubator-kie-kogito-examples/pull/2047

Re: [QUESTION] Removing Management Console usage from `incubator-kie-kogito-examples` examples

[Enrique Gonzalez Martinez <el...@gmail.com>]

I guess the main problem would be that our ci will take far longer to build
if we go for this pipeline in spite it is the right thing to do.
I am not sure if it is possible to somehow improve the CI time for this
case.

El lun, 13 ene 2025, 15:47, Gabriele Cardosi <ga...@gmail.com>
escribió:

> Hi all,
> I think we all agree on removing circular dependencies, of course.
> But, at the same time, we also have to understand why those circular
> dependencies exist, in first place, and solve the problem at its root.
> Beside that, and also this has been mentioned in the meeting, some people
> think that moving the examples inside kie-tools, and maybe "behind" a
> javascript stack, could make them harder to consume for java developers
> (that, probably, are our "target").
>
> It seems there is consensus that kogito-examples are/should be "starter"
> projects, and as such they should logically be the last one built in the
> chain.
> And, AFAIK, part of the problem lies in the examples depending on images,
> that currently are hosted inside kie-tools.
>
> In the last meeting there was an introductive mention to re-organize the
> repositories and, between them, have an image-specific one.
> The logic should be that repository organization should follow the
> architectural layers (which, by the way, is a pretty standard approach).
> With that in place, we could (grossly) have something like
>
> backend
> tooling
> images
> examples
>
>
> With that in place, the kogito-examples could depend on the images repo,
> without any issue, and, at first glance, the chain of dependency would have
> no need to do in a backward way.
> Of course, there must be a detail that I'm missing, so the last bit would
> be to understand (since it is circular) why kie-tools depend on
> kogito-examples (I'm sure it has been mentioned multiple times, but a
> one-line response would suffice to revive my old brain 😀 ), and then
> eventually address this properly.
>
> So, thanks Luiz for the PR, but as mentioned in the last meeting, maybe it
> is a high time to take small moment to reflect on the current status,
> analyze what choices lead to the problem we are discussing about (the
> circular dependency), how to best fix that once and for all, without ending
> up in a situation that maybe no-one (or very few) really wants, and
> focusing only on concrete and improcrastinabile issues - I mean broken CI,
> bugs, etc (and this one, IINW, is not one of them)
>
> Cheers
>
> :)
>
>
> Il giorno ven 10 gen 2025 alle ore 21:21 Tiago Bento <
> tiagobento@apache.org>
> ha scritto:
>
> > Luiz,
> >
> > All example modules depending on 1st party dependencies on kie-tools,
> > should either be updated to not depend on them anymore (removing a
> circular
> > dependency), removed, or moved to kie-tools, IMHO.
> >
> > It seems that there’s no consensus to migrate ALL examples to kie-tools,
> > but I guess no one is opposing fixing the circular dependencies we have
> on
> > kogito-examples.
> >
> > My opinion is to keep the PR, allowing modules on kogito-examples to
> > exclusively reference dependencies coming from drools, optaplanner,
> > kogito-runtimes, and kogito-apps.
> >
> > I’m not against creating new examples on kie-tools too, if Quarkus Dev
> UIs,
> > Editors, or container images are central pieces of a particular example
> > application we might have.
> >
> > I’m always available for reviewing PRs and helping anyone willing to
> > contribute new packages (examples or not) to kie-tools.
> >
> > Regards,
> >
> > Tiago Bento
> >
> >
> > On Fri, Jan 10, 2025 at 4:52 PM Luiz Motta <lu...@gmail.com>
> > wrote:
> >
> > > I couldn't attend today's Apache KIE call, but I watched the recording.
> > > Before the meeting, I was already preparing a PR to remove the
> Management
> > > Console from incubator-kie-kogito-examples [1] to eliminate the
> kie-tools
> > > dependency. However, after watching the call, I'm uncertain whether we
> > > should proceed with the PR. I might have overlooked something during my
> > > changes, but I believe this is the last remaining coupling to KIE
> Tools.
> > > [1] https://github.com/apache/incubator-kie-kogito-examples/pull/2047
> > >
> >
>

Re: [QUESTION] Removing Management Console usage from `incubator-kie-kogito-examples` examples

[Gabriele Cardosi <ga...@gmail.com>]

Hi all,
I think we all agree on removing circular dependencies, of course.
But, at the same time, we also have to understand why those circular
dependencies exist, in first place, and solve the problem at its root.
Beside that, and also this has been mentioned in the meeting, some people
think that moving the examples inside kie-tools, and maybe "behind" a
javascript stack, could make them harder to consume for java developers
(that, probably, are our "target").

It seems there is consensus that kogito-examples are/should be "starter"
projects, and as such they should logically be the last one built in the
chain.
And, AFAIK, part of the problem lies in the examples depending on images,
that currently are hosted inside kie-tools.

In the last meeting there was an introductive mention to re-organize the
repositories and, between them, have an image-specific one.
The logic should be that repository organization should follow the
architectural layers (which, by the way, is a pretty standard approach).
With that in place, we could (grossly) have something like

backend
tooling
images
examples


With that in place, the kogito-examples could depend on the images repo,
without any issue, and, at first glance, the chain of dependency would have
no need to do in a backward way.
Of course, there must be a detail that I'm missing, so the last bit would
be to understand (since it is circular) why kie-tools depend on
kogito-examples (I'm sure it has been mentioned multiple times, but a
one-line response would suffice to revive my old brain 😀 ), and then
eventually address this properly.

So, thanks Luiz for the PR, but as mentioned in the last meeting, maybe it
is a high time to take small moment to reflect on the current status,
analyze what choices lead to the problem we are discussing about (the
circular dependency), how to best fix that once and for all, without ending
up in a situation that maybe no-one (or very few) really wants, and
focusing only on concrete and improcrastinabile issues - I mean broken CI,
bugs, etc (and this one, IINW, is not one of them)

Cheers

:)


Il giorno ven 10 gen 2025 alle ore 21:21 Tiago Bento <ti...@apache.org>
ha scritto:

> Luiz,
>
> All example modules depending on 1st party dependencies on kie-tools,
> should either be updated to not depend on them anymore (removing a circular
> dependency), removed, or moved to kie-tools, IMHO.
>
> It seems that there’s no consensus to migrate ALL examples to kie-tools,
> but I guess no one is opposing fixing the circular dependencies we have on
> kogito-examples.
>
> My opinion is to keep the PR, allowing modules on kogito-examples to
> exclusively reference dependencies coming from drools, optaplanner,
> kogito-runtimes, and kogito-apps.
>
> I’m not against creating new examples on kie-tools too, if Quarkus Dev UIs,
> Editors, or container images are central pieces of a particular example
> application we might have.
>
> I’m always available for reviewing PRs and helping anyone willing to
> contribute new packages (examples or not) to kie-tools.
>
> Regards,
>
> Tiago Bento
>
>
> On Fri, Jan 10, 2025 at 4:52 PM Luiz Motta <lu...@gmail.com>
> wrote:
>
> > I couldn't attend today's Apache KIE call, but I watched the recording.
> > Before the meeting, I was already preparing a PR to remove the Management
> > Console from incubator-kie-kogito-examples [1] to eliminate the kie-tools
> > dependency. However, after watching the call, I'm uncertain whether we
> > should proceed with the PR. I might have overlooked something during my
> > changes, but I believe this is the last remaining coupling to KIE Tools.
> > [1] https://github.com/apache/incubator-kie-kogito-examples/pull/2047
> >
>

Re: [QUESTION] Removing Management Console usage from `incubator-kie-kogito-examples` examples

[Tiago Bento <ti...@apache.org>]

Luiz,

All example modules depending on 1st party dependencies on kie-tools,
should either be updated to not depend on them anymore (removing a circular
dependency), removed, or moved to kie-tools, IMHO.

It seems that there’s no consensus to migrate ALL examples to kie-tools,
but I guess no one is opposing fixing the circular dependencies we have on
kogito-examples.

My opinion is to keep the PR, allowing modules on kogito-examples to
exclusively reference dependencies coming from drools, optaplanner,
kogito-runtimes, and kogito-apps.

I’m not against creating new examples on kie-tools too, if Quarkus Dev UIs,
Editors, or container images are central pieces of a particular example
application we might have.

I’m always available for reviewing PRs and helping anyone willing to
contribute new packages (examples or not) to kie-tools.

Regards,

Tiago Bento


On Fri, Jan 10, 2025 at 4:52 PM Luiz Motta <lu...@gmail.com> wrote:

> I couldn't attend today's Apache KIE call, but I watched the recording.
> Before the meeting, I was already preparing a PR to remove the Management
> Console from incubator-kie-kogito-examples [1] to eliminate the kie-tools
> dependency. However, after watching the call, I'm uncertain whether we
> should proceed with the PR. I might have overlooked something during my
> changes, but I believe this is the last remaining coupling to KIE Tools.
> [1] https://github.com/apache/incubator-kie-kogito-examples/pull/2047
>