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 > >
