Yes, Im pretty sure these classes are used, but do we need to hold them in our repo? We cannot just download the jar on the fly (Im assuming somehow maven is not in place)?
On Thu, Jul 3, 2025 at 4:57 PM Alex Porcelli <a...@porcelli.me> wrote: > Francisco, > > Those classes are used by EMF in BPMN editor; Dashbuilder is also > impacted. Can't remove, feel free to try. > > On Thu, Jul 3, 2025 at 10:55 AM Francisco Javier Tirado Sarti > <ftira...@redhat.com.invalid> wrote: > > > > Im not sure GWT really requires this copy of these classes in the repo if > > they are still in rt.jar. > > So, this is the first thing to try (remove the java.xml clases and see > if > > DashBuilder is still working) > > If not, and this copy is really required in order GWT to work (which will > > be a surprise), then either we remove DashBuilder or we refactor > > Dashbuilder to not use GWT (which I bet is a big change) > > > > On Thu, Jul 3, 2025 at 4:51 PM Yeser Amer <ya...@apache.org> wrote: > > > > > As far I remember: > > > > > > Serverless Workflow Editor: Is not using GWT anymore, they migrated it > to > > > J2CL (Please correct me If I'm wrong) > > > > > > Classic DMN, Scesim, BPMN Editor: We are replacing them with > React-based > > > version, I guess we're in the path to remove them in the next few > months, > > > it depends on the maturity level of the new editors (DMN Editor is > indeed > > > the most mature one) > > > > > > DashBuilder: It is, in my opinion, the real blocker at this point. We > > > don't have any plan, committers and resources to remove GWT in > DashBuilder > > > and replace it with another technology. > > > > > > Yeser > > > > > > On 2025/07/03 14:31:27 Alex Porcelli wrote: > > > > - Who needs GWT? > > > > > > > > Whole dashbuilder, BPMN editor, Classic DMN editor, Serverless > editor... > > > etc > > > > > > > > - Can we take the GWT modules out and maintain them outside of KIE? > > > > > > > > -1 for this approach, this is not a good approach. It tries to hide > > > things.. > > > > > > > > Sure, we should have releases going.. but we need comply. So we need > fix. > > > > > > > > On Thu, Jul 3, 2025 at 10:24 AM Toni Rikkola <rikk...@apache.org> > wrote: > > > > > > > > > > Who needs GWT? > > > > > Can we take the GWT modules out and maintain them outside of KIE? > > > > > Does it have to be all GWT related code or just some of them? > > > > > > > > > > I know the answer is likely "we need to rewrite X and Y", but we > > > really should get the releases flowing. That means if a rewrite can be > done > > > in 2 months it is fine, longer than that we should give the modules the > > > boot. We can always take them back later. > > > > > > > > > > I say we release often, even if the releases are not perfect. Right > > > now Drools core could release monthly, but rest of the project is > slowing > > > things down. I do not mean this in a bad way, just an example, and > there > > > are no hard feelings about this from anyone. Just it is everyone's best > > > interest to release anything for users to try out as soon and often as > > > possible. > > > > > > > > > > Toni > > > > > > > > > > On 2025/07/03 14:05:03 Alex Porcelli wrote: > > > > > > This has been raised by PJ Fanning [1]. I haven't investigated > the > > > > > > details yet, but I wanted to give a heads-up to the community > > > members. > > > > > > > > > > > > It looks like we won't be able to have more releases until we get > > > rid of GWT. > > > > > > > > > > > > [1] - https://github.com/apache/incubator-kie-tools/issues/3196 > > > > > > > > > > > > - > > > > > > 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 > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >