+1 for Graddle. I have been using groovyant (which is included with Graddle) to integrate build tasks with GUI, leveraging application logic achievable with Groovy.
On Tue, Jun 21, 2016 at 9:04 AM, Pranay Pandey < [email protected]> wrote: > Thanks for the explanation Taher, making perfect sense. > > +1 > > Best regards, > > Pranay Pandey > HotWax Systems > http://www.hotwaxsystems.com/ > > On Tue, Jun 21, 2016 at 11:41 AM, Taher Alkhateeb < > [email protected]> wrote: > > > Hi Deepak, > > > > Ant would be removed completely for the following reasons: > > > > - First to resolve the ASF issue about the libraries mentioned by Sharan > > below without expending effort on both build systems. > > - Ant is an obstacle to refactoring the framework. If we keep both > systems > > side by side we gain nothing, actually we lose value because the builds > > become more complex. For example, we will not be able to intrduce the > unit > > tests, and we will have two build outputs, and we will have two ways of > > running the framework (java -jar ofbiz.jar and gradlew ofbiz) and we will > > have other incompatibility issues. > > > > With that being said, we will not make the switch before a thorough and > > full testing. That is why we ask everyone who is willing to please help > us > > out to make this transition smooth by testing and providing feedback and > > comments. > > > > Taher Alkhateeb > > > > On Tuesday, 21 June 2016, Deepak Dixit <[email protected]> > > wrote: > > > > > +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 <[email protected] > > > <javascript:;>> 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 > > > > > > > > > >
