[DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Jacques Le Roux]

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
templates and Groovy Scripts.

We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
 2. We add the necessary packages names
 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax or
alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.

I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as suggested
Mathieu.

I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.

Feedback welcome, thanks

Jacques

[Paul Foxworthy-2]

Thanks Jacques,

Yes, on the fly rebuild is very cool. This will encourage and accelerate
moving Java services to Groovy, I think.

Big +1 from me.

Cheers

Paul

On Mon, 16 Sep 2019 at 20:29, Jacques Le Roux <[hidden email]>
wrote:

> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets"
> I discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/
> to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on
> the fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not
> have best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
>  1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
>  2. We add the necessary packages names
>  3. Devs can then open "gradlew --continuous" in a terminal and let it
> like that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or
> alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested
> Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll
> create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Gil Portenseigne]

Hello Jacques,

I also discussed about it with Mathieu and i find it very interesting.

The main advantage I see is, beside compilation, the integration in your
IDE, that was not optimum, and the possibility to re-use methods from
these script migrated to explicit classes.

So +1

Gil


Le 12:28 - lundi 16 sept., Jacques Le Roux a écrit :

> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on the
> fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>

[Jacques Le Roux]

Thanks Paul, Gil, for your suggestions,

I have created OFBIZ-11205 for that

Jacques

Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :

> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>
>

[taher]

I'm not sure I understand the outcome from reading the JIRA and this
thread. What will happen exactly? Are you going to make groovy scripts
part of the call stack? Are you going to use @CompileStatic? Or are
you just going to move them to src/main/groovy?

On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
<[hidden email]> wrote:

>
> Thanks Paul, Gil, for your suggestions,
>
> I have created OFBIZ-11205 for that
>
> Jacques
>
> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> > Hi Devs,
> >
> > While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
> >
> > Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
> >
> > I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
> > templates and Groovy Scripts.
> >
> > We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
> >
> > I tried and it works. So here is the (simple) plan:
> >
> > 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> > 2. We add the necessary packages names
> > 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
> >
> > So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax
> > or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.
> >
> > I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> > suggested Mathieu.
> >
> > I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
> >
> > Feedback welcome, thanks
> >
> > Jacques
> >
> >

[Jacques Le Roux]

In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's
enough for my need.

Using @CompileStatic is out of my scope because I want to keep Groovy scripts dynamic.

Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :

> I'm not sure I understand the outcome from reading the JIRA and this
> thread. What will happen exactly? Are you going to make groovy scripts
> part of the call stack? Are you going to use @CompileStatic? Or are
> you just going to move them to src/main/groovy?
>
> On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
> <[hidden email]> wrote:
>> Thanks Paul, Gil, for your suggestions,
>>
>> I have created OFBIZ-11205 for that
>>
>> Jacques
>>
>> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
>>> Hi Devs,
>>>
>>> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
>>>
>>> Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
>>>
>>> I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
>>> templates and Groovy Scripts.
>>>
>>> We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
>>>
>>> I tried and it works. So here is the (simple) plan:
>>>
>>> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
>>> 2. We add the necessary packages names
>>> 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
>>>
>>> So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax
>>> or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.
>>>
>>> I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
>>> suggested Mathieu.
>>>
>>> I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
>>>
>>> Feedback welcome, thanks
>>>
>>> Jacques
>>>
>>>

[taher]

I see, in this case I think it's a good idea to comply with
conventions. It's strange that while I was working in the beginnings
on gradle I remember the opposite suggestion happening "keep the
scripts where they are" is what I heard repeatedly. Anyway, if it is
just a matter of moving, then it's not that big of a deal.

I suggest to do that slowly and carefully though. It is quite possible
to break many scripts due to location references.

On Fri, Sep 20, 2019 at 6:40 PM Jacques Le Roux
<[hidden email]> wrote:

