Thank you for reaching out, William! As Eder rightly pointed out, the community focus has been primarily on the core components. Unfortunately, this has left Dashbuilder unmaintained. This is an area of concern for me as the Dashbuilder codebase has remained untouched and is accumulating critical security vulnerabilities.
Rather than forking, an alternative solution would be to move it to a different organization, where it could receive the attention and care it deserves. Of course, such a move would require a community vote and, most importantly, approval from the Apache Software Foundation, as they currently own the brand and associated trademarks. I appreciate your efforts and interest in evolving Dashbuilder. I look forward to hearing the community's thoughts on this! P.S. I'm also forwarding this to the IPMC private mailing list for awareness and feasibility analysis. On Fri, Dec 13, 2024 at 2:05 AM Toni Rikkola <[email protected]> wrote: > > I see the benefits of a separate Dashbuilder. Having it under KIE if the > uses extend KIE use cases is not ideal. > > However the cyclic dependency issue is something that I would like to see a > plan for. Just due to the reason that KIE builds and releases need to be > made faster and more simple. This might take us in the wrong direction. > > Toni > > On Thu, Dec 12, 2024 at 8:30 PM Tiago Bento <[email protected]> wrote: > > > 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 <[email protected]> > > 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> > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
