With Moqui Framework I started using Ant and then migrated to Gradle. In doing so there are some things to be aware of:
1. because of the convention over configuration goal (defaults can generally be overridden, but it's a bit painful) it is a good idea to restructure things like the src directories to use the Maven style, ie things like "src/main/java" instead of plain "src", and then along with that it's nice to split out things like "src/main/groovy" for groovy classes that are built (not scripts interpreted/compiled at runtime, those are best elsewhere), and "src/main/resources" instead of the various "config" directories and other classpath resources 2. jar files can still be kept locally (using a local repository), and lib directories with jars can even be included with a wildcard, but it is also possible to use Maven repositories to get the jar files by specifying each jar explicitly in the gradle build file; for Moqui I went with a combination of these, using a local directory repository but also listing all jar files explicitly in anticipation of maybe using a remote repository in the future (for various reasons I like to have all jar files in the source repo instead of downloading at build time; and this way you have more control over dependency creep that sometimes happens when you pull jars plus all their dependencies from a remote repo) 3. there are various API details to get used to with Gradle, much like learning the XML elements supported in Ant, but the documentation for Gradle is really pretty good and especially these days examples are plentiful Overall using Gradle resulted in much simpler build files, it just takes care of a lot of things automagically that are pretty manual with Ant. OFBiz has some impressively complex build files that could perhaps be simplified a lot with Gradle (and/or made more flexible with support for Groovy scripting and the Gradle DSL). On a side note, using Spock for testing is very easy with Gradle... though not sure how it compares to using it with Ant as I've never tried it. Hope that helps... -David On Aug 21, 2014, at 6:48 AM, Al Byers <bye...@automationgroups.com> wrote: > 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. > > > On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato < > jacopo.cappell...@hotwaxmedia.com> wrote: > >> >> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux < >> jacques.le.r...@les7arts.com> 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 >> >>
