Hi William, Thanks for reaching out with this proposal. We’ve been indeed short of contributors for Dashbuilder inside Apache KIE, and I guess being inside Apache KIE also hasn’t been so nice for it.
I’m all for letting it *intentionally* fade out inside KIE until it’s eventually replaced once we find a suitable candidate (very likely this fork under a new name you’re proposing!) One thing that concerns me, though, is the fact that we might run into a cyclic, dephased dependency relationship, should we try to depend on this new fork. For some reason, this subject seems to keep following me in the emails I send to Apache KIE’s mailing lists :) dashbuilder-components-* packages depend on our micro-frontends Multiplying Architecture core packages (envelope-bus and envelope), and I guess this dependency would be kept for this fork you’re proposing, given the architecture Dashbuilder has chosen to follow. If that’s indeed the case, and you intend to keep depending on these packages (for micro-frontend purposes), and we then decide to drop-in replace Dashbuilder with the new forked project, we (Apache KIE) would be always depending on a previous version of ourselves transitively via our dependency with this new Dashbuilder fork. Please note that these technical issues I’m talking about here are only for making it clear that Apache KIE might not be able to depend on this new forked Dashbuilder without creating a cyclic, dephased dependency relationship, as Apache KIE can either be an upstream or a downstream dependency relative to this new fork, not both. Apache KIE, from my perspective, currently is not able to move in the pace that you might be envisioning for Dashbuilder. And at the same time, without active contributors and component SMEs for Dashbuilder, and given its somewhat complex tech stack and size, the current active Apache KIE contributors might not be able to keep maintaining, evolving, and releasing Dashbuilder too. With all that said, and as a contributor to Apache KIE, I feel like forking or not forking is your individual choice… and I deeply appreciate you reaching out for us to think together about what’s the smoothest path moving forward. I’m always available for any additional conversations about this topic! Regards, Tiago Bento On Thu, Dec 12, 2024 at 2:48 PM William Siqueira <wsiqu...@redhat.com> wrote: > Hello, > > My name is William and I was a Dashbuilder contributor. > > We have been working with Dashbuilder for a while and we have a roadmap for > quite a few improvements and we wanted to make some changes to its core, > also build new projects having dashbuilder as the core of it. > > Having this said, it would be great to fork dashbuilder core to a new > project so it can evolve independently. By Dashbuilder core I mean the > following packages: > > * dashbuilder: The actual core with GWT and Errai > * dashbuilder-components-*: Dashbuilder micro front-end components and its > APIs > > The new fork will have a friendly license, which means that you should be > able to continue using it by just pointing dashbuilder-client[1] to the > package from the new project. All the other projects dependent on > dashbuilder would continue working (Kubesmarts, vscode extension, > dashboards and so on) with little or no change. > > Kindly let me know your thoughts about this. > > Thanks! > > [1] > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder-client/package.json#L26 > > -- > > William Siqueira > > Software Engineer > > Red Hat > > <https://www.redhat.com> > > M: +55-12997070488 > <https://red.ht/sig> >
