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