Thanks for the quick response. I'll do that with the planned kogito-docs PR
On Thu, Apr 18, 2024 at 12:50 PM Alex Porcelli <porce...@apache.org> wrote: > The idea is to have it surfaced somehow to user visibility- our overall > docs are not in a good shape, but looks like SonataFlow is relatively good > one. Maybe add a disclaimer to sonataflow docs about this and a readme file > would also help. > > - > Alex > > On Thu, Apr 18, 2024 at 6:43 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi, > > I agree with the constraints mentioned by Alex. Since the PR is ready to > > merge (green and approved), is it enough to have those constraints > written > > on this list or there is something else to be done? > > > > On Tue, Apr 16, 2024 at 8:50 PM Alex Porcelli <porce...@apache.org> > wrote: > > > > > Although it may look like a simple integration, we should also > > > evaluate the affinity between the technologies, as already pointed out > > > in this thread. There's a general agreement that DMN and SWF are for > > > different target audiences, and—besides being asked by a community > > > member—we don't necessarily need to implement "just because" without a > > > proper evaluation of the possible confusion that this might create. > > > > > > There's also the aspect related to procedures. Although small codebase > > > changes, introducing such integration between components that target > > > different abstraction layers would - at minimum a HEADS UP email so > > > this could be discussed before implemented. It has been mentioned in > > > the thread that this feature was discussed years ago... but neither > > > other members of the community nor I was in the room where this was > > > discussed, nor did we have minutes available with such information - > > > so we need to be thoughtful and use the proper Apache channels (ML!) > > > to communicate and discuss the direction of things. > > > > > > Personally, I find this integration to be a bit confusing. However, I > > > won't -1 if we clearly state that this is an experimental feature and > > > likely to be replaced in the future with a more suitable format, such > > > as yaml-based decision tables (if I recall correctly, such a format > > > was mentioned). > > > > > > - > > > Alex > > > > > > On Tue, Apr 16, 2024 at 2:34 PM Francisco Javier Tirado Sarti > > > <ftira...@redhat.com> wrote: > > > > > > > > The fact that the new SWF DMN module is optional is probably better > > > > perceived in the example PR > > > > < > > > > > > https://github.com/apache/incubator-kie-kogito-examples/pull/1906/files#diff-482ece0498351646309f2a00000bd4702c2aae92771e0abc79ff0c85abb8f197R79-R86 > > > >. > > > > Users will have to explicitly add the two linked modules in order to > > have > > > > the feature available in quarkus. > > > > > > > > > > > > > > > > On Tue, Apr 16, 2024 at 8:29 PM Francisco Javier Tirado Sarti < > > > > ftira...@redhat.com> wrote: > > > > > > > > > Hi Mark, > > > > > Yes, the new SWF DMN module is optional (this can be easily checked > > in > > > the > > > > > PR > > > > > < > > > > > > https://github.com/apache/incubator-kie-kogito-runtimes/pull/3468/files#diff-f770ef88ba3f52f02edbcf80521cd6e34959e819ec7da4169b55e38a5562b37f > > > > > > > > > ). > > > > > Besides that, we are going to work, as part of a proposal from > > > Enrique, to > > > > > pull out the RuleSetNodeInstance from the process engine core and > > move > > > it > > > > > to a different module. Once this is done, the DMN dependency will > > > indeed be > > > > > optional for SWF or any other parser built on top of the process > > > engine. > > > > > Currently, to avoid including DMN in the set of dependencies for > > SWF, > > > we > > > > > setted it to optional explicitly in the jbpm-flow pom > > > > > < > > > > > > https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/jbpm/jbpm-flow/pom.xml#L63 > > > > > > > > > (an approach that is a bit hacky and usually indicates you need to > > > improve > > > > > your design, as we are doing ;) ) > > > > > > > > > > On Tue, Apr 16, 2024 at 4:26 PM Mark Proctor <mdproc...@apache.org > > > > > wrote: > > > > > > > > > >> All workflow definitions need decision capabilities and will be > > > delegated > > > > >> to some subsystem or external system. > > > > >> > > > > >> I think decisioning is orthogonal enough to workflow (BPMN or SWF) > > > that we > > > > >> shouldn't be too worried, as long as it is not coupled in any way > > and > > > > >> fully > > > > >> optional. Also, the complexity (or technical burden) introduced by > > any > > > > >> integration is probably not at a level that I think anyone needs > to > > be > > > > >> overly concerned. Or at least we should ensure that any decision > > > > >> capability > > > > >> is optional, for the end-user, and the implementation is not > > creating > > > any > > > > >> long term burden. I don't believe the proposal is going against > > > anything > > > > >> I've said here. > > > > >> > > > > >> I do agree that I'm not sure DMN as a format is the best fit for > > SWF, > > > and > > > > >> I > > > > >> know Matteo did some POC work showing a format that was more > > aligned. > > > > >> However, that work isn't available yet and is currently paused; we > > > need to > > > > >> pick it back up again. In the meantime, as long as it's kept > > > optional I > > > > >> have no concerns if there is community demand for DMN with SWF > > > > >> > > > > >> Mark > > > > >> > > > > >> On Mon, 15 Apr 2024 at 16:01, Tibor Zimányi <tzima...@apache.org> > > > wrote: > > > > >> > > > > >> > Hi everyone, > > > > >> > > > > > >> > I noticed multiple discussions on Zulip and also a PR opened (1) > > > about > > > > >> > executing DMN from Sonataflow. I am opening this thread > (because I > > > > >> didn't > > > > >> > notice one), so we can discuss, if we want to do it. First of > > all, I > > > > >> want > > > > >> > to write, I am not against it. I just want us to be completely > > sure, > > > > >> that > > > > >> > it is what we want to do. Because from my perspective, it opens > > > multiple > > > > >> > other discussions about the KIE workflow portfolio. One of them > > > could > > > > >> be, > > > > >> > why we have two workflow engines in the KIE project, if we want > to > > > > >> execute > > > > >> > all file types from everywhere (I read discussions on Zulip > about > > > DRL > > > > >> being > > > > >> > executed from Sonataflow too). It could imply, that we need a > > > portfolio > > > > >> > consolidation and similar, because we are able to execute DMN > and > > > DRL > > > > >> from > > > > >> > the BPMN workflow engine. > > > > >> > > > > > >> > What are your opinions please? > > > > >> > > > > > >> > Best regards, > > > > >> > Tibor > > > > >> > > > > > >> > (1) > > > https://github.com/apache/incubator-kie-kogito-runtimes/pull/3468 > > > > >> > > > > > >> > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > >
