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

Reply via email to