Unfortunately we confirmed that there's a dependency between
serverless-operator, images and kie-tools that invalidated this
proposal. (Thank you Dominik for bringing this up!)
With such circular dependency, we are back to the situation where the
Apache KIE 10 is BLOCKED.
A new proposal will be
Alright, lots to unpack here! Thank you so much for the interest in
this effort, and yeah, we won't escape a much broader conversation
about our structure in regards to poly- vs mono-repo, the CI builds,
topology and all that. Let me try to get everything cleared out for
this thread, though. Here
Ricardo, Eder and Community Members,
We definitely need to have a conversation about how best to deal with
our repositories and in general the whole codebase organization. I
think it's fair to say that it's not working well. We also consume
many times more computing resources that we should and
Yeah I forgot about the jars now in tools that we need in images. So I
guess the solution is to move everythign to one single monorepo. That might
be really tough to handle in the long run.
I hope I can learn how to pull specific folders from the monorepo then.
--
Ricardo Zanini Fernandes
Vida
Zanini,
On Thu, Mar 7, 2024 at 9:44 AM ricardo zanini fernandes <
ricardozan...@gmail.com> wrote:
> Hi! Apart from the kn-workflow, what else kie-tools depends on the images?
>
Paulo/Caponetto can elaborate more, but remember that in the past, we
stopped using tools for custom images to use
Hi Francisco,
thanks for clarification!
Best
Gabriele
Il giorno gio 7 mar 2024 alle ore 16:29 Francisco Javier Tirado Sarti <
ftira...@redhat.com> ha scritto:
> Hi Grabielle,
> There is not ,circular dependency between images and tooling. The subject
> makes reference to the removed circular
Hi Grabielle,
There is not ,circular dependency between images and tooling. The subject
makes reference to the removed circular dependency between apps and
tooling, that was resolver moving part of the stuff in apps to tooling.
One of the consequences of that move is that images now depends both
Hi! Apart from the kn-workflow, what else kie-tools depends on the images?
I'm asking because there's yet another problem. The operator depends on the
images and the kn-workflow depends on the operator. So yet another circular
dependency.
If only kn-workflows depends on the images, we can have
Alex,
In [1] I see that we are agreeing on the move and there will be an official
proposal
shared. Where is the proposal? I see only an announcement [2] that this is
in progress already.
This is not good imho, we need to learn from this and get better.
about the issue:
The proposed solution is
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
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
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 <
ftira...@redhat.com> wrote:
> Hi Tiago,
> Let's rewind a bit, if we ignore the kie and kogito name
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
Domink,
Seems that we already have the issue solved...
Regarding the proposal email, this initially was discussed and agreed
here [1] and the current thread [2] has been used for a detailed
execution plan (this thread should be HEADS UP and not ANNOUNCEMENT,
tho).
[1] -
Hi Alex,
this is the first time I see this plan in detail. Apologies, but I am
unable to find
any [PROPOSAL] related to this on the mailing list.
Could you please point me in the right direction?
In any case, I am not asking to revisit this move. I am for it, it is a
good move.
My goal is to
After a second thought, we need these features from kie-tools. If that's
the solution to move there, let's do it and release this.
But I'm struggling to find time to wrap up my own tasks, I'll need help,
won't have time atm.
Cheers!
On Wed, Mar 6, 2024 at 4:49 PM ricardo zanini fernandes <
Ok, so remove all the dependencies from the kie-tools in the images and we
figure out later how to include this features post-release.
-1 to add to kie-tools. The repo is complex enough now.
Cheers!
On Wed, Mar 6, 2024 at 3:02 PM Eder Ignatowicz wrote:
> Tiago, thanks for the detailed
Tiago, thanks for the detailed explanation.
As the kn-plugin workflow will always depend on the dev mode image and
eventually images will depend on tools artifacts, I would vote to move the
images for kie tools, remove the circular dependency, unblock the 10
release, and later we figure out if
Oops. Ended up mixing the references there.
The PR I'm referring to as [1] is
https://github.com/apache/incubator-kie-kogito-images/pull/1734
And the repo list I'm referring to as [1] is
https://github.com/orgs/apache/repositories?language==incubator-kie==all
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
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
Alex,
I'm not aware of any dependencies in KIE Tools for images.
On Wed, Mar 6, 2024 at 9:44 AM Alex Porcelli 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.
>
>
>
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 <
ricardozan...@gmail.com> wrote:
> Hi!
>
> A strong -1 from my side moving
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
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
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
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`
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
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
Hi Tiago,
It was a nice morning reading ;) Thanks for all the time invested on such
detailed writing.
@Ricardo Zanini @Walter Medvedeo
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.
Great news Tiago! Thank you for sharing the plan.
Regarding the Quarkus devui's move, I want to give awareness that I already
started the GAV's rinaming for all the Quarkus extensions and raised some
PR's to kogito-apps (which includes both sonataflow & jbpm Quarkus
devui's). Since the extensions
Thank you, Tiago, for starting this thread and sharing the context with a
detailed plan.
On Thu, Feb 22, 2024 at 8:29 PM Tiago Bento 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
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
33 matches
Mail list logo
