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