+1 for Gradle. Are we going to remove ant from framework completely or planning to keep both ant and gradle?
Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.f...@gmail.com> wrote: > Hi Everyone > > This is the second of two emails to inform the community about what has > been happening around how we are planning to handle external dependencies > in the trunk. Two weeks ago the community discussed and agreed to the use > of Gradle to help us put together a unit test framework. While trying to > get this set up while Ant remained as our build tool became very difficult. > This was because our Ant scripts: > > - are massive and contain a lot of code > - are complex > - are very brittle and make it very hard to change things > - have no dependency management > - need everything to be declared > > We realised very quickly that the re-factoring issues and limitations we > are facing are because of our build tool – Ant. > > Ant is verbose so it needs everything to be declared. We did a brief > assessment of Maven and found it better than Ant but not a good fit for > OFBiz because it has strict requirements for the > convention-over-configuration rules to work. Instead we decided to take a > closer look at Gradle. > > So why Gradle? > As Taher was already looking at Gradle for unit testing, we decided to > look at what we would need to do to totally replace Ant with Gradle. We > received some great support and feedback from David, who is already using > Gradle with Moqui. > > After some preliminary tests we found that Gradle has some very good > features such as: > > - a much shorter code base (e.g. one single file of around 250 lines of > code replaces all the build.xml files and thousands of lines of code) > - Programming is DSL based and links in well with Groovy (e.g. the > script is short because despite heavy custom requirements for OFBiz, two > small functions took care of the complex directory structure) > - It handles all the external jar files by downloading any dependencies > directly via internet > - Jars can be upgraded by simply changing a string > - It has matured a lot and has a high level of support in tools,IDEs, > books, documentation > - It also has a lot of plugins which means that it works with pretty > much all build systems, supports multiple programming languages, and many > other features (e.g. OSGi) > > We understand that it can help us make OFBiz more modular and also setting > up a framework for managing addons would be a lot easier. > > So what's been done? > Taher has been working very hard on a patch for the trunk that completely > replaces Ant with Gradle. (Huge thanks to David for providing some example > scripts to help us get started!) The patch is now ready to be applied to > the trunk and includes the following: > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz > --whatever-options-here' > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug > --whatever'. What does that mean? It means we can run debug on ALL ofbiz > commands, not just start > - If we decide to change the source directory structure in components > say from /src to /src/main, it would literally be a change of 5 characters > in the build script > - We can immediately move all jar files if we want to a unified > location in /lib for example > - We can delete most of the jars and declare them as dependencies > saving space and resources > - We can automate the creation of the .classpath file so when we > update libraries no need to do this manually (under development) > - We can ignore components that are not define in the xml files for > loading (under development) > - We can introduce unit tests with about 10 minutes of work > > We are finding that the flexibility and control we are getting with Gradle > is truly amazing. We know that Gradle will be a major change to the project > but we think that it will significantly improve the project by removing a > lot of build complexity and take care of that essential dependency > management that we need to comply with. > > Our next steps will be to apply the patch to the trunk and then continue > the re-factoring work. We will need to organise some knowledge transfer so > that all our committers understand what the changes are and how they would > need to work in the future. > > The PMC are very, very excited about having Gradle as part of future of > OFBiz and we hope that the community will think so too. As always, feedback > welcome. > > Thanks > Sharan >
