Also as Michael mentioned : "So it would be really helpful to break down the todos in smaller pieces to be assigned to contributors. " It will help other contributors to pick tasks and help in this effort.
Thanks -- Divesh Dutta. On Tue, Jun 21, 2016 at 2:32 PM, Divesh Dutta < divesh.du...@hotwaxsystems.com> wrote: > Thanks for detailed email Sharan. It was very informative. After reading > all the details it totally makes sense that why should we move to Gradle > from Ant. Overall work going in community to improve OFBiz is really > amazing and I am really excited about this. > > Thanks > -- > Divesh Dutta. > > 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 >> > >
