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

[Michael Brohl]

+1, with a remark




Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 02.02.20 um 16:21 schrieb Pierre Smits:

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.

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 <michael.br...@ecomify.de>
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

smime.p7s
Description: S/MIME Cryptographic Signature