If the problem lies with the EMF marshaller, we can migrate to an annotation-based XML marshaller that’s compatible with the JRE/J2CL/GWT I support
https://github.com/kiegroup/j2cl-tools/tree/main/mapper-xml > On Jul 3, 2025, at 8:35 AM, Toni Rikkola <rikk...@apache.org> wrote: > > I hope we have the experts to give a more detailed answer, but the goal has > been to have one parser on both ends. Client and server. I suspect that is > the case here. > > So that gives us another solution. Using different one on client side. > > Also finding a solution is one thing. Another is finding someone to implement > it. > > Toni > > On 2025/07/03 15:26:49 Francisco Javier Tirado Sarti wrote: >> Hi, >> Im lacking context, but why these classes are even needed if GWT has a >> dedicated xml parser? >> >> On Thu, Jul 3, 2025 at 5:24 PM Toni Rikkola <rikk...@apache.org> wrote: >> >>> 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 >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org >