>
> In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's
> enough for my need.
>
> Using @CompileStatic is out of my scope because I want to keep Groovy scripts dynamic.
>
> Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :
> > I'm not sure I understand the outcome from reading the JIRA and this
> > thread. What will happen exactly? Are you going to make groovy scripts
> > part of the call stack? Are you going to use @CompileStatic? Or are
> > you just going to move them to src/main/groovy?
> >
> > On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
> > <[hidden email]> wrote:
> >> Thanks Paul, Gil, for your suggestions,
> >>
> >> I have created OFBIZ-11205 for that
> >>
> >> Jacques
> >>
> >> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> >>> Hi Devs,
> >>>
> >>> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
> >>>
> >>> Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
> >>>
> >>> I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
> >>> templates and Groovy Scripts.
> >>>
> >>> We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
> >>>
> >>> I tried and it works. So here is the (simple) plan:
> >>>
> >>> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> >>> 2. We add the necessary packages names
> >>> 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
> >>>
> >>> So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax
> >>> or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.
> >>>
> >>> I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> >>> suggested Mathieu.
> >>>
> >>> I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
> >>>
> >>> Feedback welcome, thanks
> >>>
> >>> Jacques
> >>>
> >>>

[Samuel-2]

Hello Jacques,

I think it is a really good idea: add more checks on our code!

The option to use `gradlew --continous classes` make me think about
putting more things into jar (but this another discussion )

I still have one question: what about `commponent://` url in xml
(screen, service,...) ? are you going to rewrite
ComponentLocationResolver to load groovy from compiled `.class`

Samuel


On 16/09/2019 12:28, Jacques Le Roux wrote:

> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle
> sourceSets" I discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/
> to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on
> the fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not
> have best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it
> like that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible
> syntax or alike issues in the terminal running the continuous build.
> It's very fast since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll
> create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>
>

[Jacques Le Roux]

Hi Samuel,

For the moment I don't expect to change "`commponent://` url in xml (screen, service,...)", but that a good idea!

I suggest you create a Jira for that

Thanks

Jacques

Le 23/09/2019 à 10:31, Samuel a écrit :

> Hello Jacques,
>
> I think it is a really good idea: add more checks on our code!
>
> The option to use `gradlew --continous classes` make me think about putting more things into jar (but this another discussion )
>
> I still have one question: what about `commponent://` url in xml (screen, service,...) ? are you going to rewrite ComponentLocationResolver to load
> groovy from compiled `.class`
>
> Samuel
>
>
> On 16/09/2019 12:28, Jacques Le Roux wrote:
>> Hi Devs,
>>
>> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.
>>
>> Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/.
>>
>> I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker
>> templates and Groovy Scripts.
>>
>> We also know the advantages of compilation. But then I thought: why not have best of both Groovy worlds: compile and on the fly.
>>
>> I tried and it works. So here is the (simple) plan:
>>
>> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
>> 2. We add the necessary packages names
>> 3. Devs can then open "gradlew --continuous" in a terminal and let it like that. It will continuously build on any changes in Gradle sourcesets
>>
>> So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax
>> or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.
>>
>> I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
>> suggested Mathieu.
>>
>> I see no disadvantages, do you? If nobody disagree with this idea, I'll create a Jira for that.
>>
>> Feedback welcome, thanks
>>
>> Jacques
>>
>>
>

[Michael Brohl-3]

Hi Jacques,

just stumbled upon this topic again, inline...

Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> OFBIZ-10205 and this thread, ie indeed mostly "move them to
> src/main/groovy". That's enough for my need.
>
> Using @CompileStatic is out of my scope because I want to keep Groovy
> scripts dynamic.

I'd like to bring up this thead again and encourage everyone to read the
mentioned article by David E. Jones:
https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E

We should be careful and act responsible when deciding certain
principles and patterns. While it is of course more simple for
developers to have it dynamic it might be a nightmare in real world
projects with huge traffic. We have our experiences with this.

We had this discussion in the aforementioned thread. One argument
against is "premature optimization" which is a killer argument to end
such discussions. Of course there will be perfomance metrics only if we
would implement the two patterns and compare runtime in a relevant load
scenario which is not achievable.

One can very well rely on the experiences of others and make use of
patterns to avoid problems in the later run. It would be real bad for
the project if we do mass changes and ignore these experiences just to
end up with users having serious production problems.

So I ask everyone involved to act responsible and take these
informations into account when changing the code base.

Thanks,

Michael

[Pierre Smits-3]

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <[hidden email]>
wrote:

