It is both a stub and not, it has some parts that are identical. Since that is how you would write the code for the solution. Looking at the current source it is clear we have a copy & paste with few changes.
Comparing the two files we are almost 1:1. Our version has the unneeded methods commented out, but even the comments are clear copy of the source. For an easy fix. I suspect javax.xml.XMLGregorianCalendar name, package and even partial implementation break a license. Not sure how this works, since when writing unit tests for example, you might do a dummy implementation of a class. Is that still a problem? Then there are other tricks. We can generate a file that matches all these requirements for the compiler. We could download the real source. Filter the methods out we do not want, replace the ones we need to replace and write a temp file for the GWT compiler. Problem is I do not know what is good enough. Toni On 2025/07/03 15:16:29 Francisco Javier Tirado Sarti wrote: > Hmm, if it is not a copy, but a stub to make GWT work, why is this a > license issue at all? > > On Thu, Jul 3, 2025 at 5:08 PM Toni Rikkola <rikk...@apache.org> wrote: > > > One of the files is XMLGregorianCalendar. > > > > > > https://stackoverflow.com/questions/26803294/how-to-write-a-gwt-customserializer-for-xmlgregoriancalendar > > > > The implementation we have here (falsely claims it is under Apache license) > > > > > > https://github.com/apache/incubator-kie-tools/blob/b6658df8b9f187c0c5fdecfc6517a640d823823f/packages/stunner-editors/kie-wb-common-stunner/kie-wb-common-stunner-sets/kie-wb-common-stunner-bpmn/kie-wb-common-stunner-bpmn-emf/src/main/java/org/eclipse/emul/javax/xml/datatype/XMLGregorianCalendar.java#L21 > > > > Is used since without it GWT can not compile. There is no version of it in > > GWT source. GWT needs a class with that name from that package and with > > each method implemented that our files use. And that implementation is > > licensed under another source. > > > > The XMLGregorianCalendar we have is not a copy of the original. It is our > > version that works once GWT has compiled, but I am not sure if that is > > enough to get rid of the copyright/licensing issue. > > > > Toni > > > > On 2025/07/03 15:06:29 Alex Porcelli wrote: > > > "Ok, and there is not any hook we can use to download the source files > > from > > > their original repo before GWT analyzes the source?" > > > > > > This needs to be investigated; it sounds possible. Someone needs to > > > take on this investigation and, if possible, make all necessary > > > adjustments throughout the codebase. > > > > > > On Thu, Jul 3, 2025 at 11:04 AM Francisco Javier Tirado Sarti > > > <ftira...@redhat.com.invalid> wrote: > > > > > > > > Ok, and there is not any hook we can use to download the source files > > from > > > > their original repo before GWT analyzes the source? > > > > > > > > On Thu, Jul 3, 2025 at 5:03 PM Alex Porcelli <a...@porcelli.me> wrote: > > > > > > > > > For transpiler it requires the source; GWT do not use binaries as > > source of > > > > > transpilation. > > > > > > > > > > > > > > > - > > > > > Alex > > > > > > > > > > > > > > > On Thu, Jul 3, 2025 at 11:00 AM Francisco Javier Tirado Sarti > > > > > <ftira...@redhat.com.invalid> wrote: > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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
