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
+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
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
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
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
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,
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
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
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
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
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 -
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
wrote:
> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle
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
13 matches
Mail list logo
