That is one person's opinion. The reason OFBiz got to where it is today
is because of innovation, and a certain fearlessness in trying new
things. But that fearlessness ended years ago.
Moqui exists because the OFBiz community turned its back on innovation.
I don't see Moqui ever making it into this project - simply because
every time it has been suggested, there has been opposition.
The project is doomed to be locked in its current state until the PMC
decides to embrace change.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/21/2014 7:47 PM, Jacques Le Roux wrote:
Le 21/08/2014 15:48, Al Byers a écrit :
As a "pro" it should stated that migrating to gradle would - wait for
it -
help in the migration to and/or from moqui.org, as it is one its many
advanced built-in tools. I appreciate the groovy-everywhere
consistency of
moqui and believe that it would be a good direction for OFBiz to head.
I'd not be against that, still a long term goal...
For now OFBiz has a much larger users base than Moqui, sot it's less
flexible (one of the reason David created Moqui).
We must be cautious with our technical moves; nothing impossible though,
especially Gradle indeed
Jacques
On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
[email protected]> wrote:
On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
[email protected]> wrote:
I think you did not get me right. Like I have explained to Ron,
branches
are not only to get stabilised releases. So my idea would be to have
a new
feature branch where we can make the desired changes before merging
them in
the trunk, when happy with them.
This is for instance what I did for the jQuery move. What I did also
for
the missed Tom Burn's new help (now a Neogia addon I have been told).
And
what I'm doing for the SEO branch I created for OFBIZ-5312 which I
want to
merge back in trunk before we freeze a branch for the next release.
So yes it's a bit a burden, but it's a way to (more) safely integrate
new features in the trunk.
Jacques
Experimental branches are useful for running experiments that impact a
large amount of code or require several commits (and committers) to be
completed; especially when the community is divided about the
opportunity
to integrate them. The examples you provided belongs to this group...
the
ant->gradle switch I am not sure because we could easily implement the
gradle scripts while leaving the ant scripts in place and then remove
the
ant scripts only when we will have enough confidence.
But really it is too early to talk about how to do this work... at the
moment we can just focus on the pros/cons of this switch.
Jacopo
