Toni, thank you for your input but I don't think it's feasible nor worth the investment.
Tiago, fair points. Let's work together on a plan for the codebase removal, we don't need to rush. Now my points on the specifics: >>1. >>https://github.com/apache/incubator-kie-issues/issues/782 - IMHO this is a >>must-have feature that needs to be present on the new DMN Editor too. This is a controversial feature, not on the concept - but on the implementation. But for the sake of unblocking the new editor could use the same mechanism and a discussion for a more efficient solution could be discussed. One additional data point related to Import data types: import from java is a good thing, but several enterprises will have a centralized data type catalog already in place, import things like JSON Schema or XML Schema are probably as useful - if not even more useful - than Java import. >>2. >>https://github.com/apache/incubator-kie-issues/issues/171 - Also an >>important aspect that is currently only present on the DMN Editor (classic) I personally don't think this would be a blocker by any means. As pointed out in the issue, the old solution was limited and not efficient. Whatever solution for PDF/docs should take in account the whole project. >>3. I don’t think we have an issue for this particular problem, but as long >>as we don’t have a SceSim Editor working for DMN 1.5, IMHO we can’t force >>users to depend on the new DMN Editor only and be forced to opt-out of >>SceSim entirely. Isn't this already the current situation? Anyway... I also hope this will become a no-issue with the new SceSim in the bake.... On Fri, Dec 13, 2024 at 1:57 AM Toni Rikkola <trikk...@redhat.com> wrote: > > One option is to remove the codes and stop releasing the older editor > Then if we still want to provide the editor we import the older release. > > This of course depends on where the current uses are and if they support > this without causing dependency clashes. The DMN editor matches a DMN spec > and does not evolve along with the language like Drools editors have done, > causing the need to release the editor and the core at the same time. With > DMN in theory this would not be an issue. > > Toni > > On Fri, Dec 13, 2024 at 1:04 AM Tiago Bento <tiagobe...@apache.org> wrote: > > > I’m all for moving away from our GWT infrastructure, but I guess we have > > three important gaps to fill before we’re able to do that for the DMN > > Editor. > > > > 1. > > https://github.com/apache/incubator-kie-issues/issues/782 - IMHO this is a > > must-have feature that needs to be present on the new DMN Editor too. > > > > 2. > > https://github.com/apache/incubator-kie-issues/issues/171 - Also an > > important aspect that is currently only present on the DMN Editor (classic) > > > > 3. I don’t think we have an issue for this particular problem, but as long > > as we don’t have a SceSim Editor working for DMN 1.5, IMHO we can’t force > > users to depend on the new DMN Editor only and be forced to opt-out of > > SceSim entirely. > > > > Maybe we can layout a deprecation/removal plan for the next releases, > > provided we covered these three gaps I mentioned? > > > > Let me know what you think! > > > > Regards, > > > > Tiago Bento > > > > > > > > On Thu, Dec 12, 2024 at 7:30 PM Alex Porcelli <porce...@apache.org> wrote: > > > > > Following our 10.0.0 release, I propose removing the legacy GWT-based > > > DMN Editor from our codebase. We currently maintain two DMN editors in > > > parallel - our modern implementation and the legacy GWT version. > > > > > > Removing the legacy editor would simplify our codebase and reduce > > > maintenance overhead. The code would remain accessible through git > > > history if needed for reference. If accepted, we would complete this > > > removal before our next release. > > > > > > Please share your thoughts. > > > > > > - > > > Alex > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
