Important Changes to Trunk and Use of Ant & Gradle

[Sharan-F]

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]

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 <[hidden email]> 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
>

[Ron Wheeler]

This sounds like a great step forward.
In addition to the technical benefits, this identifies OFBiz as a
"modern" project which will help in market acceptance when technical
analysts are asked to comment.

Ron

On 20/06/2016 8:50 AM, Sharan Foga 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
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Sharan-F]

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 <[hidden email]> 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 <[hidden email]> 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]

So how does the PMC envision the way contributors collaborate on this new
feature?

Best regards,

Pierre

On Monday, June 20, 2016, Sharan Foga <[hidden email]> 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 <[hidden email]
> <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 <[hidden email]
> <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/

[taher]

Hi Pierre Sharan and all,

In reply to your question Pierre, I will create a JIRA to which people can
contribute.

Although I worked very hard on this feature, I really need help with
thorough testing and feedback. I look forward to your help if you'd like to
contribute.

Regards,

Taher Alkhateeb
So how does the PMC envision the way contributors collaborate on this new
feature?

Best regards,

Pierre

On Monday, June 20, 2016, Sharan Foga <[hidden email]> 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 <[hidden email]
> <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 <[hidden email]
> <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/

[Pierre Smits]

Sharan,

If and when you refer to some notes from a refactoring team meeting a few
months ago, please have the decency to include the reference in the mail
thread yourself, as I can't find a vote thread (and its resolution
notification) in this ml on abandoning development branches,

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 3:28 PM, Sharan Foga <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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]

Where can the community find this work already done, for investigation and
evaluation purposes?

Best regards,

Pierre

On Monday, June 20, 2016, Sharan Foga <[hidden email]> 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/

[Deepak Dixit-3]

+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 <[hidden email]> 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
>

[taher]

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 <[hidden email]>
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 <[hidden email]
> <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
> >
>

[Deepak Dixit-3]

Thanks Taher,

Sounds good to me.



Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Tue, Jun 21, 2016 at 11:41 AM, Taher Alkhateeb <
[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> > <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
> > >
> >
>

[Pranay Pandey-3]

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 <
[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> > <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
> > >
> >
>

[Gavin Mabie-2]

+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 <
[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]
> > > <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
> > > >
> > >
> >
>

[Julien NICOLAS]

+1 to go forward with Gradle

Julien.

On 21/06/2016 08:11, Taher Alkhateeb 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 <[hidden email]>
> 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 <[hidden email]
>> <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
>>>

[Michael Brohl-3]

Hi Sharan,

thank you very much for this well-written summary of the changes to
come! Very exciting and I pretty much like the momentum that OFBiz is
gaining in the last months.

We would like to help as much as possible to make this work but are
facing a lot of customer projects in the moment. It's hard to find time
and have a clear view on which issues to focus to help efficiently. So
it would be really helpful to break down the todos in smaller pieces to
be assigned to contributors. Maybe this is already planned.

I'm not sure if it's the right way to do this change in trunk directly
and be backported in 14.12/15.12 accordingly. It forces everyone using
trunk and the latest release branches to make this switch directly and
get to learn/use the new mechanisms. This can be helpful for the project
itself because it has to go the next steps very quickly to get back to
"normal work", on the other hand it will break projects already on their
way...

Again, I'm very excited and looking forward to help out as much as I can
under the current circumstances.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 20.06.16 um 14:50 schrieb Sharan Foga:

> 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

[Michael Brohl-3]

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 <[hidden email]>
> 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 <[hidden email]
>> <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
>>>

[Ashish Vijaywargiya-4]

+1 for moving to Gradle!

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997

On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <[hidden email]> 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
>

[Gil Portenseigne]

Same opinion here, so +1

Best regards,

Gil

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 [hidden email]
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 <[hidden email]
<a class="moz-txt-link-rfc2396E" href="javascript:;"><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

[Jacopo Cappellato-5]

+1 for switching to Gradle.

Jacopo

On Mon, Jun 20, 2016 at 2:50 PM, Sharan Foga <[hidden email]> 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
>

[Jacques Le Roux]

As Gavin mentioned, Gradle can run Ant so no worries using only Gradle

https://docs.gradle.org/current/userguide/ant.html

Jacques


Le 21/06/2016 à 09:59, Michael Brohl a écrit :

> 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 <[hidden email]>
>> 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 <[hidden email]
>>> <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
>>>>
>
>