I think the spreadsheet shared by Kris is missing quite some information, I’ll double check it and get back to this thread.
Hopefully with the updates that are missing, we can clarify Francisco concerns. On Tue, Feb 6, 2024 at 6:43 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > I think that we should set a criteria, I do not mind which one. For > example, if we took the one: "across all engines" vs "workflow > (bpmn+sonata, but not drools)", then, at a first look, persistence can be > considered kie, but job service would be just kogito ;). @Kris Verlaenen > <kverl...@redhat.com> I think we need some more concrete guidelines here. > > On Tue, Feb 6, 2024 at 12:37 PM Enrique Gonzalez Martinez < > elguard...@gmail.com> wrote: > > > Hi, > > > > El mar, 6 feb 2024 a las 12:01, Francisco Javier Tirado Sarti > > (<ftira...@redhat.com>) escribió: > > > > > > 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. > > > > As mentioned in my prior message the criteria avoided such distinction > > (yes, it is an arbitrary one) but criterias in the end are based on > > some arbitrary decision making. > > > > I guess the criteria is not really supporting service but if we > > consider addons something across all engines (kie) or workflow > > (kogito) > > > > The important part from my point of view is to have one that makes > > sense and the naming fits the criteria. > > Regarding persistence or messaging we might come up with different > > arguments to put them in different categories or we can set a degree > > of "importance" (whatever it means in this context) depending again on > > our views of the topic. > > In my case (I guess) I can compromise what I can consider something > > that I could come up with different arguments that fall in any of > > those categories and agree with the current situation. > > > > > > > > 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 > > > > > > > > > > > > > > > > -- > > Saludos, Enrique González Martínez :) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > >
