ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gil portenseigne <gil.portensei...@nereide.fr>
Subject Re: Important Changes to Trunk and Use of Ant & Gradle
Date Tue, 21 Jun 2016 08:03:44 GMT
Same opinion here, so +1

Best regards,


On 21/06/2016 09:59, Michael Brohl wrote:
> I have no strong opinion for/against Gradle (I simply have no 
> experience with it) but I agree that it should be either Ant or Gradle.
> Running two build tools in parallel would make it too complex an gain 
> nothing.
> I'm in favor for learning new things so Gradle sounds fine for me :-)
> Regards,
> Michael
> Am 21.06.16 um 08:11 schrieb Taher Alkhateeb:
>> 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 <deepak.dixit@hotwaxsystems.com>
>> 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 <sharan.foga@gmail.com
>>> <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

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message