I believe there is sufficient consensus on the approach so we are executing on this.
Note that the recommendation is to focus on the module renaming for now (and whatever would be absolutely necessary to integrate into quarkus, e.g. metadata updates), as this is considered a blocker for the release. While there is more work to be done (renaming other modules, renaming properties, etc.), let's try to prioritize getting the renaming merged asap and we can follow up with more changes later. Thx, Kris On Wed, Feb 7, 2024 at 4:44 PM Alex Porcelli <a...@porcelli.me> wrote: > The following extensions are missing in the spreadsheet: > > org.kie:kogito-addons-quarkus-jobs > org.kie:kogito-addons-data-audit-quarkus > org.kie:kogito-addons-data-audit-jpa-quarkus > org.kie:kogito-addons-data-audit-springboot > org.kie:kogito-addons-data-audit-jpa-springboot > > The org.kie.kogito:kogito-quarkus I suggest to preserve and rename to > org.jbpm:jbpm-with-drools - and not remove. > > And, for now I'd prefer to preserve all extensions, so not removing > the following: > > org.kie:kie-addons-quarkus-events-predictions > org.kie:kie-addons-quarkus-explainability > org.kie:kie-addons-quarkus-tracing-decision > org.kie:kie-quarkus-predictions > > > On Wed, Feb 7, 2024 at 7:31 AM Francisco Javier Tirado Sarti > <ftira...@redhat.com> wrote: > > > > +1 > > > > On Wed, Feb 7, 2024 at 1:05 PM Kris Verlaenen <kris.verlae...@gmail.com> > > wrote: > > > > > It's up to us to define how to use Kogito. I guess the term I used > > > (supporting service) isn't well-defined and open for interpretation. > If we > > > define them more like services that are developed as part of the KIE > > > project and could (potentially) be independent, then job service and > data > > > index would fall under that category, but persistence (for the runtime > > > engine) would more like eventing and other generic services under kie, > > > where it's more connecting to other external services. I updated the > > > proposal to reflect this. Wdyt? > > > > > > There were a few missing modules that were added after the spreadsheet > was > > > created, I added them, but they are following the same reasoning. > > > I also incorporated Pere's suggestion on jbpm-quarkus-devui. > > > > > > Thx, > > > Kris > > > > > > On Tue, Feb 6, 2024 at 4:30 PM Alex Porcelli <a...@porcelli.me> wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
