So how does the PMC envision the way contributors collaborate on this new feature?
Best regards, Pierre On Monday, June 20, 2016, Sharan Foga <[email protected]> wrote: > Hi Pierre > > My understanding is that this will not be done as a branch - it will done > directly onto the trunk. If you refer back to the notes from the > re-factoring team meeting a few months ago, we decided not to use branches > as they become abandoned and hard to integrate. We also wanted to use the > trunk to innovate (and this definitely fits that!) > > Thanks > Sharan > > > On 2016-06-20 15:09 (+0200), Pierre Smits <[email protected] > <javascript:;>> wrote: > > Will this be done in a separate dev branch available in the OFBiz repo, > so > > that contributors can assist? > > > > Best regards, > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Mon, Jun 20, 2016 at 2:50 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 > > > > > > -- Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/