> Hi Jacques,
>
> just stumbled upon this topic again, inline...
>
> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> > In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> > OFBIZ-10205 and this thread, ie indeed mostly "move them to
> > src/main/groovy". That's enough for my need.
> >
> > Using @CompileStatic is out of my scope because I want to keep Groovy
> > scripts dynamic.
>
> I'd like to bring up this thead again and encourage everyone to read the
> mentioned article by David E. Jones:
>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>
> We should be careful and act responsible when deciding certain
> principles and patterns. While it is of course more simple for
> developers to have it dynamic it might be a nightmare in real world
> projects with huge traffic. We have our experiences with this.
>
> We had this discussion in the aforementioned thread. One argument
> against is "premature optimization" which is a killer argument to end
> such discussions. Of course there will be perfomance metrics only if we
> would implement the two patterns and compare runtime in a relevant load
> scenario which is not achievable.
>
> One can very well rely on the experiences of others and make use of
> patterns to avoid problems in the later run. It would be real bad for
> the project if we do mass changes and ignore these experiences just to
> end up with users having serious production problems.
>
> So I ask everyone involved to act responsible and take these
> informations into account when changing the code base.
>
> Thanks,
>
> Michael
>
>
>
>

[Michael Brohl-3]

+1, with a remark

We should do the development on a feature branch based on trunk (instead
of a release branch) and constantly merge trunk into it. This would
allow to develop very near to the ongoing developments in other areas
and merge back easily once the feature branch gets accepted. It would
also allow field tests using the feature branch with the latest feature set.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 02.02.20 um 16:21 schrieb Pierre Smits:

> Hi All,
>
> Given that this is yet another major refactoring endeavour and can, when we
> do this on trunk, be dragged on for years given the limited number of
> contributors. Like is happening right now with those other refactoring
> efforts, such as the move from xml-services to script services or the
> migrate-documentation effort.
>
> If we do this on trunk, there is the risk that we confront our adopters
> (meaning their developers) with scripts in inconsistent locations. This
> will surely hinder the appeal of OFBiz.
>
> Michael stated:
>
> Of course there will be perfomance metrics only if we would implement the
> two patterns and compare runtime in a relevant load scenario which is not
> achievable.
>
> When done on trunk, Michael is correct: we can't measure and compare impact
> between the two scenarios.
> But we can measure and compare when we don't do this on trunk, but instead
> in a separate development branch based on one of the releases. Then we can
> have a CI perform the necessary tests on both, and we get insight in the
> performance gains/penalties.
>
> And when there are significant performance gains, we can work to merge the
> changes back into trunk.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <[hidden email]>
> wrote:
>
>> Hi Jacques,
>>
>> just stumbled upon this topic again, inline...
>>
>> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
>>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
>>> OFBIZ-10205 and this thread, ie indeed mostly "move them to
>>> src/main/groovy". That's enough for my need.
>>>
>>> Using @CompileStatic is out of my scope because I want to keep Groovy
>>> scripts dynamic.
>> I'd like to bring up this thead again and encourage everyone to read the
>> mentioned article by David E. Jones:
>>
>> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>>
>> We should be careful and act responsible when deciding certain
>> principles and patterns. While it is of course more simple for
>> developers to have it dynamic it might be a nightmare in real world
>> projects with huge traffic. We have our experiences with this.
>>
>> We had this discussion in the aforementioned thread. One argument
>> against is "premature optimization" which is a killer argument to end
>> such discussions. Of course there will be perfomance metrics only if we
>> would implement the two patterns and compare runtime in a relevant load
>> scenario which is not achievable.
>>
>> One can very well rely on the experiences of others and make use of
>> patterns to avoid problems in the later run. It would be real bad for
>> the project if we do mass changes and ignore these experiences just to
>> end up with users having serious production problems.
>>
>> So I ask everyone involved to act responsible and take these
>> informations into account when changing the code base.
>>
>> Thanks,
>>
>> Michael
>>
>>
>>
>>

[Pierre Smits-3]

Requests for feature branches in the OFBiz repositories received a lot of
push-back from PMC-members and committers in the past due to perceived high
maintenance burdens (ensuring the branch stayed in sync with where they
were derived from) placed on those willing to do that. I guess, the number
of those branches in svn (and restrictions thereon) led to this. I also
guess those complaining were the ones not often willing to participate in
those efforts.

