I think this would be the case if the outside repository was not a reusable component, but specific for our needs. The linked mapper-xml project is used by the J2CL community. It was previously outside of KIE for this reason, but dragged in due to reasons and I can not remember the details.
It needs to be removed outside due to this license issue. This might apply to the entire j2cl-tools repo. By a quick look, nothing in that repo is specific to KIE and reusable by J2CL community. It might even need to be split into several repositories. I see Jakarta bits are under Eclipse Public License. GPL can "eat" Apache, not sure if it same goes for EPL. Toni On 2025/07/04 09:05:36 Alex Porcelli wrote: > My concern is that moving all GPL code into an outside repository > maintained by a committer might not be the right solution, as it gives > me the impression that we are using a shadow organization to solve > issues. > > I'd be cautious with such an option. > > - > Alex > > On Fri, Jul 4, 2025 at 3:57 AM Toni Rikkola <rikk...@apache.org> wrote: > > > > Any project using code from GPL becomes GPL. > > https://www.apache.org/licenses/GPL-compatibility.html > > > > However there is a linking exception. > > https://openjdk.org/legal/gplv2+ce.html > > https://en.wikipedia.org/wiki/GPL_linking_exception > > > > So the project maintained by Dmitrii is fine as a dependency, but it should > > change the license to GPL. It can not avoid copying GPL code, so it becomes > > a GPL licensed project. > > > > We are already linking that project on Java side. This would be the same > > for GWT/frontend side. > > > > Toni > > > > On 2025/07/03 17:16:23 Alex Porcelli wrote: > > > Dmitri, I’d argue that your library faces a similar issue to ours. While > > > on > > > the surface it may be labeled as ASL-licensed, it doesn’t take much > > > digging > > > to find source code under different licenses included within. > > > > > > Given that a member of Apache KIE maintains it, it could appear as a > > > workaround to the broader problem, essentially externalizing non-compliant > > > components to a shadow organization. > > > > > > On Thu, Jul 3, 2025 at 12:47 PM Dmitrii Tikhomirov > > > <dtikh...@redhat.com.invalid> wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > j2cl-tools/mapper-xml at main · kiegroup/j2cl-tools > > > > <https://github.com/kiegroup/j2cl-tools/tree/main/mapper-xml> > > > > github.com <https://github.com/kiegroup/j2cl-tools/tree/main/mapper-xml> > > > > [image: apple-touch-icon-180x180-a80b8e11abe2.png] > > > > <https://github.com/kiegroup/j2cl-tools/tree/main/mapper-xml> > > > > <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 > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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
