Hi, I agree with you. It is crystal clear what is bpmn, what is rules and what is serverless workflow. I just wanted to clarify what is not clear. And what is not clear, in my opinion, is the meaning of supporting service. And I think the example I mention still stands. Persistence is mentioned as supporting service and messaging is not, why? I hardly see persistence being more important than the possibility of starting a process through an event (something that cannot be done if the messaging addon is not there as dependency). Therefore, as a tentative, I proposed to use the distinction between microservice (because even if data index is deployed embedded, it is still conceptually a microservice) vs infrastructure service as a criteria to rename addos as Kie vs Kogito. Or we can just avoid that distinction at all and just rename as kie all addons that are not specific to drools, jbpm or sonataflow.
On Tue, Feb 6, 2024 at 9:35 AM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > Hi Francisco, > > For the sake of moving things forward, probably the best way to > address your disagreement with Kris on this would be for you to > provide some feedback regarding his approach (where your discrepancy > lies) > This will lead: > > 1. remove the focus of just a few components and move again to a more > general criteria > 2. A common criteria for the current modules and future ones. > 3. Discuss things in a more broad scope vs discuss element by element > that could drag too much the conversation. > 4. With a common criteria we can discuss things elements because we > have already a judgement of how things should be named. > > The current criteria proposed by Kris is this one: > > Drools: for anything related to rules, > jBPM: for everything related to business processes (BPMN2), > SonataFlow: for everything related to Serverless Workflow, > Kogito: for supporting services like persistence, data index and job > service, and > Kie: just for anything that does not fit in other categories. > > I would point out few things: > * This criteria does not take into account how elements are being > deployed (collocated or microservice); in fact most of the have a dual > nature like data index, audit, jobs, etc... (this is independent of > what will be our recomendations in prod environments) > * The criteria is not taking into account how dependencies are working > together. For instance jobs or persistence are something that the > engine requires to work 100 % but we can compromise that in some > scenarios might not be needed; like for instance STP or workflows that > don't require timers. > * The criteria takes into account functionality offered as a priority. > * The criteria is not taking into account the dependency with other > tiers (like database, brokers, streams....) > > I would suggest you should take the criteria and try to refine it to > your best of your abilities so we can see exactly where the > disagreement lies and Kris (and other people) can engage in the > differences and how to reach a middleground. > > > El lun, 5 feb 2024 a las 20:15, Francisco Javier Tirado Sarti > (<ftira...@redhat.com>) escribió: > > > > Enrique, > > Iḿ afraid is not that clear, at least for me. > > Which definition of supporting service are we using to consider > persistence > > addons ( a java library essentially) a supporting service and not > > messaging addons (another java library)? > > In other words, and being redundant just in case, if in Kris e-mail he > had > > not put persistence together with data index and jobs, I would agree the > > criteria is crystal clear, because data index and job services (as being > > microservices) belong to a different group than messaging and other > addons, > > which are essentially optional java libraries that can be added as > > dependencies on the example poms. According to that rationale, it can be > > argued that persistence addons belongs to the second group, unless Kris > was > > referring to the database server and not the persistence addon (please > note > > the similar relation between persistence addons with the db server and > > messaging addon with the event broker) > > > > On Mon, Feb 5, 2024 at 7:26 PM Enrique Gonzalez Martinez < > > egonza...@apache.org> wrote: > > > > > +1 to kris approach > > > The criteria is well defined and make sense. The only maybe point of > > > discussion would be jobs as it needs to be there to get the fully > > > functional workflow engine. > > > > > > El lun, 5 feb 2024, 18:11, ricardo zanini fernandes < > > > ricardozan...@gmail.com> > > > escribió: > > > > > > > +1, Javi > > > > > > > > On Mon, Feb 5, 2024 at 12:58 PM Francisco Javier Tirado Sarti < > > > > ftira...@redhat.com> wrote: > > > > > > > > > I think is better to consider messaging, persistence, marshallers > and > > > so > > > > on > > > > > infrastructure (kogito or kie) and data-index and jobs as > supporting > > > > > services ( kogito o kie), if we want to do the distinction into > > > libraries > > > > > that are added to a microservice as addon (infra) and microservices > > > that > > > > > are not mandatory but heavily recommended to have all functionality > > > (job > > > > > service and data index service) > > > > > > > > > > On Mon, Feb 5, 2024 at 4:54 PM Francisco Javier Tirado Sarti < > > > > > ftira...@redhat.com> wrote: > > > > > > > > > > > Hi Kris, sounds good, but I have a question why is persistence > > > > considered > > > > > > a supporting service and messaging is not?. > > > > > > > > > > > > On Mon, Feb 5, 2024 at 4:44 PM Kris Verlaenen < > > > > kris.verlae...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> All, > > > > > >> > > > > > >> Here's a slightly modified proposal to take the feedback so far > into > > > > > >> account: the suggestion is to use Drools for anything related to > > > > rules, > > > > > >> jBPM for everything related to business processes (BPMN2), > > > SonataFlow > > > > > for > > > > > >> everything related to Serverless Workflow, Kogito for supporting > > > > > services > > > > > >> like persistence, data index and job service, and kie just for > > > > anything > > > > > >> that doesn't fit any or does fit all of the other categories. > > > > > >> > > > > > >> I added a counter-proposal to the document in a column D in the > same > > > > > >> spreadsheet: > > > > > >> > > > > > >> > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1gsttRcXGtwGQO469EYFDhLxJLEA7Kl3gmioR6XhGhjY/edit#gid=0 > > > > > >> > > > > > >> Please let us know what you think. > > > > > >> > > > > > >> Thx, > > > > > >> Kris > > > > > >> > > > > > >> > > > > > >> On Tue, Oct 31, 2023 at 6:45 PM Alex Porcelli <a...@porcelli.me > > > > > > wrote: > > > > > >> > > > > > >> > Ricardo, > > > > > >> > > > > > > >> > One concern that I have with the proposed renames is the > complete > > > > > >> > vanish of the Kogito brand. Although I always agreed that we > need > > > to > > > > > >> > reposition the brands, I also have concerns to basically make > one > > > of > > > > > >> > them - that got some decent public coverage in recent years - > > > > > >> > completely disappear. > > > > > >> > > > > > > >> > My suggestion is to revisit the list and get some components > to > > > keep > > > > > >> > the Kogito brand. My inital suggestion are persistence, > data-index > > > > and > > > > > >> > job scheduler components to be kept under Kogito. > > > > > >> > > > > > > >> > I also see some components that are planned to be removed like > > > PMML, > > > > > >> > Tracing and Predictions that I don't get why. > > > > > >> > > > > > > >> > On Tue, Oct 24, 2023 at 2:42 PM ricardo zanini fernandes > > > > > >> > <ricardozan...@gmail.com> wrote: > > > > > >> > > > > > > > >> > > Alex, > > > > > >> > > > > > > > >> > > As discussed here's the spreadsheet: > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1gsttRcXGtwGQO469EYFDhLxJLEA7Kl3gmioR6XhGhjY/edit#gid=0 > > > > > >> > > (anyone can edit) > > > > > >> > > > > > > > >> > > It contains only the Quarkus Add-ons for now, I'll add the > > > > remaining > > > > > >> > > libraries tomorrow if we all agree with this format. > > > > > >> > > > > > > > >> > > @Jason, we decided to table this discussion for now. We > need to > > > > > rename > > > > > >> > > Kogito SW, and other add-ons to reflect the implementation > to > > > > > >> release. We > > > > > >> > > won't add Apache prefix anywhere at this time. > > > > > >> > > > > > > > >> > > Cheers! > > > > > >> > > -- > > > > > >> > > > > > > > >> > > > > > > > >> > > On Mon, Oct 23, 2023 at 11:17 AM Jason Porter < > > > > > >> lightguar...@apache.org> > > > > > >> > > wrote: > > > > > >> > > > > > > > >> > > > I just checked > https://groovy.apache.org/download.html#distro > > > > and > > > > > >> it > > > > > >> > does > > > > > >> > > > look like Groovy has moved all of their GAV to > > > > org.apache.groovy. > > > > > At > > > > > >> > some > > > > > >> > > > point we'll need to do the same thing. > > > > > >> > > > > > > > > >> > > > On 2023/10/23 14:01:12 Jason Porter wrote: > > > > > >> > > > > I missed some of this discussion as I was out on > Friday. We > > > > > should > > > > > >> > look > > > > > >> > > > at what Groovy has done. They’re probably the biggest > project > > > > that > > > > > >> is > > > > > >> > in a > > > > > >> > > > similar space (Java, Maven, number of artifacts, etc.) to > us > > > and > > > > > has > > > > > >> > moved > > > > > >> > > > over. I suggest we follow what they have done. > > > > > >> > > > > > > > > > >> > > > > -- > > > > > >> > > > > Jason Porter > > > > > >> > > > > Software Engineer > > > > > >> > > > > He/Him/His > > > > > >> > > > > > > > > > >> > > > > IBM > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > From: ricardo zanini fernandes <ricardozan...@gmail.com > > > > > > > >> > > > > Date: Friday, October 20, 2023 at 13:53 > > > > > >> > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > >> > > > > Subject: [EXTERNAL] Re: [PROPOSAL] Renaming Kogito SW > > > > artifacts > > > > > to > > > > > >> > > > KIE/SonataFlow > > > > > >> > > > > As discussed offline, I'm gonna create a spreadsheet > with > > > the > > > > > >> > renaming > > > > > >> > > > > proposition and share it in this thread. > > > > > >> > > > > > > > > > >> > > > > We table the discussion about `apache` prefixing in > > > > > GAV/namespaces > > > > > >> > for > > > > > >> > > > now. > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > On Fri, Oct 20, 2023 at 2:20 PM Alex Porcelli < > > > > > >> porce...@apache.org> > > > > > >> > > > wrote: > > > > > >> > > > > > > > > > >> > > > > > You have a point in regarding the change of all GAVs. > > > > > >> > > > > > > > > > > >> > > > > > My suggestion is to table that discussion for now, > work on > > > > the > > > > > >> > > > inventory > > > > > >> > > > > > and proposed changes. Once we have it done, we may > start a > > > > new > > > > > >> > thread > > > > > >> > > > about > > > > > >> > > > > > GAVs. > > > > > >> > > > > > > > > > > >> > > > > > Wdyt? > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > On Fri, Oct 20, 2023 at 1:07 PM ricardo zanini > fernandes < > > > > > >> > > > > > ricardozan...@gmail.com> wrote: > > > > > >> > > > > > > > > > > >> > > > > > > Alex, I can create and share this spreadsheet, so > we can > > > > > start > > > > > >> > > > working on > > > > > >> > > > > > > it. > > > > > >> > > > > > > > > > > > >> > > > > > > IMHO, we shouldn't start adding apache prefixes in > some > > > > > >> > components > > > > > >> > > > and > > > > > >> > > > > > not > > > > > >> > > > > > > in others. > > > > > >> > > > > > > If we ought to add it, I'd rather add everything at > > > once. > > > > > >> > > > > > > > > > > > >> > > > > > > -- > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > On Fri, Oct 20, 2023 at 1:58 PM Alex Porcelli < > > > > > >> a...@porcelli.me> > > > > > >> > > > wrote: > > > > > >> > > > > > > > > > > > >> > > > > > > > Ricardo, > > > > > >> > > > > > > > > > > > > >> > > > > > > > Besides the SonataFlow proposed changes, Mario > already > > > > > >> > mentioned a > > > > > >> > > > > > > similar > > > > > >> > > > > > > > change in Drools, and we'll need similar > adjustments > > > for > > > > > >> jBPM. > > > > > >> > We > > > > > >> > > > > > should > > > > > >> > > > > > > > collectively create a spreadsheet to be shared in > this > > > > > >> thread > > > > > >> > with > > > > > >> > > > an > > > > > >> > > > > > > > inventory of the extensions we have with the > suggested > > > > > >> change; > > > > > >> > we > > > > > >> > > > look > > > > > >> > > > > > to > > > > > >> > > > > > > > this in a more comprehensive approach other than > local > > > > to > > > > > >> > > > SonataFlow. > > > > > >> > > > > > > > > > > > > >> > > > > > > > Regarding the use of the Apache prefix, even if > we are > > > > not > > > > > >> > > > necessarily > > > > > >> > > > > > > > required to adopt it right away, it's inevitable > that > > > > > we'll > > > > > >> > have to > > > > > >> > > > > > start > > > > > >> > > > > > > > using it at some point. Given that we're already > > > > > discussing > > > > > >> a > > > > > >> > reset > > > > > >> > > > > > with > > > > > >> > > > > > > > 10.x, it would help to make the message even more > > > > apparent > > > > > >> and > > > > > >> > > > sharper > > > > > >> > > > > > to > > > > > >> > > > > > > > incorporate the Apache prefix in the proposed > changes > > > > that > > > > > >> > we'll > > > > > >> > > > have > > > > > >> > > > > > in > > > > > >> > > > > > > > the spreadsheet. > > > > > >> > > > > > > > > > > > > >> > > > > > > > To be more clear and precise, the Apache prefix is > > > > > expected > > > > > >> to > > > > > >> > be > > > > > >> > > > > > > > incorporated only into the components in the > > > spreadsheet > > > > > AND > > > > > >> > > > nothing > > > > > >> > > > > > > else, > > > > > >> > > > > > > > so no complete change of GAVs or namespaces. > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > On Fri, Oct 20, 2023 at 8:51 AM ricardo zanini > > > > fernandes < > > > > > >> > > > > > > > ricardozan...@gmail.com> wrote: > > > > > >> > > > > > > > > > > > > >> > > > > > > > > Hi Jason! Are we required to change > namespaces/GAV > > > to > > > > > >> include > > > > > >> > > > > > `apache`? > > > > > >> > > > > > > > I'd > > > > > >> > > > > > > > > instead do this simple change now since we must > move > > > > on > > > > > >> with > > > > > >> > > > > > > SonataFlow, > > > > > >> > > > > > > > > and then rethink all modules to include > > > > "org.apache.kie" > > > > > >> > prefix. > > > > > >> > > > > > > > Honestly, > > > > > >> > > > > > > > > if we are not required, I'd keep the naming we > have > > > > > today. > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > -- > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > On Fri, Oct 20, 2023 at 12:54 AM Jason Porter > > > > > >> > > > > > <jpor...@ibm.com.invalid > > > > > >> > > > > > > > > > > > > >> > > > > > > > > wrote: > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > We don’t have to rename current code, but new > code > > > > > will > > > > > >> > need > > > > > >> > > > to be > > > > > >> > > > > > > > > > org.apache (sonataflow is probably fine). I > was > > > > > >> thinking if > > > > > >> > > > we’re > > > > > >> > > > > > > going > > > > > >> > > > > > > > > to > > > > > >> > > > > > > > > > rename packages group id now, we might as well > > > make > > > > it > > > > > >> > Apache > > > > > >> > > > and > > > > > >> > > > > > > only > > > > > >> > > > > > > > do > > > > > >> > > > > > > > > > it once. > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > -- > > > > > >> > > > > > > > > > Jason Porter > > > > > >> > > > > > > > > > Software Engineer > > > > > >> > > > > > > > > > He/Him/His > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > IBM > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > From: ricardo zanini fernandes < > > > > > ricardozan...@gmail.com > > > > > >> > > > > > > >> > > > > > > > > > Date: Thursday, October 19, 2023 at 11:47 > > > > > >> > > > > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > >> > > > > > > > > > Subject: [EXTERNAL] Re: [PROPOSAL] Renaming > Kogito > > > > SW > > > > > >> > > > artifacts to > > > > > >> > > > > > > > > > KIE/SonataFlow > > > > > >> > > > > > > > > > We have org.drools, org.jbpm, hence > > > org.sonataflow. > > > > > >> Can't > > > > > >> > we > > > > > >> > > > keep > > > > > >> > > > > > > this > > > > > >> > > > > > > > > > ubiquity? org.kie.apache.sonataflow is too > large, > > > > IMO. > > > > > >> If > > > > > >> > we > > > > > >> > > > go for > > > > > >> > > > > > > > > > org.apache.sonataflow, then maybe renaming > > > > everything > > > > > >> else > > > > > >> > to > > > > > >> > > > > > follow > > > > > >> > > > > > > > the > > > > > >> > > > > > > > > > same pattern? > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > On Thu, Oct 19, 2023 at 2:30 PM Jason Porter < > > > > > >> > > > > > > lightguar...@apache.org> > > > > > >> > > > > > > > > > wrote: > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > I'm +0 on this. > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > If we're going to rename it to SonataFlow, > > > should > > > > we > > > > > >> not > > > > > >> > > > make it > > > > > >> > > > > > > > > > > org.apache.kie.sonataflow or something > similar > > > > under > > > > > >> the > > > > > >> > > > Apache > > > > > >> > > > > > > name? > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > On 2023/10/19 12:42:53 ricardo zanini > fernandes > > > > > wrote: > > > > > >> > > > > > > > > > > > Friends, > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Since we moved from "Kogito Serverless > > > Workflow" > > > > > to > > > > > >> > > > > > "SonataFlow" > > > > > >> > > > > > > > > > project > > > > > >> > > > > > > > > > > > I'd like to propose a naming change to > those > > > > > >> artifacts > > > > > >> > > > > > targeting > > > > > >> > > > > > > > > 10.x. > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Some are *only* related to SW which is > > > > > >> implementation > > > > > >> > > > > > specifics. > > > > > >> > > > > > > We > > > > > >> > > > > > > > > can > > > > > >> > > > > > > > > > > > change to SonataFlow, for example: > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Description Extension Target > > > > > >> > > > > > > > > > > > Runtime development tools for SonataFlow > > > > > >> > > > > > > > > > > > > > > > > >> org.kie.kogito:kogito-quarkus-serverless-workflow-devui > > > > > >> > > > > > > > > > > > org.sonataflow:sonataflow-quarkus-devui > > > > > >> > > > > > > > > > > > SonataFlow Add-On - Includes OpenApi > Client, > > > the > > > > > >> > Process > > > > > >> > > > > > engine, > > > > > >> > > > > > > > and > > > > > >> > > > > > > > > > > > Knative Eventing capabilities > > > > > >> > > > > > > > > > > > > > > > org.kie.kogito:kogito-quarkus-serverless-workflow > > > > > >> > > > > > > > > > > > org.sonataflow:sonataflow-quarkus > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Another renaming is targeting Kogito > Quarkus > > > > > Add-Ons > > > > > >> > to KIE > > > > > >> > > > > > > Quarkus > > > > > >> > > > > > > > > > > Add-Ons > > > > > >> > > > > > > > > > > > for generic proposes (works for > SonataFlow, > > > > jBPM, > > > > > >> > Drools, > > > > > >> > > > etc). > > > > > >> > > > > > > For > > > > > >> > > > > > > > > > > example: > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Description Extension Target > > > > > >> > > > > > > > > > > > KIE Data Index Infinispan Add-On > > > > > >> > > > > > > > > > > > > > > > > >> > org.kie.kogito:kogito-addons-quarkus-data-index-infinispan > > > > > >> > > > > > > > > > > > > > > org.kie:kie-addons-quarkus-data-index-infinispan > > > > > >> > > > > > > > > > > > KIE Data Index In-memory Add-On > > > > > >> > > > > > > > > > > > > > > > > >> > org.kie.kogito:kogito-addons-quarkus-data-index-inmemory > > > > > >> > > > > > > > > > > > > org.kie:kie-addons-quarkus-data-index-inmemory > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > There are also jBPM specifics, which I > > > propose: > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Description Extension Target > > > > > >> > > > > > > > > > > > jBPM Add-On for e-mail support on Human > Tasks. > > > > > >> > > > > > > > > > > > org.kie.kogito:kogito-addons-quarkus-mail > > > > > >> > > > > > > > > > > org.jbpm:jbpm-addons-quarkus-mail > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > To keep things simple for now, we can > refrain > > > > from > > > > > >> > renaming > > > > > >> > > > > > > > > namespaces, > > > > > >> > > > > > > > > > > but > > > > > >> > > > > > > > > > > > GAV is important since we are moving to > 10.x., > > > > so > > > > > we > > > > > >> > start > > > > > >> > > > > > fresh. > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > If we agree, I can keep a spreadsheet > with all > > > > the > > > > > >> > renames > > > > > >> > > > and > > > > > >> > > > > > > > share > > > > > >> > > > > > > > > it > > > > > >> > > > > > > > > > > > with the community. > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > Cheers! > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > -- > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > --------------------------------------------------------------------- > > > > > >> > > > > > > > > > > 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 > >