With the implementation of Git as our prime version control solution, any
community member can start the feature branch and share it - for
collaboration and/or review purposes - via their public Github fork. With
this approach, the burden is placed on the member (not necessarily a PMC
Member or committer) willing to act as lead to keep the branch up to date.
And when the maintainer (as the driving party) feels confident it is ready
to be included in the OFBiz repository it can be introduced in the form of
a pull request. Updates to the community of progress can - as always - take
place via ticket comments and/or postings to the mailing list(s).

IMO, this path should be followed by every community member considering to
introduce new plugins or considering a large number of improvements on one
or more components.

However, there is also a drawback to this. This approach can lead to a big
contribution (in the form of a lot of changes to a lot of files) that won't
get the attention of fellow community members that the initiative deserves.
Over the years committers have rejected such from non-privileged
contributors because of the effort involved regarding review. And postings
on the ml hadn't helped the community. One could even argue that perception
regarding this has led to the floundering of many of the feature (and wish)
tickets in our JIRA (see [1]), and maybe even loss of contributors.

How will this be prevented?


[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20issuetype%20in%20(%22New%20Feature%22%2C%20Wish)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sun, Feb 2, 2020 at 5:01 PM Michael Brohl <[hidden email]>
wrote:

> +1, with a remark
>
> We should do the development on a feature branch based on trunk (instead
> of a release branch) and constantly merge trunk into it. This would
> allow to develop very near to the ongoing developments in other areas
> and merge back easily once the feature branch gets accepted. It would
> also allow field tests using the feature branch with the latest feature
> set.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 02.02.20 um 16:21 schrieb Pierre Smits:
> > Hi All,
> >
> > Given that this is yet another major refactoring endeavour and can, when
> we
> > do this on trunk, be dragged on for years given the limited number of
> > contributors. Like is happening right now with those other refactoring
> > efforts, such as the move from xml-services to script services or the
> > migrate-documentation effort.
> >
> > If we do this on trunk, there is the risk that we confront our adopters
> > (meaning their developers) with scripts in inconsistent locations. This
> > will surely hinder the appeal of OFBiz.
> >
> > Michael stated:
> >
> > Of course there will be perfomance metrics only if we would implement the
> > two patterns and compare runtime in a relevant load scenario which is not
> > achievable.
> >
> > When done on trunk, Michael is correct: we can't measure and compare
> impact
> > between the two scenarios.
> > But we can measure and compare when we don't do this on trunk, but
> instead
> > in a separate development branch based on one of the releases. Then we
> can
> > have a CI perform the necessary tests on both, and we get insight in the
> > performance gains/penalties.
> >
> > And when there are significant performance gains, we can work to merge
> the
> > changes back into trunk.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <[hidden email]>
> > wrote:
> >
> >> Hi Jacques,
> >>
> >> just stumbled upon this topic again, inline...
> >>
> >> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> >>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> >>> OFBIZ-10205 and this thread, ie indeed mostly "move them to
> >>> src/main/groovy". That's enough for my need.
> >>>
> >>> Using @CompileStatic is out of my scope because I want to keep Groovy
> >>> scripts dynamic.
> >> I'd like to bring up this thead again and encourage everyone to read the
> >> mentioned article by David E. Jones:
> >>
> >>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
> >>
> >> We should be careful and act responsible when deciding certain
> >> principles and patterns. While it is of course more simple for
> >> developers to have it dynamic it might be a nightmare in real world
> >> projects with huge traffic. We have our experiences with this.
> >>
> >> We had this discussion in the aforementioned thread. One argument
> >> against is "premature optimization" which is a killer argument to end
> >> such discussions. Of course there will be perfomance metrics only if we
> >> would implement the two patterns and compare runtime in a relevant load
> >> scenario which is not achievable.
> >>
> >> One can very well rely on the experiences of others and make use of
> >> patterns to avoid problems in the later run. It would be real bad for
> >> the project if we do mass changes and ignore these experiences just to
> >> end up with users having serious production problems.
> >>
> >> So I ask everyone involved to act responsible and take these
> >> informations into account when changing the code base.
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >>
> >>
> >>
>
>