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