Thank you for bringing better visibility of the consequences, Gabriele. However, as pointed out, unfortunately the way the demo is currently setup - it has important restrictions with Apache policies.
In the end of the day, the general decision has been to allow the whole move forward, we accept small sacrifices. Of course, this could be solved if a different library/license is used to accomplish same results. On Thu, Nov 28, 2024 at 3:41 AM Gabriele Cardosi <[email protected]> wrote: > Hi all. > I see multiple approvals on this removal proposal (and I'm not even sure if > it is still active). > While I have no strong opinion on that, I would like to be sure that it is > fully clear, for everyone, that removing that bundle.js means, actually, > removing the "demo" itself. > The scope of that demo was to provide an easy and OOTB way to: > 1 pick any arbitrary dmn file > 2 send payload to jitdmn to validate it > 3 send payload to jitdmn to execute it with different values, providing an > automatically-generated form > > This can't simply be replaced by curl, first because it would be awfully > cumbersome to manually create the required payloads, and second because the > potential user of that demo could be non-techy users, maybe BA, or anyone > else that anyway does not have time or way to go through the console. > And, IMO, this is confirmed by the fact that the demo has not much of a > usage for us, as developers: I worked a lot on the jitdmn, and I used that > only once, because I, as "tech", do not need it. > > m2c > > Best > > Il giorno gio 28 nov 2024 alle ore 09:13 Yeser Amer <[email protected]> ha > scritto: > > > +1 > > > > On 2024/11/26 15:32:31 Jozef Marko wrote: > > > Hi everyone, we have an issue with licensing the 'bundle.js' file for > > the the Apache KIE 10 release, see the discussion here [1]. > > > > > > All this discussion brought me to an idea, do we really need this file? > > After my investigation, it is used only as the 'jitexecutor-runner' demo > > app available as 'localhost:8080/index.html' once you start 'java -jar > > jitexecutor-runner/target/quarkus-app/quarkus-run.jar'. > > > > > > There, you will have a simple webpage with two buttons: > > > > > > 'Choose file' button: > > > This button is for opening a model file. Internally, it calls > > 'fetchSchemaForm' from the 'bundle.js' autogenerates form fields for the > > selected model. > > > > > > 'Submit' button: > > > This is for model evaluation on the 'localhost:8080/jitdmn' endpoint. > It > > internally calls 'handleForm' from the bundle.js > > > > > > Possible actions: > > > > > > * > > > If we check the 'jitexecutor/README' we can do the same demo using > > 'curl' command, so if there is no heavy usage of the jitexecutor demo UI, > > we could remove it, and remove also 'bundle.js' from the codebase > > > * > > > We could re-implement 'Choose file' and 'Submit' button handlers > without > > the 'bundle.js' probably, as it is basically invoking a rest endpoint > with > > some payload, however for sure it is not so straight forward to > > autogenerate fields in the webpage. We do such autogeneration in > > 'kie-tools' project, what gives as some chance, it is doable as > 'kie-tools' > > does not use 'bundle.js' > > > * > > > We could simplify the option above, we could refactor the page, the > > 'Choose file' would load 'model' part of the payload for 'jitdmn' > endpoint, > > but the 'context' payload would user need to provide manually - ie. no > > schema reading and generating form fields by the demo app > > > * > > > maybe some other option ... > > > > > > What are your thoughts? Is it possible to remove 'bundle.js' from the > > codebase to solve the licensing issue? If yes, who to do it? Do some of > the > > options mentioned sound good for you? > > > > > > [1] > > > > > > https://github.com/apache/incubator-kie-kogito-apps/pull/2111/files#r1853279114 > > > > > > > > > Jozef Marko > > > > > > Software Developer > > > > > > [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
