You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Alex Porcelli <al...@porcelli.me> on 2025/05/03 01:13:41 UTC
[DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Hi all,
I’d like to propose that we bring the current conversation around
SpringBoot support in job-service to the mailing list.
While I understand the intention behind organizing a call to move the
discussion forward, it’s important to remember that calls are not the
primary medium for resolving decisions in Apache projects. We’ve used
calls in the past, but there’s broad consensus now that the ML should
be the main channel — for transparency, inclusiveness, and alignment
with the Apache Way. In fact, we recently agreed to discontinue the
Friday sync meetings for the same reason [1].
I’m not here to dive into the merits of the technical arguments just
yet — though I see valid concerns from both perspectives. On one hand,
the current implementation may seem overly complex and tightly coupled
with Quarkus, which limits portability. On the other, any significant
architectural change needs careful consideration, especially when it
may affect alternative use cases like the SonataFlow deployment
strategy.
So rather than defaulting to a call, I suggest we use this thread to:
- Surface and clarify the concerns
- Explore how we can evolve the codebase to support SpringBoot at the
highest quality standard
- Ensure we do so without compromising other existing deployment strategies
Let’s take full advantage of the mechanisms the community has in
place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
necessary to clarify something specific, it should still be initiated
through the ML and the outcomes reflected on the ML.
Looking forward to your thoughts.
[1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
-
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Enrique Gonzalez Martinez <el...@gmail.com>.
Hi Dominik
El lun, 5 may 2025 a las 16:33, Dominik Hanak
(<do...@gmail.com>) escribió:
>
> Enrique,
>
> I agree more involvement is needed. That is why I am highlighting the
> template, as from my experience
> having detailed base focused on technical details, helps and facilities
> better collaboration on any code base.
There are two different problems at play.
1. awareness / involved
2. better understanding of that will be done.
The current problem is not about better understanding (template) it is
about awareness
They are two different things/concepts
My concern about getting into a call is about this will lead people to
try to fix things *after*
following the procedure which is the formal way to organise the
community. This is the wrong
approach and lessons learnt.
I can agree to certain extent that more detailed would help to see the
impact clearly, but given such
a complex problem of supporting 2 different runtimes and several
storage plus different sets of configurations
turn this into a little hell to organise things and the only real way
to do this is offering certain amount of information
and try to implement this in scoped PR to a simple concept (in this
case remove the reactive code from the common parts).
I am not against being inclusive at this point but rejecting right
away something that was coming along the way is completely a
misunderstanding how the community is organised IMO. If the feedback
were like this is missing or this need to be addressed that would
be ok, but rejecting the core concept of the PR (removing reactive
code) that was the core concept is a no-go.
Quarkus' implementation was not working properly either (and it was
because of the reactive code).
* The basic interface is not reactive so it was forced to be called
from non reactive code.
* This also was a problem with transactions in collocated mode and
IIRC collocated mode is one of the supported use cases everybody
agreed upon.
* This required a bit of a hack with I/O threads and worker threads in
that scenario.
* This was also a problem with the unit of work as it stores
information in the Thread Local variable (so the solution was
incompatible)
> My understanding is that some technical details of the implementation &
> their impact were misunderstood, hence my suggestion to mitigate this.
> It will never be perfect, however in open source community we must strive
> to provide accurate information about why a change is or
> was made.
Technical details won't fix awareness. It is just simple. The first
thing to become a community is to get involved in the decision making.
>
> On Mon, 5 May 2025 at 14:07, Toni Rikkola <ri...@apache.org> wrote:
>
> > The one delivering it always leads it.
> >
> > As long as the intentions were brought up on this list in advance, the
> > ones surprised then need to use the search function for the list. I doubt
> > there is a way for everyone to know everything all the time, but this is
> > the closest we can get.
> >
> > This gives a lot of power for the person delivering and for a good reason,
> > none of us wants to waste time on something that gets rejected later.
> >
> > Toni
> >
> > On 2025/05/05 09:59:35 Enrique Gonzalez Martinez wrote:
> > > Hi Dominik,
> > > What you said does not matter if people do not get involved in the
> > proposals.
> > > You can be as much as specific you want, vote and approve and then,
> > > one month later, somebody would be surprised by the job being done.
> > >
> > > El lun, 5 may 2025 a las 11:33, Dominik Hanak
> > > (<do...@gmail.com>) escribió:
> > > >
> > > > Hello everyone,
> > > >
> > > > imho the clarity of what is going to happen and how, can be partially
> > > > solved by initially proposing the change as per the
> > > > agreed proposal template[1]. The more detailed and specific it is, the
> > > > better.
> > > > There will always be surprises, the template helps minimizing them.
> > > >
> > > > [1]
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate
> > > >
> > > > Best regards,
> > > >
> > > > Dominik
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
--
Saludos, Enrique González Martínez :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Dominik Hanak <do...@gmail.com>.
Enrique,
I agree more involvement is needed. That is why I am highlighting the
template, as from my experience
having detailed base focused on technical details, helps and facilities
better collaboration on any code base.
My understanding is that some technical details of the implementation &
their impact were misunderstood, hence my suggestion to mitigate this.
It will never be perfect, however in open source community we must strive
to provide accurate information about why a change is or
was made.
On Mon, 5 May 2025 at 14:07, Toni Rikkola <ri...@apache.org> wrote:
> The one delivering it always leads it.
>
> As long as the intentions were brought up on this list in advance, the
> ones surprised then need to use the search function for the list. I doubt
> there is a way for everyone to know everything all the time, but this is
> the closest we can get.
>
> This gives a lot of power for the person delivering and for a good reason,
> none of us wants to waste time on something that gets rejected later.
>
> Toni
>
> On 2025/05/05 09:59:35 Enrique Gonzalez Martinez wrote:
> > Hi Dominik,
> > What you said does not matter if people do not get involved in the
> proposals.
> > You can be as much as specific you want, vote and approve and then,
> > one month later, somebody would be surprised by the job being done.
> >
> > El lun, 5 may 2025 a las 11:33, Dominik Hanak
> > (<do...@gmail.com>) escribió:
> > >
> > > Hello everyone,
> > >
> > > imho the clarity of what is going to happen and how, can be partially
> > > solved by initially proposing the change as per the
> > > agreed proposal template[1]. The more detailed and specific it is, the
> > > better.
> > > There will always be surprises, the template helps minimizing them.
> > >
> > > [1]
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate
> > >
> > > Best regards,
> > >
> > > Dominik
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Toni Rikkola <ri...@apache.org>.
The one delivering it always leads it.
As long as the intentions were brought up on this list in advance, the ones surprised then need to use the search function for the list. I doubt there is a way for everyone to know everything all the time, but this is the closest we can get.
This gives a lot of power for the person delivering and for a good reason, none of us wants to waste time on something that gets rejected later.
Toni
On 2025/05/05 09:59:35 Enrique Gonzalez Martinez wrote:
> Hi Dominik,
> What you said does not matter if people do not get involved in the proposals.
> You can be as much as specific you want, vote and approve and then,
> one month later, somebody would be surprised by the job being done.
>
> El lun, 5 may 2025 a las 11:33, Dominik Hanak
> (<do...@gmail.com>) escribió:
> >
> > Hello everyone,
> >
> > imho the clarity of what is going to happen and how, can be partially
> > solved by initially proposing the change as per the
> > agreed proposal template[1]. The more detailed and specific it is, the
> > better.
> > There will always be surprises, the template helps minimizing them.
> >
> > [1]
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate
> >
> > Best regards,
> >
> > Dominik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
Hi Dominik,
What you said does not matter if people do not get involved in the proposals.
You can be as much as specific you want, vote and approve and then,
one month later, somebody would be surprised by the job being done.
El lun, 5 may 2025 a las 11:33, Dominik Hanak
(<do...@gmail.com>) escribió:
>
> Hello everyone,
>
> imho the clarity of what is going to happen and how, can be partially
> solved by initially proposing the change as per the
> agreed proposal template[1]. The more detailed and specific it is, the
> better.
> There will always be surprises, the template helps minimizing them.
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate
>
> Best regards,
>
> Dominik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Dominik Hanak <do...@gmail.com>.
Hello everyone,
imho the clarity of what is going to happen and how, can be partially
solved by initially proposing the change as per the
agreed proposal template[1]. The more detailed and specific it is, the
better.
There will always be surprises, the template helps minimizing them.
[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate
Best regards,
Dominik
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Alex Porcelli <po...@apache.org>.
sounds fair;
Let’s wait for others input to better understand the impact.
On Sat, May 3, 2025 at 11:10 AM Enrique Gonzalez Martinez <
elguardian@gmail.com> wrote:
> Yeah. First i need to know what the impact is.
> Job service is used by the workflow engine and so far there is no impact in
> the workflow engine from any use case as serveless workflow is just another
> parser in it (more or less)
> Security has not been touched, functionality and performance is already
> answered. So i want the people rising concerns to state clearly what are
> the problems they see so i can address them publicly either here or in the
> PR.
>
> El sáb, 3 may 2025, 17:01, Alex Porcelli <al...@porcelli.me> escribió:
>
> > Enrique,
> >
> > I hear you and - regarding the specific piece of code impacted - I
> > can't agree more that the current state seems to have quite
> > unnecessary complexity.
> >
> > However, it's not because a change has been discussed, that it has to
> > be executed without taking into account impact on use cases. If
> > there's a concern that current proposed solution has an impact on a
> > use case, it has to be properly addressed. I might be wrong, but the
> > original proposal that has been agreed to progress, didn't clearly
> > stated or evaluated that a use case would not be supported anymore, or
> > would cause significant impact on it (significant impact includes
> > security and performance issues).
> >
> > So.. I'd love to use this thread, or the original, so you can address
> > how the use case referenced is not impact or what type of adjustments
> > you can make to current PR can be made to address the concerns.
> >
> > On Sat, May 3, 2025 at 10:04 AM Enrique Gonzalez Martinez
> > <el...@gmail.com> wrote:
> > >
> > > Hi Alex and Tiago
> > >
> > > Regarding calls, as it was mentioned before, it is not the right way
> > > as the formal procedure is to go through is the ML like it is
> > > mentioned by Alex, pushing in any other communication channels steals
> > > the conversation from the community and that is not something we want
> > > in a sensitive component like the workflow engine and its satellites
> > > applications like audit, jobs, index, events and wih, etc...
> > >
> > > The removal of the reactive code was discussed during the spring boot
> > > support discussion. You can check that thread for more details as
> > > Francisco asked for some clarifications about what it means about
> > > removing code that was not shared among runtimes. I did mention
> > > explicitly the reactive code in the job service and there was no push
> > > back in the discussion or any other direction so I presumed by
> > > procedure that everybody was aware. As nobody else raised any concerns
> > > and there was not any push back and everybody agreed on the topic
> > > being discussed (by voting +1 or by being absent) I started to work on
> > > this.
> > > I also asked for volunteers and I should remind people that the
> > > default responsible for moving forward the code is the committer
> > > responsible for making the proposal. Francisco asked for the data
> > > index support and nobody else asked for the job service so I did take
> > > it.
> > >
> > > I want to state clearly that this bullet point on the topic was
> > > mentioned explicitly and nobody pushed back during the active period
> > > of the discussion and vote.
> > >
> > > In any case and just reaching this point I would like to know the
> > > committers concerns because so far they were answered in the PR.
> > >
> > > El sáb, 3 may 2025 a las 15:35, Alex Porcelli (<po...@apache.org>)
> > escribió:
> > > >
> > > > Tiago,
> > > >
> > > > I understand the issue concern, as I wrote before.
> > > >
> > > > However I didn’t see any attempt in ML nor in PR to discuss anything.
> > > >
> > > > I’d much rather to see initial discussion happening here, and if
> party
> > > > involved consider that a call would be helpful, I consider it
> > completely
> > > > fine.
> > > >
> > > > So, please let’s try to have initial conversation here first…
> > unfortunately
> > > > I can’t make the proposed call time, and I’d love to hear the
> > discussion….
> > > > At least proposals on how to solve the situation, so I’d be aware of
> > > > possible outcomes.
> > > >
> > > > Alex
> > > >
> > > >
> > > > On Sat, May 3, 2025 at 9:03 AM Tiago Bento <ti...@apache.org>
> > wrote:
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > Thanks for raising it here, given it’s been a topic of debate
> > recently. I
> > > > > guess they didn’t default to a call in this case and tried to move
> it
> > > > > forward in the ML then on the PR directly… but even so people seem
> > to think
> > > > > written communication is lacking something for them to find a
> common
> > ground
> > > > > for this particular case.
> > > > >
> > > > > If they feel like getting together on a call will help, I guess
> > that’s
> > > > > okay, provided there’s a summary captured here for those who can’t
> > attend,
> > > > > and their proposed resolution is sent in the ML too so everyone can
> > voice
> > > > > their view as well.
> > > > >
> > > > > As long as we’re not under the impression big decisions can be made
> > in
> > > > > calls within a small group, and we eventually come back to the ML
> > with
> > > > > something more polished for everyone to understand and participate
> > in, I
> > > > > guess I don’t see a problem in having these discussion calls.
> > > > >
> > > > > In summary I think we can do both: some times discuss in calls then
> > use the
> > > > > Mailing List for continue discussing and eventually reaching
> > consensus.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tiago Bento
> > > > >
> > > > >
> > > > > On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me>
> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I’d like to propose that we bring the current conversation around
> > > > > > SpringBoot support in job-service to the mailing list.
> > > > > >
> > > > > > While I understand the intention behind organizing a call to move
> > the
> > > > > > discussion forward, it’s important to remember that calls are not
> > the
> > > > > > primary medium for resolving decisions in Apache projects. We’ve
> > used
> > > > > > calls in the past, but there’s broad consensus now that the ML
> > should
> > > > > > be the main channel — for transparency, inclusiveness, and
> > alignment
> > > > > > with the Apache Way. In fact, we recently agreed to discontinue
> the
> > > > > > Friday sync meetings for the same reason [1].
> > > > > >
> > > > > > I’m not here to dive into the merits of the technical arguments
> > just
> > > > > > yet — though I see valid concerns from both perspectives. On one
> > hand,
> > > > > > the current implementation may seem overly complex and tightly
> > coupled
> > > > > > with Quarkus, which limits portability. On the other, any
> > significant
> > > > > > architectural change needs careful consideration, especially when
> > it
> > > > > > may affect alternative use cases like the SonataFlow deployment
> > > > > > strategy.
> > > > > >
> > > > > > So rather than defaulting to a call, I suggest we use this thread
> > to:
> > > > > >
> > > > > > - Surface and clarify the concerns
> > > > > > - Explore how we can evolve the codebase to support SpringBoot at
> > the
> > > > > > highest quality standard
> > > > > > - Ensure we do so without compromising other existing deployment
> > > > > strategies
> > > > > >
> > > > > > Let’s take full advantage of the mechanisms the community has in
> > > > > > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> > > > > > necessary to clarify something specific, it should still be
> > initiated
> > > > > > through the ML and the outcomes reflected on the ML.
> > > > > >
> > > > > > Looking forward to your thoughts.
> > > > > >
> > > > > > [1]
> > https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
> > > > > >
> > > > > > -
> > > > > > Alex
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Saludos, Enrique González Martínez :)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Enrique Gonzalez Martinez <el...@gmail.com>.
Yeah. First i need to know what the impact is.
Job service is used by the workflow engine and so far there is no impact in
the workflow engine from any use case as serveless workflow is just another
parser in it (more or less)
Security has not been touched, functionality and performance is already
answered. So i want the people rising concerns to state clearly what are
the problems they see so i can address them publicly either here or in the
PR.
El sáb, 3 may 2025, 17:01, Alex Porcelli <al...@porcelli.me> escribió:
> Enrique,
>
> I hear you and - regarding the specific piece of code impacted - I
> can't agree more that the current state seems to have quite
> unnecessary complexity.
>
> However, it's not because a change has been discussed, that it has to
> be executed without taking into account impact on use cases. If
> there's a concern that current proposed solution has an impact on a
> use case, it has to be properly addressed. I might be wrong, but the
> original proposal that has been agreed to progress, didn't clearly
> stated or evaluated that a use case would not be supported anymore, or
> would cause significant impact on it (significant impact includes
> security and performance issues).
>
> So.. I'd love to use this thread, or the original, so you can address
> how the use case referenced is not impact or what type of adjustments
> you can make to current PR can be made to address the concerns.
>
> On Sat, May 3, 2025 at 10:04 AM Enrique Gonzalez Martinez
> <el...@gmail.com> wrote:
> >
> > Hi Alex and Tiago
> >
> > Regarding calls, as it was mentioned before, it is not the right way
> > as the formal procedure is to go through is the ML like it is
> > mentioned by Alex, pushing in any other communication channels steals
> > the conversation from the community and that is not something we want
> > in a sensitive component like the workflow engine and its satellites
> > applications like audit, jobs, index, events and wih, etc...
> >
> > The removal of the reactive code was discussed during the spring boot
> > support discussion. You can check that thread for more details as
> > Francisco asked for some clarifications about what it means about
> > removing code that was not shared among runtimes. I did mention
> > explicitly the reactive code in the job service and there was no push
> > back in the discussion or any other direction so I presumed by
> > procedure that everybody was aware. As nobody else raised any concerns
> > and there was not any push back and everybody agreed on the topic
> > being discussed (by voting +1 or by being absent) I started to work on
> > this.
> > I also asked for volunteers and I should remind people that the
> > default responsible for moving forward the code is the committer
> > responsible for making the proposal. Francisco asked for the data
> > index support and nobody else asked for the job service so I did take
> > it.
> >
> > I want to state clearly that this bullet point on the topic was
> > mentioned explicitly and nobody pushed back during the active period
> > of the discussion and vote.
> >
> > In any case and just reaching this point I would like to know the
> > committers concerns because so far they were answered in the PR.
> >
> > El sáb, 3 may 2025 a las 15:35, Alex Porcelli (<po...@apache.org>)
> escribió:
> > >
> > > Tiago,
> > >
> > > I understand the issue concern, as I wrote before.
> > >
> > > However I didn’t see any attempt in ML nor in PR to discuss anything.
> > >
> > > I’d much rather to see initial discussion happening here, and if party
> > > involved consider that a call would be helpful, I consider it
> completely
> > > fine.
> > >
> > > So, please let’s try to have initial conversation here first…
> unfortunately
> > > I can’t make the proposed call time, and I’d love to hear the
> discussion….
> > > At least proposals on how to solve the situation, so I’d be aware of
> > > possible outcomes.
> > >
> > > Alex
> > >
> > >
> > > On Sat, May 3, 2025 at 9:03 AM Tiago Bento <ti...@apache.org>
> wrote:
> > >
> > > > Hi Alex,
> > > >
> > > > Thanks for raising it here, given it’s been a topic of debate
> recently. I
> > > > guess they didn’t default to a call in this case and tried to move it
> > > > forward in the ML then on the PR directly… but even so people seem
> to think
> > > > written communication is lacking something for them to find a common
> ground
> > > > for this particular case.
> > > >
> > > > If they feel like getting together on a call will help, I guess
> that’s
> > > > okay, provided there’s a summary captured here for those who can’t
> attend,
> > > > and their proposed resolution is sent in the ML too so everyone can
> voice
> > > > their view as well.
> > > >
> > > > As long as we’re not under the impression big decisions can be made
> in
> > > > calls within a small group, and we eventually come back to the ML
> with
> > > > something more polished for everyone to understand and participate
> in, I
> > > > guess I don’t see a problem in having these discussion calls.
> > > >
> > > > In summary I think we can do both: some times discuss in calls then
> use the
> > > > Mailing List for continue discussing and eventually reaching
> consensus.
> > > >
> > > > Regards,
> > > >
> > > > Tiago Bento
> > > >
> > > >
> > > > On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I’d like to propose that we bring the current conversation around
> > > > > SpringBoot support in job-service to the mailing list.
> > > > >
> > > > > While I understand the intention behind organizing a call to move
> the
> > > > > discussion forward, it’s important to remember that calls are not
> the
> > > > > primary medium for resolving decisions in Apache projects. We’ve
> used
> > > > > calls in the past, but there’s broad consensus now that the ML
> should
> > > > > be the main channel — for transparency, inclusiveness, and
> alignment
> > > > > with the Apache Way. In fact, we recently agreed to discontinue the
> > > > > Friday sync meetings for the same reason [1].
> > > > >
> > > > > I’m not here to dive into the merits of the technical arguments
> just
> > > > > yet — though I see valid concerns from both perspectives. On one
> hand,
> > > > > the current implementation may seem overly complex and tightly
> coupled
> > > > > with Quarkus, which limits portability. On the other, any
> significant
> > > > > architectural change needs careful consideration, especially when
> it
> > > > > may affect alternative use cases like the SonataFlow deployment
> > > > > strategy.
> > > > >
> > > > > So rather than defaulting to a call, I suggest we use this thread
> to:
> > > > >
> > > > > - Surface and clarify the concerns
> > > > > - Explore how we can evolve the codebase to support SpringBoot at
> the
> > > > > highest quality standard
> > > > > - Ensure we do so without compromising other existing deployment
> > > > strategies
> > > > >
> > > > > Let’s take full advantage of the mechanisms the community has in
> > > > > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> > > > > necessary to clarify something specific, it should still be
> initiated
> > > > > through the ML and the outcomes reflected on the ML.
> > > > >
> > > > > Looking forward to your thoughts.
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
> > > > >
> > > > > -
> > > > > Alex
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Saludos, Enrique González Martínez :)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Alex Porcelli <al...@porcelli.me>.
Enrique,
I hear you and - regarding the specific piece of code impacted - I
can't agree more that the current state seems to have quite
unnecessary complexity.
However, it's not because a change has been discussed, that it has to
be executed without taking into account impact on use cases. If
there's a concern that current proposed solution has an impact on a
use case, it has to be properly addressed. I might be wrong, but the
original proposal that has been agreed to progress, didn't clearly
stated or evaluated that a use case would not be supported anymore, or
would cause significant impact on it (significant impact includes
security and performance issues).
So.. I'd love to use this thread, or the original, so you can address
how the use case referenced is not impact or what type of adjustments
you can make to current PR can be made to address the concerns.
On Sat, May 3, 2025 at 10:04 AM Enrique Gonzalez Martinez
<el...@gmail.com> wrote:
>
> Hi Alex and Tiago
>
> Regarding calls, as it was mentioned before, it is not the right way
> as the formal procedure is to go through is the ML like it is
> mentioned by Alex, pushing in any other communication channels steals
> the conversation from the community and that is not something we want
> in a sensitive component like the workflow engine and its satellites
> applications like audit, jobs, index, events and wih, etc...
>
> The removal of the reactive code was discussed during the spring boot
> support discussion. You can check that thread for more details as
> Francisco asked for some clarifications about what it means about
> removing code that was not shared among runtimes. I did mention
> explicitly the reactive code in the job service and there was no push
> back in the discussion or any other direction so I presumed by
> procedure that everybody was aware. As nobody else raised any concerns
> and there was not any push back and everybody agreed on the topic
> being discussed (by voting +1 or by being absent) I started to work on
> this.
> I also asked for volunteers and I should remind people that the
> default responsible for moving forward the code is the committer
> responsible for making the proposal. Francisco asked for the data
> index support and nobody else asked for the job service so I did take
> it.
>
> I want to state clearly that this bullet point on the topic was
> mentioned explicitly and nobody pushed back during the active period
> of the discussion and vote.
>
> In any case and just reaching this point I would like to know the
> committers concerns because so far they were answered in the PR.
>
> El sáb, 3 may 2025 a las 15:35, Alex Porcelli (<po...@apache.org>) escribió:
> >
> > Tiago,
> >
> > I understand the issue concern, as I wrote before.
> >
> > However I didn’t see any attempt in ML nor in PR to discuss anything.
> >
> > I’d much rather to see initial discussion happening here, and if party
> > involved consider that a call would be helpful, I consider it completely
> > fine.
> >
> > So, please let’s try to have initial conversation here first… unfortunately
> > I can’t make the proposed call time, and I’d love to hear the discussion….
> > At least proposals on how to solve the situation, so I’d be aware of
> > possible outcomes.
> >
> > Alex
> >
> >
> > On Sat, May 3, 2025 at 9:03 AM Tiago Bento <ti...@apache.org> wrote:
> >
> > > Hi Alex,
> > >
> > > Thanks for raising it here, given it’s been a topic of debate recently. I
> > > guess they didn’t default to a call in this case and tried to move it
> > > forward in the ML then on the PR directly… but even so people seem to think
> > > written communication is lacking something for them to find a common ground
> > > for this particular case.
> > >
> > > If they feel like getting together on a call will help, I guess that’s
> > > okay, provided there’s a summary captured here for those who can’t attend,
> > > and their proposed resolution is sent in the ML too so everyone can voice
> > > their view as well.
> > >
> > > As long as we’re not under the impression big decisions can be made in
> > > calls within a small group, and we eventually come back to the ML with
> > > something more polished for everyone to understand and participate in, I
> > > guess I don’t see a problem in having these discussion calls.
> > >
> > > In summary I think we can do both: some times discuss in calls then use the
> > > Mailing List for continue discussing and eventually reaching consensus.
> > >
> > > Regards,
> > >
> > > Tiago Bento
> > >
> > >
> > > On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I’d like to propose that we bring the current conversation around
> > > > SpringBoot support in job-service to the mailing list.
> > > >
> > > > While I understand the intention behind organizing a call to move the
> > > > discussion forward, it’s important to remember that calls are not the
> > > > primary medium for resolving decisions in Apache projects. We’ve used
> > > > calls in the past, but there’s broad consensus now that the ML should
> > > > be the main channel — for transparency, inclusiveness, and alignment
> > > > with the Apache Way. In fact, we recently agreed to discontinue the
> > > > Friday sync meetings for the same reason [1].
> > > >
> > > > I’m not here to dive into the merits of the technical arguments just
> > > > yet — though I see valid concerns from both perspectives. On one hand,
> > > > the current implementation may seem overly complex and tightly coupled
> > > > with Quarkus, which limits portability. On the other, any significant
> > > > architectural change needs careful consideration, especially when it
> > > > may affect alternative use cases like the SonataFlow deployment
> > > > strategy.
> > > >
> > > > So rather than defaulting to a call, I suggest we use this thread to:
> > > >
> > > > - Surface and clarify the concerns
> > > > - Explore how we can evolve the codebase to support SpringBoot at the
> > > > highest quality standard
> > > > - Ensure we do so without compromising other existing deployment
> > > strategies
> > > >
> > > > Let’s take full advantage of the mechanisms the community has in
> > > > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> > > > necessary to clarify something specific, it should still be initiated
> > > > through the ML and the outcomes reflected on the ML.
> > > >
> > > > Looking forward to your thoughts.
> > > >
> > > > [1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
> > > >
> > > > -
> > > > Alex
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
>
>
>
> --
> Saludos, Enrique González Martínez :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Enrique Gonzalez Martinez <el...@gmail.com>.
Hi Alex and Tiago
Regarding calls, as it was mentioned before, it is not the right way
as the formal procedure is to go through is the ML like it is
mentioned by Alex, pushing in any other communication channels steals
the conversation from the community and that is not something we want
in a sensitive component like the workflow engine and its satellites
applications like audit, jobs, index, events and wih, etc...
The removal of the reactive code was discussed during the spring boot
support discussion. You can check that thread for more details as
Francisco asked for some clarifications about what it means about
removing code that was not shared among runtimes. I did mention
explicitly the reactive code in the job service and there was no push
back in the discussion or any other direction so I presumed by
procedure that everybody was aware. As nobody else raised any concerns
and there was not any push back and everybody agreed on the topic
being discussed (by voting +1 or by being absent) I started to work on
this.
I also asked for volunteers and I should remind people that the
default responsible for moving forward the code is the committer
responsible for making the proposal. Francisco asked for the data
index support and nobody else asked for the job service so I did take
it.
I want to state clearly that this bullet point on the topic was
mentioned explicitly and nobody pushed back during the active period
of the discussion and vote.
In any case and just reaching this point I would like to know the
committers concerns because so far they were answered in the PR.
El sáb, 3 may 2025 a las 15:35, Alex Porcelli (<po...@apache.org>) escribió:
>
> Tiago,
>
> I understand the issue concern, as I wrote before.
>
> However I didn’t see any attempt in ML nor in PR to discuss anything.
>
> I’d much rather to see initial discussion happening here, and if party
> involved consider that a call would be helpful, I consider it completely
> fine.
>
> So, please let’s try to have initial conversation here first… unfortunately
> I can’t make the proposed call time, and I’d love to hear the discussion….
> At least proposals on how to solve the situation, so I’d be aware of
> possible outcomes.
>
> Alex
>
>
> On Sat, May 3, 2025 at 9:03 AM Tiago Bento <ti...@apache.org> wrote:
>
> > Hi Alex,
> >
> > Thanks for raising it here, given it’s been a topic of debate recently. I
> > guess they didn’t default to a call in this case and tried to move it
> > forward in the ML then on the PR directly… but even so people seem to think
> > written communication is lacking something for them to find a common ground
> > for this particular case.
> >
> > If they feel like getting together on a call will help, I guess that’s
> > okay, provided there’s a summary captured here for those who can’t attend,
> > and their proposed resolution is sent in the ML too so everyone can voice
> > their view as well.
> >
> > As long as we’re not under the impression big decisions can be made in
> > calls within a small group, and we eventually come back to the ML with
> > something more polished for everyone to understand and participate in, I
> > guess I don’t see a problem in having these discussion calls.
> >
> > In summary I think we can do both: some times discuss in calls then use the
> > Mailing List for continue discussing and eventually reaching consensus.
> >
> > Regards,
> >
> > Tiago Bento
> >
> >
> > On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Hi all,
> > >
> > > I’d like to propose that we bring the current conversation around
> > > SpringBoot support in job-service to the mailing list.
> > >
> > > While I understand the intention behind organizing a call to move the
> > > discussion forward, it’s important to remember that calls are not the
> > > primary medium for resolving decisions in Apache projects. We’ve used
> > > calls in the past, but there’s broad consensus now that the ML should
> > > be the main channel — for transparency, inclusiveness, and alignment
> > > with the Apache Way. In fact, we recently agreed to discontinue the
> > > Friday sync meetings for the same reason [1].
> > >
> > > I’m not here to dive into the merits of the technical arguments just
> > > yet — though I see valid concerns from both perspectives. On one hand,
> > > the current implementation may seem overly complex and tightly coupled
> > > with Quarkus, which limits portability. On the other, any significant
> > > architectural change needs careful consideration, especially when it
> > > may affect alternative use cases like the SonataFlow deployment
> > > strategy.
> > >
> > > So rather than defaulting to a call, I suggest we use this thread to:
> > >
> > > - Surface and clarify the concerns
> > > - Explore how we can evolve the codebase to support SpringBoot at the
> > > highest quality standard
> > > - Ensure we do so without compromising other existing deployment
> > strategies
> > >
> > > Let’s take full advantage of the mechanisms the community has in
> > > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> > > necessary to clarify something specific, it should still be initiated
> > > through the ML and the outcomes reflected on the ML.
> > >
> > > Looking forward to your thoughts.
> > >
> > > [1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
> > >
> > > -
> > > Alex
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
--
Saludos, Enrique González Martínez :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Alex Porcelli <po...@apache.org>.
Tiago,
I understand the issue concern, as I wrote before.
However I didn’t see any attempt in ML nor in PR to discuss anything.
I’d much rather to see initial discussion happening here, and if party
involved consider that a call would be helpful, I consider it completely
fine.
So, please let’s try to have initial conversation here first… unfortunately
I can’t make the proposed call time, and I’d love to hear the discussion….
At least proposals on how to solve the situation, so I’d be aware of
possible outcomes.
Alex
On Sat, May 3, 2025 at 9:03 AM Tiago Bento <ti...@apache.org> wrote:
> Hi Alex,
>
> Thanks for raising it here, given it’s been a topic of debate recently. I
> guess they didn’t default to a call in this case and tried to move it
> forward in the ML then on the PR directly… but even so people seem to think
> written communication is lacking something for them to find a common ground
> for this particular case.
>
> If they feel like getting together on a call will help, I guess that’s
> okay, provided there’s a summary captured here for those who can’t attend,
> and their proposed resolution is sent in the ML too so everyone can voice
> their view as well.
>
> As long as we’re not under the impression big decisions can be made in
> calls within a small group, and we eventually come back to the ML with
> something more polished for everyone to understand and participate in, I
> guess I don’t see a problem in having these discussion calls.
>
> In summary I think we can do both: some times discuss in calls then use the
> Mailing List for continue discussing and eventually reaching consensus.
>
> Regards,
>
> Tiago Bento
>
>
> On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me> wrote:
>
> > Hi all,
> >
> > I’d like to propose that we bring the current conversation around
> > SpringBoot support in job-service to the mailing list.
> >
> > While I understand the intention behind organizing a call to move the
> > discussion forward, it’s important to remember that calls are not the
> > primary medium for resolving decisions in Apache projects. We’ve used
> > calls in the past, but there’s broad consensus now that the ML should
> > be the main channel — for transparency, inclusiveness, and alignment
> > with the Apache Way. In fact, we recently agreed to discontinue the
> > Friday sync meetings for the same reason [1].
> >
> > I’m not here to dive into the merits of the technical arguments just
> > yet — though I see valid concerns from both perspectives. On one hand,
> > the current implementation may seem overly complex and tightly coupled
> > with Quarkus, which limits portability. On the other, any significant
> > architectural change needs careful consideration, especially when it
> > may affect alternative use cases like the SonataFlow deployment
> > strategy.
> >
> > So rather than defaulting to a call, I suggest we use this thread to:
> >
> > - Surface and clarify the concerns
> > - Explore how we can evolve the codebase to support SpringBoot at the
> > highest quality standard
> > - Ensure we do so without compromising other existing deployment
> strategies
> >
> > Let’s take full advantage of the mechanisms the community has in
> > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> > necessary to clarify something specific, it should still be initiated
> > through the ML and the outcomes reflected on the ML.
> >
> > Looking forward to your thoughts.
> >
> > [1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
> >
> > -
> > Alex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [DISCUSS] SpringBoot Support in Job-Service: Let's Bring the Conversation to the Mailing List
Posted by Tiago Bento <ti...@apache.org>.
Hi Alex,
Thanks for raising it here, given it’s been a topic of debate recently. I
guess they didn’t default to a call in this case and tried to move it
forward in the ML then on the PR directly… but even so people seem to think
written communication is lacking something for them to find a common ground
for this particular case.
If they feel like getting together on a call will help, I guess that’s
okay, provided there’s a summary captured here for those who can’t attend,
and their proposed resolution is sent in the ML too so everyone can voice
their view as well.
As long as we’re not under the impression big decisions can be made in
calls within a small group, and we eventually come back to the ML with
something more polished for everyone to understand and participate in, I
guess I don’t see a problem in having these discussion calls.
In summary I think we can do both: some times discuss in calls then use the
Mailing List for continue discussing and eventually reaching consensus.
Regards,
Tiago Bento
On Fri, May 2, 2025 at 21:14 Alex Porcelli <al...@porcelli.me> wrote:
> Hi all,
>
> I’d like to propose that we bring the current conversation around
> SpringBoot support in job-service to the mailing list.
>
> While I understand the intention behind organizing a call to move the
> discussion forward, it’s important to remember that calls are not the
> primary medium for resolving decisions in Apache projects. We’ve used
> calls in the past, but there’s broad consensus now that the ML should
> be the main channel — for transparency, inclusiveness, and alignment
> with the Apache Way. In fact, we recently agreed to discontinue the
> Friday sync meetings for the same reason [1].
>
> I’m not here to dive into the merits of the technical arguments just
> yet — though I see valid concerns from both perspectives. On one hand,
> the current implementation may seem overly complex and tightly coupled
> with Quarkus, which limits portability. On the other, any significant
> architectural change needs careful consideration, especially when it
> may affect alternative use cases like the SonataFlow deployment
> strategy.
>
> So rather than defaulting to a call, I suggest we use this thread to:
>
> - Surface and clarify the concerns
> - Explore how we can evolve the codebase to support SpringBoot at the
> highest quality standard
> - Ensure we do so without compromising other existing deployment strategies
>
> Let’s take full advantage of the mechanisms the community has in
> place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being
> necessary to clarify something specific, it should still be initiated
> through the ML and the outcomes reflected on the ML.
>
> Looking forward to your thoughts.
>
> [1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3
>
> -
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>