You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Sharan Foga <sh...@gmail.com> on 2016/06/20 12:50:54 UTC
Important Changes to Trunk and Use of Ant & Gradle
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 \u2013 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
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pierre Smits <pi...@gmail.com>.
Where can the community find this work already done, for investigation and
evaluation purposes?
Best regards,
Pierre
On Monday, June 20, 2016, Sharan Foga <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
--
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <sh...@gmail.com> 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 <pierre.smits@gmail.com
> <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 <sharan.foga@gmail.com
> <javascript:;>> wrote:
> >
> > > Hi Everyone
> > >
> > > This is the second of two emails to inform the community about what
has
> > > been happening around how we are planning to handle external
> dependencies
> > > in the trunk. Two weeks ago the community discussed and agreed to the
> use
> > > of Gradle to help us put together a unit test framework. While trying
> to
> > > get this set up while Ant remained as our build tool became very
> difficult.
> > > This was because our Ant scripts:
> > >
> > > - are massive and contain a lot of code
> > > - are complex
> > > - are very brittle and make it very hard to change things
> > > - have no dependency management
> > > - need everything to be declared
> > >
> > > We realised very quickly that the re-factoring issues and limitations
> we
> > > are facing are because of our build tool – Ant.
> > >
> > > Ant is verbose so it needs everything to be declared. We did a brief
> > > assessment of Maven and found it better than Ant but not a good fit
for
> > > OFBiz because it has strict requirements for the
> > > convention-over-configuration rules to work. Instead we decided to
> take a
> > > closer look at Gradle.
> > >
> > > So why Gradle?
> > > As Taher was already looking at Gradle for unit testing, we decided to
> > > look at what we would need to do to totally replace Ant with Gradle.
We
> > > received some great support and feedback from David, who is already
> using
> > > Gradle with Moqui.
> > >
> > > After some preliminary tests we found that Gradle has some very good
> > > features such as:
> > >
> > > - a much shorter code base (e.g. one single file of around 250
> lines of
> > > code replaces all the build.xml files and thousands of lines of code)
> > > - Programming is DSL based and links in well with Groovy (e.g. the
> > > script is short because despite heavy custom requirements for OFBiz,
> two
> > > small functions took care of the complex directory structure)
> > > - It handles all the external jar files by downloading any
> dependencies
> > > directly via internet
> > > - Jars can be upgraded by simply changing a string
> > > - It has matured a lot and has a high level of support in
> tools,IDEs,
> > > books, documentation
> > > - It also has a lot of plugins which means that it works with
pretty
> > > much all build systems, supports multiple programming languages, and
> many
> > > other features (e.g. OSGi)
> > >
> > > We understand that it can help us make OFBiz more modular and also
> setting
> > > up a framework for managing addons would be a lot easier.
> > >
> > > So what's been done?
> > > Taher has been working very hard on a patch for the trunk that
> completely
> > > replaces Ant with Gradle. (Huge thanks to David for providing some
> example
> > > scripts to help us get started!) The patch is now ready to be applied
> to
> > > the trunk and includes the following:
> > >
> > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > --whatever-options-here'
> > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > --whatever'. What does that mean? It means we can run debug on ALL
> ofbiz
> > > commands, not just start
> > > - If we decide to change the source directory structure in
> components
> > > say from /src to /src/main, it would literally be a change of 5
> characters
> > > in the build script
> > > - We can immediately move all jar files if we want to a unified
> > > location in /lib for example
> > > - We can delete most of the jars and declare them as dependencies
> > > saving space and resources
> > > - We can automate the creation of the .classpath file so when we
> > > update libraries no need to do this manually (under development)
> > > - We can ignore components that are not define in the xml files
for
> > > loading (under development)
> > > - We can introduce unit tests with about 10 minutes of work
> > >
> > > We are finding that the flexibility and control we are getting with
> Gradle
> > > is truly amazing. We know that Gradle will be a major change to the
> project
> > > but we think that it will significantly improve the project by
> removing a
> > > lot of build complexity and take care of that essential dependency
> > > management that we need to comply with.
> > >
> > > Our next steps will be to apply the patch to the trunk and then
> continue
> > > the re-factoring work. We will need to organise some knowledge
> transfer so
> > > that all our committers understand what the changes are and how they
> would
> > > need to work in the future.
> > >
> > > The PMC are very, very excited about having Gradle as part of future
of
> > > OFBiz and we hope that the community will think so too. As always,
> feedback
> > > welcome.
> > >
> > > Thanks
> > > Sharan
> > >
> >
>
--
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pierre Smits <pi...@gmail.com>.
So how does the PMC envision the way contributors collaborate on this new
feature?
Best regards,
Pierre
On Monday, June 20, 2016, Sharan Foga <sh...@gmail.com> 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 <pierre.smits@gmail.com
> <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 <sharan.foga@gmail.com
> <javascript:;>> wrote:
> >
> > > Hi Everyone
> > >
> > > This is the second of two emails to inform the community about what has
> > > been happening around how we are planning to handle external
> dependencies
> > > in the trunk. Two weeks ago the community discussed and agreed to the
> use
> > > of Gradle to help us put together a unit test framework. While trying
> to
> > > get this set up while Ant remained as our build tool became very
> difficult.
> > > This was because our Ant scripts:
> > >
> > > - are massive and contain a lot of code
> > > - are complex
> > > - are very brittle and make it very hard to change things
> > > - have no dependency management
> > > - need everything to be declared
> > >
> > > We realised very quickly that the re-factoring issues and limitations
> we
> > > are facing are because of our build tool – Ant.
> > >
> > > Ant is verbose so it needs everything to be declared. We did a brief
> > > assessment of Maven and found it better than Ant but not a good fit for
> > > OFBiz because it has strict requirements for the
> > > convention-over-configuration rules to work. Instead we decided to
> take a
> > > closer look at Gradle.
> > >
> > > So why Gradle?
> > > As Taher was already looking at Gradle for unit testing, we decided to
> > > look at what we would need to do to totally replace Ant with Gradle. We
> > > received some great support and feedback from David, who is already
> using
> > > Gradle with Moqui.
> > >
> > > After some preliminary tests we found that Gradle has some very good
> > > features such as:
> > >
> > > - a much shorter code base (e.g. one single file of around 250
> lines of
> > > code replaces all the build.xml files and thousands of lines of code)
> > > - Programming is DSL based and links in well with Groovy (e.g. the
> > > script is short because despite heavy custom requirements for OFBiz,
> two
> > > small functions took care of the complex directory structure)
> > > - It handles all the external jar files by downloading any
> dependencies
> > > directly via internet
> > > - Jars can be upgraded by simply changing a string
> > > - It has matured a lot and has a high level of support in
> tools,IDEs,
> > > books, documentation
> > > - It also has a lot of plugins which means that it works with pretty
> > > much all build systems, supports multiple programming languages, and
> many
> > > other features (e.g. OSGi)
> > >
> > > We understand that it can help us make OFBiz more modular and also
> setting
> > > up a framework for managing addons would be a lot easier.
> > >
> > > So what's been done?
> > > Taher has been working very hard on a patch for the trunk that
> completely
> > > replaces Ant with Gradle. (Huge thanks to David for providing some
> example
> > > scripts to help us get started!) The patch is now ready to be applied
> to
> > > the trunk and includes the following:
> > >
> > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > --whatever-options-here'
> > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > --whatever'. What does that mean? It means we can run debug on ALL
> ofbiz
> > > commands, not just start
> > > - If we decide to change the source directory structure in
> components
> > > say from /src to /src/main, it would literally be a change of 5
> characters
> > > in the build script
> > > - We can immediately move all jar files if we want to a unified
> > > location in /lib for example
> > > - We can delete most of the jars and declare them as dependencies
> > > saving space and resources
> > > - We can automate the creation of the .classpath file so when we
> > > update libraries no need to do this manually (under development)
> > > - We can ignore components that are not define in the xml files for
> > > loading (under development)
> > > - We can introduce unit tests with about 10 minutes of work
> > >
> > > We are finding that the flexibility and control we are getting with
> Gradle
> > > is truly amazing. We know that Gradle will be a major change to the
> project
> > > but we think that it will significantly improve the project by
> removing a
> > > lot of build complexity and take care of that essential dependency
> > > management that we need to comply with.
> > >
> > > Our next steps will be to apply the patch to the trunk and then
> continue
> > > the re-factoring work. We will need to organise some knowledge
> transfer so
> > > that all our committers understand what the changes are and how they
> would
> > > need to work in the future.
> > >
> > > The PMC are very, very excited about having Gradle as part of future of
> > > OFBiz and we hope that the community will think so too. As always,
> feedback
> > > welcome.
> > >
> > > Thanks
> > > Sharan
> > >
> >
>
--
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pierre Smits <pi...@gmail.com>.
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 <sh...@gmail.com> 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 <pi...@gmail.com> 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 <sh...@gmail.com>
> wrote:
> >
> > > Hi Everyone
> > >
> > > This is the second of two emails to inform the community about what has
> > > been happening around how we are planning to handle external
> dependencies
> > > in the trunk. Two weeks ago the community discussed and agreed to the
> use
> > > of Gradle to help us put together a unit test framework. While trying
> to
> > > get this set up while Ant remained as our build tool became very
> difficult.
> > > This was because our Ant scripts:
> > >
> > > - are massive and contain a lot of code
> > > - are complex
> > > - are very brittle and make it very hard to change things
> > > - have no dependency management
> > > - need everything to be declared
> > >
> > > We realised very quickly that the re-factoring issues and limitations
> we
> > > are facing are because of our build tool – Ant.
> > >
> > > Ant is verbose so it needs everything to be declared. We did a brief
> > > assessment of Maven and found it better than Ant but not a good fit for
> > > OFBiz because it has strict requirements for the
> > > convention-over-configuration rules to work. Instead we decided to
> take a
> > > closer look at Gradle.
> > >
> > > So why Gradle?
> > > As Taher was already looking at Gradle for unit testing, we decided to
> > > look at what we would need to do to totally replace Ant with Gradle. We
> > > received some great support and feedback from David, who is already
> using
> > > Gradle with Moqui.
> > >
> > > After some preliminary tests we found that Gradle has some very good
> > > features such as:
> > >
> > > - a much shorter code base (e.g. one single file of around 250
> lines of
> > > code replaces all the build.xml files and thousands of lines of code)
> > > - Programming is DSL based and links in well with Groovy (e.g. the
> > > script is short because despite heavy custom requirements for OFBiz,
> two
> > > small functions took care of the complex directory structure)
> > > - It handles all the external jar files by downloading any
> dependencies
> > > directly via internet
> > > - Jars can be upgraded by simply changing a string
> > > - It has matured a lot and has a high level of support in
> tools,IDEs,
> > > books, documentation
> > > - It also has a lot of plugins which means that it works with pretty
> > > much all build systems, supports multiple programming languages, and
> many
> > > other features (e.g. OSGi)
> > >
> > > We understand that it can help us make OFBiz more modular and also
> setting
> > > up a framework for managing addons would be a lot easier.
> > >
> > > So what's been done?
> > > Taher has been working very hard on a patch for the trunk that
> completely
> > > replaces Ant with Gradle. (Huge thanks to David for providing some
> example
> > > scripts to help us get started!) The patch is now ready to be applied
> to
> > > the trunk and includes the following:
> > >
> > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > --whatever-options-here'
> > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > --whatever'. What does that mean? It means we can run debug on ALL
> ofbiz
> > > commands, not just start
> > > - If we decide to change the source directory structure in
> components
> > > say from /src to /src/main, it would literally be a change of 5
> characters
> > > in the build script
> > > - We can immediately move all jar files if we want to a unified
> > > location in /lib for example
> > > - We can delete most of the jars and declare them as dependencies
> > > saving space and resources
> > > - We can automate the creation of the .classpath file so when we
> > > update libraries no need to do this manually (under development)
> > > - We can ignore components that are not define in the xml files for
> > > loading (under development)
> > > - We can introduce unit tests with about 10 minutes of work
> > >
> > > We are finding that the flexibility and control we are getting with
> Gradle
> > > is truly amazing. We know that Gradle will be a major change to the
> project
> > > but we think that it will significantly improve the project by
> removing a
> > > lot of build complexity and take care of that essential dependency
> > > management that we need to comply with.
> > >
> > > Our next steps will be to apply the patch to the trunk and then
> continue
> > > the re-factoring work. We will need to organise some knowledge
> transfer so
> > > that all our committers understand what the changes are and how they
> would
> > > need to work in the future.
> > >
> > > The PMC are very, very excited about having Gradle as part of future of
> > > OFBiz and we hope that the community will think so too. As always,
> feedback
> > > welcome.
> > >
> > > Thanks
> > > Sharan
> > >
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Sharan Foga <sh...@gmail.com>.
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 <pi...@gmail.com> 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 <sh...@gmail.com> wrote:
>
> > Hi Everyone
> >
> > This is the second of two emails to inform the community about what has
> > been happening around how we are planning to handle external dependencies
> > in the trunk. Two weeks ago the community discussed and agreed to the use
> > of Gradle to help us put together a unit test framework. While trying to
> > get this set up while Ant remained as our build tool became very difficult.
> > This was because our Ant scripts:
> >
> > - are massive and contain a lot of code
> > - are complex
> > - are very brittle and make it very hard to change things
> > - have no dependency management
> > - need everything to be declared
> >
> > We realised very quickly that the re-factoring issues and limitations we
> > are facing are because of our build tool \u2013 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
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pierre Smits <pi...@gmail.com>.
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 <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
Also as Michael mentioned : "So it would be really helpful to break down
the todos in smaller pieces to be assigned to contributors. " It will help
other contributors to pick tasks and help in this effort.
Thanks
--
Divesh Dutta.
On Tue, Jun 21, 2016 at 2:32 PM, Divesh Dutta <
divesh.dutta@hotwaxsystems.com> wrote:
> Thanks for detailed email Sharan. It was very informative. After reading
> all the details it totally makes sense that why should we move to Gradle
> from Ant. Overall work going in community to improve OFBiz is really
> amazing and I am really excited about this.
>
> Thanks
> --
> Divesh Dutta.
>
> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sh...@gmail.com>
> wrote:
>
>> Hi Everyone
>>
>> This is the second of two emails to inform the community about what has
>> been happening around how we are planning to handle external dependencies
>> in the trunk. Two weeks ago the community discussed and agreed to the use
>> of Gradle to help us put together a unit test framework. While trying to
>> get this set up while Ant remained as our build tool became very difficult.
>> This was because our Ant scripts:
>>
>> - are massive and contain a lot of code
>> - are complex
>> - are very brittle and make it very hard to change things
>> - have no dependency management
>> - need everything to be declared
>>
>> We realised very quickly that the re-factoring issues and limitations we
>> are facing are because of our build tool – Ant.
>>
>> Ant is verbose so it needs everything to be declared. We did a brief
>> assessment of Maven and found it better than Ant but not a good fit for
>> OFBiz because it has strict requirements for the
>> convention-over-configuration rules to work. Instead we decided to take a
>> closer look at Gradle.
>>
>> So why Gradle?
>> As Taher was already looking at Gradle for unit testing, we decided to
>> look at what we would need to do to totally replace Ant with Gradle. We
>> received some great support and feedback from David, who is already using
>> Gradle with Moqui.
>>
>> After some preliminary tests we found that Gradle has some very good
>> features such as:
>>
>> - a much shorter code base (e.g. one single file of around 250 lines
>> of code replaces all the build.xml files and thousands of lines of code)
>> - Programming is DSL based and links in well with Groovy (e.g. the
>> script is short because despite heavy custom requirements for OFBiz, two
>> small functions took care of the complex directory structure)
>> - It handles all the external jar files by downloading any
>> dependencies directly via internet
>> - Jars can be upgraded by simply changing a string
>> - It has matured a lot and has a high level of support in tools,IDEs,
>> books, documentation
>> - It also has a lot of plugins which means that it works with pretty
>> much all build systems, supports multiple programming languages, and many
>> other features (e.g. OSGi)
>>
>> We understand that it can help us make OFBiz more modular and also
>> setting up a framework for managing addons would be a lot easier.
>>
>> So what's been done?
>> Taher has been working very hard on a patch for the trunk that completely
>> replaces Ant with Gradle. (Huge thanks to David for providing some example
>> scripts to help us get started!) The patch is now ready to be applied to
>> the trunk and includes the following:
>>
>> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
>> --whatever-options-here'
>> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
>> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
>> commands, not just start
>> - If we decide to change the source directory structure in components
>> say from /src to /src/main, it would literally be a change of 5 characters
>> in the build script
>> - We can immediately move all jar files if we want to a unified
>> location in /lib for example
>> - We can delete most of the jars and declare them as dependencies
>> saving space and resources
>> - We can automate the creation of the .classpath file so when we
>> update libraries no need to do this manually (under development)
>> - We can ignore components that are not define in the xml files for
>> loading (under development)
>> - We can introduce unit tests with about 10 minutes of work
>>
>> We are finding that the flexibility and control we are getting with
>> Gradle is truly amazing. We know that Gradle will be a major change to the
>> project but we think that it will significantly improve the project by
>> removing a lot of build complexity and take care of that essential
>> dependency management that we need to comply with.
>>
>> Our next steps will be to apply the patch to the trunk and then continue
>> the re-factoring work. We will need to organise some knowledge transfer so
>> that all our committers understand what the changes are and how they would
>> need to work in the future.
>>
>> The PMC are very, very excited about having Gradle as part of future of
>> OFBiz and we hope that the community will think so too. As always, feedback
>> welcome.
>>
>> Thanks
>> Sharan
>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
Thanks for detailed email Sharan. It was very informative. After reading
all the details it totally makes sense that why should we move to Gradle
from Ant. Overall work going in community to improve OFBiz is really
amazing and I am really excited about this.
Thanks
--
Divesh Dutta.
On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Julien NICOLAS <ju...@nereide.fr>.
+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 <de...@hotwaxsystems.com>
> wrote:
>
>> +1 for Gradle.
>>
>> Are we going to remove ant from framework completely or planning to keep
>> both ant and gradle?
>>
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>> <javascript:;>> wrote:
>>
>>> Hi Everyone
>>>
>>> This is the second of two emails to inform the community about what has
>>> been happening around how we are planning to handle external dependencies
>>> in the trunk. Two weeks ago the community discussed and agreed to the use
>>> of Gradle to help us put together a unit test framework. While trying to
>>> get this set up while Ant remained as our build tool became very
>> difficult.
>>> This was because our Ant scripts:
>>>
>>> - are massive and contain a lot of code
>>> - are complex
>>> - are very brittle and make it very hard to change things
>>> - have no dependency management
>>> - need everything to be declared
>>>
>>> We realised very quickly that the re-factoring issues and limitations we
>>> are facing are because of our build tool \u2013 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
>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
Thanks Taher,
Sounds good to me.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Tue, Jun 21, 2016 at 11:41 AM, Taher Alkhateeb <
slidingfilaments@gmail.com> 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 <de...@hotwaxsystems.com>
> wrote:
>
> > +1 for Gradle.
> >
> > Are we going to remove ant from framework completely or planning to keep
> > both ant and gradle?
> >
> >
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > www.hotwaxsystems.com
> >
> > On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
> > <javascript:;>> wrote:
> >
> > > Hi Everyone
> > >
> > > This is the second of two emails to inform the community about what has
> > > been happening around how we are planning to handle external
> dependencies
> > > in the trunk. Two weeks ago the community discussed and agreed to the
> use
> > > of Gradle to help us put together a unit test framework. While trying
> to
> > > get this set up while Ant remained as our build tool became very
> > difficult.
> > > This was because our Ant scripts:
> > >
> > > - are massive and contain a lot of code
> > > - are complex
> > > - are very brittle and make it very hard to change things
> > > - have no dependency management
> > > - need everything to be declared
> > >
> > > We realised very quickly that the re-factoring issues and limitations
> we
> > > are facing are because of our build tool – Ant.
> > >
> > > Ant is verbose so it needs everything to be declared. We did a brief
> > > assessment of Maven and found it better than Ant but not a good fit for
> > > OFBiz because it has strict requirements for the
> > > convention-over-configuration rules to work. Instead we decided to
> take a
> > > closer look at Gradle.
> > >
> > > So why Gradle?
> > > As Taher was already looking at Gradle for unit testing, we decided to
> > > look at what we would need to do to totally replace Ant with Gradle. We
> > > received some great support and feedback from David, who is already
> using
> > > Gradle with Moqui.
> > >
> > > After some preliminary tests we found that Gradle has some very good
> > > features such as:
> > >
> > > - a much shorter code base (e.g. one single file of around 250 lines
> > of
> > > code replaces all the build.xml files and thousands of lines of code)
> > > - Programming is DSL based and links in well with Groovy (e.g. the
> > > script is short because despite heavy custom requirements for OFBiz,
> two
> > > small functions took care of the complex directory structure)
> > > - It handles all the external jar files by downloading any
> > dependencies
> > > directly via internet
> > > - Jars can be upgraded by simply changing a string
> > > - It has matured a lot and has a high level of support in
> tools,IDEs,
> > > books, documentation
> > > - It also has a lot of plugins which means that it works with pretty
> > > much all build systems, supports multiple programming languages, and
> many
> > > other features (e.g. OSGi)
> > >
> > > We understand that it can help us make OFBiz more modular and also
> > setting
> > > up a framework for managing addons would be a lot easier.
> > >
> > > So what's been done?
> > > Taher has been working very hard on a patch for the trunk that
> completely
> > > replaces Ant with Gradle. (Huge thanks to David for providing some
> > example
> > > scripts to help us get started!) The patch is now ready to be applied
> to
> > > the trunk and includes the following:
> > >
> > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > --whatever-options-here'
> > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > --whatever'. What does that mean? It means we can run debug on ALL
> ofbiz
> > > commands, not just start
> > > - If we decide to change the source directory structure in
> components
> > > say from /src to /src/main, it would literally be a change of 5
> > characters
> > > in the build script
> > > - We can immediately move all jar files if we want to a unified
> > > location in /lib for example
> > > - We can delete most of the jars and declare them as dependencies
> > > saving space and resources
> > > - We can automate the creation of the .classpath file so when we
> > > update libraries no need to do this manually (under development)
> > > - We can ignore components that are not define in the xml files for
> > > loading (under development)
> > > - We can introduce unit tests with about 10 minutes of work
> > >
> > > We are finding that the flexibility and control we are getting with
> > Gradle
> > > is truly amazing. We know that Gradle will be a major change to the
> > project
> > > but we think that it will significantly improve the project by
> removing a
> > > lot of build complexity and take care of that essential dependency
> > > management that we need to comply with.
> > >
> > > Our next steps will be to apply the patch to the trunk and then
> continue
> > > the re-factoring work. We will need to organise some knowledge transfer
> > so
> > > that all our committers understand what the changes are and how they
> > would
> > > need to work in the future.
> > >
> > > The PMC are very, very excited about having Gradle as part of future of
> > > OFBiz and we hope that the community will think so too. As always,
> > feedback
> > > welcome.
> > >
> > > Thanks
> > > Sharan
> > >
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by gil portenseigne <gi...@nereide.fr>.
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 <de...@hotwaxsystems.com>
>> wrote:
>>
>>> +1 for Gradle.
>>>
>>> Are we going to remove ant from framework completely or planning to
>>> keep
>>> both ant and gradle?
>>>
>>>
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>>
>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>> <javascript:;>> wrote:
>>>
>>>> Hi Everyone
>>>>
>>>> This is the second of two emails to inform the community about what
>>>> has
>>>> been happening around how we are planning to handle external
>>>> dependencies
>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>> the use
>>>> of Gradle to help us put together a unit test framework. While
>>>> trying to
>>>> get this set up while Ant remained as our build tool became very
>>> difficult.
>>>> This was because our Ant scripts:
>>>>
>>>> - are massive and contain a lot of code
>>>> - are complex
>>>> - are very brittle and make it very hard to change things
>>>> - have no dependency management
>>>> - need everything to be declared
>>>>
>>>> We realised very quickly that the re-factoring issues and
>>>> limitations we
>>>> are facing are because of our build tool \u2013 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
>>>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Julien NICOLAS <ju...@nereide.fr>.
For me, no problem to drop it.
Julien.
On 22/06/2016 16:23, Taher Alkhateeb wrote:
> Hi Michael Jacques and everyone,
>
> So I also want to confirm that you really need the following tasks:
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - revert-dev
>
> Are you using them yourselves? Here are the reasons why I suggest to remove
> them:
> - First, you must have the patch command existing in your environment, thus
> making the build script brittle
> - Second, it has this weird naming convention for patches and how they
> should be applied. I would imagine that every team and every company has
> its own style and methodology for patching and keeping track of files and
> changes. They use their own version control system and even different kinds
> of patches
> - It is dependent on a specific format of diff which you must generate
> either with svn diff or diff -Naur.
>
> It seems like it does not make a lot of sense to keep something like that
> when companies might completely ignore it and choose their own
> implementation strategies. Do you agree? Feedback?
>
> Taher Alkhateeb
>
> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> I wonder though why this was introduced. If we have no feedback from any
>> member of the community I think we can drop it. I don't see how to use it.
>>
>> Jacques
>>
>>
>>
>> Le 22/06/2016 � 14:43, Michael Brohl a �crit :
>>
>>> Hi Taher,
>>>
>>> no, I don't use it myself. This was just a guess by looking what the task
>>> does and it seemed to me this should be preserved.
>>> No problem to drop it from my side.
>>>
>>> Regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>
>>>> Hi Michael,
>>>>
>>>> Are you sure you are using "run-test-list"? This is an old task using a
>>>> target on the server called --testlist which essentially creates an ant
>>>> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz
>>>> in
>>>> between each run.
>>>>
>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>> this a
>>>> typo by you or are you actually using this target? The reason I ask is
>>>> because I actually wanted to delete the entire TestListContainer.java and
>>>> related files in the future. But now of course I hesitate.
>>>>
>>>> Thanks in advance for your feedback.
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>> michael.brohl@ecomify.de>
>>>> wrote:
>>>>
>>>> Hi Taher,
>>>>> First question:
>>>>>
>>>>> Don't drop:
>>>>>
>>>>> - build-dev
>>>>> - build-production
>>>>> - build-qa
>>>>> - build-test
>>>>> - refresh
>>>>> - revert-dev
>>>>> - run-test-list
>>>>>
>>>>> Drop:
>>>>>
>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>> - copy-dtds
>>>>> - download-PG-JDBC
>>>>> - download-activemq
>>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed if
>>>>> we
>>>>> use Gradle/automatic dependency mechanism)
>>>>>
>>>>>
>>>>> Not sure (I don't use them):
>>>>>
>>>>> - create-tenant
>>>>> - load-all-tenants
>>>>> - load-demo-multitenant
>>>>> - load-tenant
>>>>> - load-tenant-data-readers
>>>>> - gen-kek
>>>>> - gitinfo
>>>>> - run-test-list
>>>>> - start-batch-secure
>>>>> - start-both-secure
>>>>> - start-pos-secure
>>>>> - start-secure (...secure: not sure if these are needed anymore, I think
>>>>> Jacques can give some hints about them)
>>>>> - svninfo
>>>>>
>>>>> Second question: +1
>>>>>
>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>
>>>>> Hi Everyone,
>>>>>> I have create the JIRA
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>> for
>>>>>> this project
>>>>>>
>>>>>> I have two questions in this thread
>>>>>>
>>>>>> First Question
>>>>>> ------------------
>>>>>> Can I drop the below tasks from the build system? They currently exist
>>>>>> in
>>>>>> Ant but I am not sure whether they are actively used or not. So if you
>>>>>> want
>>>>>> me to add any of these tasks please reply to this thread, otherwise I
>>>>>> will
>>>>>> not include them in gradle. Please note I added all multi tenant tasks
>>>>>> because many of them are broken or have no functionality, so I am
>>>>>> assuming
>>>>>> people are doing multi-tenancy manually but not sure, so please help!
>>>>>>
>>>>>> - build-dev
>>>>>> - build-production
>>>>>> - build-qa
>>>>>> - build-test
>>>>>> - clean-ivy
>>>>>> - copy-dtds
>>>>>> - create-tenant
>>>>>> - download-PG-JDBC
>>>>>> - download-activemq
>>>>>> - download-mySQL-JDBC
>>>>>> - gen-kek
>>>>>> - gitinfo
>>>>>> - load-all-tenants
>>>>>> - load-demo-multitenant
>>>>>> - load-tenant
>>>>>> - load-tenant-data-readers
>>>>>> - refresh
>>>>>> - revert-dev
>>>>>> - run-test-list
>>>>>> - start-batch
>>>>>> - start-batch-secure
>>>>>> - start-both-secure
>>>>>> - start-pos-secure
>>>>>> - start-secure
>>>>>> - svninfo
>>>>>>
>>>>>> Second Question
>>>>>> -----------------------
>>>>>>
>>>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>>>> instead of load-extseed.
>>>>>>
>>>>>> If you would like to add the other load data tasks, please specify
>>>>>> which
>>>>>> ones.
>>>>>>
>>>>>> Appreciate your early responses.
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>
>>>>>>
>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hello Everyone,
I am very happy and thrilled to announce that OFBiz now has a skeleton for
a plug-in system without any changes to the code base :)
How did we design it
------------------------------
- Add all the components defined in framework/component-load.xml as gradle
subprojects
- Add all the components defined in applications/component-load.xml as
gradle subprojects
- Add all the components defined in specialcomponents/component-load.xml as
gradle subprojects
- Add the start component as a gradle subproject
- Add all the components in /hot-deploy as gradle subprojects
- Each subproject can _optionally_ have a build.gradle script
- If a directory exists in framework, applications or specialpurpose but is
not defined in component-load.xml, then it will be considered a dead
folder, it will not even compile and it will not be part of OFBiz and your
IDE will ignore it.
What are the benefits
-------------------------------
- Each subproject can declare its own library dependencies in its own
build.gradle away from the framework
- Compilation, running, and testing is centralized at the master build
script, making the subproject build scripts very small
- It is very easy now to "turn on" or "turn off" a plugin with a build
script that simply removes/adds it to component-load.xml!
- We can now design a full plug-in API and can design a full eco-system
around OFBiz.
- If we decide to, we do not _have to_ compile and test everything, we can
offload the maintenance of plugins to specialized teams, or even to third
parties.
So, maximum benefits without any code changes (except for may 30-40 lines
in the build scripts). I have a few ideas for a full API design in the
future (another thread perhaps) for these plugins (in gradle). The API
could contain tasks like:
- installPlugin
- activatePlugin
- deactivatePlugin
- uninstallPlugin
- etc ...
The latest patch in https://issues.apache.org/jira/browse/OFBIZ-7534 has
everything that I described above with all tests passing. Try it and enjoy.
Just comment-out any component in component-load.xml and observe how it
does not exist anymore :)
On Mon, Jun 27, 2016 at 6:30 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hey Everyone,
>
> I am exhausted, but I have a working patch in
> https://issues.apache.org/jira/browse/OFBIZ-7534
>
> This patch introduces gradle with all tests passing. I have also added a
> new README.md file which documents how to use this system. I think you will
> find the README.md file valuable for guidance on how to use and test. This
> is a big patch and requires a LOT of testing, so I need everyone to jump on
> board and help please.
>
> Oh, and I have a little rant
>
> ====== rant begins ======
> The classpath issues I faced with OFBiz are really horrible, and the
> design of the code base around classpaths is one of the worst I've even
> seen in my life. I cannot even fathom why we seperate classpaths for
> components and use this weird custom classloader. It took me so much time
> and thinking in delivering this patch just because of this damn issue
> ====== rant ends ======
>
> The executable is huge if you type ps ax|grep java. This is because of the
> unfortunately large and complex classpath. I will clean that up slowly as
> we progress.
>
> I look forward to your help and feedback.
>
> Taher Alkhateeb
>
> On Thu, Jun 23, 2016 at 6:23 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com> wrote:
>
>> Hey Guys,
>>
>> I've attached a text file in
>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>
>> This text file shows the old ant commands and how I implemented them
>> (most of them anyway) in Gradle. Please review it and provide your feedback:
>>
>> - Does it look correct?
>> - Are the parameters corrects?
>> - Are there any important missing tasks?
>> - Do you want to provide shorter versions for some of the tasks?
>>
>> Note, I only created two real short commands for OFBiz server commands:
>> loadDemo and testInteg. These exist because the most common command in
>> OFBiz would be ./gradlew cleanAll loadDemo testInteg
>>
>> I look forward to your feedback.
>>
>> Taher Alkhateeb
>>
>> On Wed, Jun 22, 2016 at 11:12 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com> wrote:
>>
>>> Hi Jacques,
>>>
>>> Thank you for the explanation. OK, between your feedback and the votes
>>> from other members, I'll keep them. Working on integration in gradle ...
>>>
>>> Cheers
>>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Jun 22, 2016 at 11:08 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> Hi Taher,
>>>>
>>>> Inline...
>>>>
>>>> Le 22/06/2016 à 16:23, Taher Alkhateeb a écrit :
>>>>
>>>>> Hi Michael Jacques and everyone,
>>>>>
>>>>> So I also want to confirm that you really need the following tasks:
>>>>>
>>>>> - build-dev
>>>>> - build-production
>>>>> - build-qa
>>>>> - build-test
>>>>> - revert-dev
>>>>>
>>>>
>>>> I introduced those for a custom project and improved it in the
>>>> following project I worked on. So yes I use these targets. BTW I documented
>>>> it at
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml
>>>> .
>>>>
>>>> Are you using them yourselves? Here are the reasons why I suggest to
>>>>> remove
>>>>> them:
>>>>> - First, you must have the patch command existing in your environment,
>>>>> thus
>>>>> making the build script brittle
>>>>>
>>>>
>>>> Actually it's a bit more complicated than that, see the comment above
>>>> the calculate-svn-patch-available target:
>>>> <!-- Following allow to use "svn patch" and fallback on "patch" if
>>>> necessary -->
>>>> and then
>>>> <!-- On Linux prefer patch because "svn patch" needs "ant exec and you
>>>> can't check patching errors -->
>>>>
>>>> - Second, it has this weird naming convention for patches and how they
>>>>> should be applied. I would imagine that every team and every company
>>>>> has
>>>>> its own style and methodology for patching and keeping track of files
>>>>> and
>>>>> changes. They use their own version control system and even different
>>>>> kinds
>>>>> of patches
>>>>> - It is dependent on a specific format of diff which you must generate
>>>>> either with svn diff or diff -Naur.
>>>>>
>>>>
>>>> This is useful even if you are using Git for your project. Why? Because
>>>> if, instead of relying on a released package, you decide to rely on the
>>>> trunk or a release branch you need to connect your project to the ASF svn
>>>> repo.
>>>> And yes it's possible to have both, I did it, used those targets and
>>>> was quite happy with them. I can agree it's a bit complicated, but not that
>>>> much when you look into details: they make sense.
>>>>
>>>> It seems like it does not make a lot of sense to keep something like
>>>>> that
>>>>> when companies might completely ignore it and choose their own
>>>>> implementation strategies. Do you agree? Feedback?
>>>>>
>>>>
>>>> You got mine :)
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> I wonder though why this was introduced. If we have no feedback from
>>>>>> any
>>>>>> member of the community I think we can drop it. I don't see how to
>>>>>> use it.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 22/06/2016 à 14:43, Michael Brohl a écrit :
>>>>>>
>>>>>> Hi Taher,
>>>>>>>
>>>>>>> no, I don't use it myself. This was just a guess by looking what the
>>>>>>> task
>>>>>>> does and it seemed to me this should be preserved.
>>>>>>> No problem to drop it from my side.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Michael Brohl
>>>>>>> ecomify GmbH
>>>>>>> www.ecomify.de
>>>>>>>
>>>>>>>
>>>>>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>>>
>>>>>>>> Are you sure you are using "run-test-list"? This is an old task
>>>>>>>> using a
>>>>>>>> target on the server called --testlist which essentially creates an
>>>>>>>> ant
>>>>>>>> file of all the suites in OFBiz and runs them one-by-one stopping
>>>>>>>> OFBiz
>>>>>>>> in
>>>>>>>> between each run.
>>>>>>>>
>>>>>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>>>>>> this a
>>>>>>>> typo by you or are you actually using this target? The reason I ask
>>>>>>>> is
>>>>>>>> because I actually wanted to delete the entire
>>>>>>>> TestListContainer.java and
>>>>>>>> related files in the future. But now of course I hesitate.
>>>>>>>>
>>>>>>>> Thanks in advance for your feedback.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>>>>>> michael.brohl@ecomify.de>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Taher,
>>>>>>>>
>>>>>>>>> First question:
>>>>>>>>>
>>>>>>>>> Don't drop:
>>>>>>>>>
>>>>>>>>> - build-dev
>>>>>>>>> - build-production
>>>>>>>>> - build-qa
>>>>>>>>> - build-test
>>>>>>>>> - refresh
>>>>>>>>> - revert-dev
>>>>>>>>> - run-test-list
>>>>>>>>>
>>>>>>>>> Drop:
>>>>>>>>>
>>>>>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>>>>>> - copy-dtds
>>>>>>>>> - download-PG-JDBC
>>>>>>>>> - download-activemq
>>>>>>>>> - download-mySQL-JDBC (download tasks: assuming they are not
>>>>>>>>> needed if
>>>>>>>>> we
>>>>>>>>> use Gradle/automatic dependency mechanism)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure (I don't use them):
>>>>>>>>>
>>>>>>>>> - create-tenant
>>>>>>>>> - load-all-tenants
>>>>>>>>> - load-demo-multitenant
>>>>>>>>> - load-tenant
>>>>>>>>> - load-tenant-data-readers
>>>>>>>>> - gen-kek
>>>>>>>>> - gitinfo
>>>>>>>>> - run-test-list
>>>>>>>>> - start-batch-secure
>>>>>>>>> - start-both-secure
>>>>>>>>> - start-pos-secure
>>>>>>>>> - start-secure (...secure: not sure if these are needed anymore, I
>>>>>>>>> think
>>>>>>>>> Jacques can give some hints about them)
>>>>>>>>> - svninfo
>>>>>>>>>
>>>>>>>>> Second question: +1
>>>>>>>>>
>>>>>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Michael Brohl
>>>>>>>>> ecomify GmbH
>>>>>>>>> www.ecomify.de
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>>>>>
>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>>> I have create the JIRA
>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>>>>>> for
>>>>>>>>>> this project
>>>>>>>>>>
>>>>>>>>>> I have two questions in this thread
>>>>>>>>>>
>>>>>>>>>> First Question
>>>>>>>>>> ------------------
>>>>>>>>>> Can I drop the below tasks from the build system? They currently
>>>>>>>>>> exist
>>>>>>>>>> in
>>>>>>>>>> Ant but I am not sure whether they are actively used or not. So
>>>>>>>>>> if you
>>>>>>>>>> want
>>>>>>>>>> me to add any of these tasks please reply to this thread,
>>>>>>>>>> otherwise I
>>>>>>>>>> will
>>>>>>>>>> not include them in gradle. Please note I added all multi tenant
>>>>>>>>>> tasks
>>>>>>>>>> because many of them are broken or have no functionality, so I am
>>>>>>>>>> assuming
>>>>>>>>>> people are doing multi-tenancy manually but not sure, so please
>>>>>>>>>> help!
>>>>>>>>>>
>>>>>>>>>> - build-dev
>>>>>>>>>> - build-production
>>>>>>>>>> - build-qa
>>>>>>>>>> - build-test
>>>>>>>>>> - clean-ivy
>>>>>>>>>> - copy-dtds
>>>>>>>>>> - create-tenant
>>>>>>>>>> - download-PG-JDBC
>>>>>>>>>> - download-activemq
>>>>>>>>>> - download-mySQL-JDBC
>>>>>>>>>> - gen-kek
>>>>>>>>>> - gitinfo
>>>>>>>>>> - load-all-tenants
>>>>>>>>>> - load-demo-multitenant
>>>>>>>>>> - load-tenant
>>>>>>>>>> - load-tenant-data-readers
>>>>>>>>>> - refresh
>>>>>>>>>> - revert-dev
>>>>>>>>>> - run-test-list
>>>>>>>>>> - start-batch
>>>>>>>>>> - start-batch-secure
>>>>>>>>>> - start-both-secure
>>>>>>>>>> - start-pos-secure
>>>>>>>>>> - start-secure
>>>>>>>>>> - svninfo
>>>>>>>>>>
>>>>>>>>>> Second Question
>>>>>>>>>> -----------------------
>>>>>>>>>>
>>>>>>>>>> it seems many of the load tasks are too specific. So I suggest to
>>>>>>>>>> only
>>>>>>>>>> implement loadDemo and the rest are executed manually by users,
>>>>>>>>>> for
>>>>>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial,
>>>>>>>>>> ext'
>>>>>>>>>> instead of load-extseed.
>>>>>>>>>>
>>>>>>>>>> If you would like to add the other load data tasks, please specify
>>>>>>>>>> which
>>>>>>>>>> ones.
>>>>>>>>>>
>>>>>>>>>> Appreciate your early responses.
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>
>>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hey Everyone,
I am exhausted, but I have a working patch in
https://issues.apache.org/jira/browse/OFBIZ-7534
This patch introduces gradle with all tests passing. I have also added a
new README.md file which documents how to use this system. I think you will
find the README.md file valuable for guidance on how to use and test. This
is a big patch and requires a LOT of testing, so I need everyone to jump on
board and help please.
Oh, and I have a little rant
====== rant begins ======
The classpath issues I faced with OFBiz are really horrible, and the design
of the code base around classpaths is one of the worst I've even seen in my
life. I cannot even fathom why we seperate classpaths for components and
use this weird custom classloader. It took me so much time and thinking in
delivering this patch just because of this damn issue
====== rant ends ======
The executable is huge if you type ps ax|grep java. This is because of the
unfortunately large and complex classpath. I will clean that up slowly as
we progress.
I look forward to your help and feedback.
Taher Alkhateeb
On Thu, Jun 23, 2016 at 6:23 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hey Guys,
>
> I've attached a text file in
> https://issues.apache.org/jira/browse/OFBIZ-7534
>
> This text file shows the old ant commands and how I implemented them (most
> of them anyway) in Gradle. Please review it and provide your feedback:
>
> - Does it look correct?
> - Are the parameters corrects?
> - Are there any important missing tasks?
> - Do you want to provide shorter versions for some of the tasks?
>
> Note, I only created two real short commands for OFBiz server commands:
> loadDemo and testInteg. These exist because the most common command in
> OFBiz would be ./gradlew cleanAll loadDemo testInteg
>
> I look forward to your feedback.
>
> Taher Alkhateeb
>
> On Wed, Jun 22, 2016 at 11:12 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com> wrote:
>
>> Hi Jacques,
>>
>> Thank you for the explanation. OK, between your feedback and the votes
>> from other members, I'll keep them. Working on integration in gradle ...
>>
>> Cheers
>>
>> Taher Alkhateeb
>>
>> On Wed, Jun 22, 2016 at 11:08 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Hi Taher,
>>>
>>> Inline...
>>>
>>> Le 22/06/2016 à 16:23, Taher Alkhateeb a écrit :
>>>
>>>> Hi Michael Jacques and everyone,
>>>>
>>>> So I also want to confirm that you really need the following tasks:
>>>>
>>>> - build-dev
>>>> - build-production
>>>> - build-qa
>>>> - build-test
>>>> - revert-dev
>>>>
>>>
>>> I introduced those for a custom project and improved it in the following
>>> project I worked on. So yes I use these targets. BTW I documented it at
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml
>>> .
>>>
>>> Are you using them yourselves? Here are the reasons why I suggest to
>>>> remove
>>>> them:
>>>> - First, you must have the patch command existing in your environment,
>>>> thus
>>>> making the build script brittle
>>>>
>>>
>>> Actually it's a bit more complicated than that, see the comment above
>>> the calculate-svn-patch-available target:
>>> <!-- Following allow to use "svn patch" and fallback on "patch" if
>>> necessary -->
>>> and then
>>> <!-- On Linux prefer patch because "svn patch" needs "ant exec and you
>>> can't check patching errors -->
>>>
>>> - Second, it has this weird naming convention for patches and how they
>>>> should be applied. I would imagine that every team and every company has
>>>> its own style and methodology for patching and keeping track of files
>>>> and
>>>> changes. They use their own version control system and even different
>>>> kinds
>>>> of patches
>>>> - It is dependent on a specific format of diff which you must generate
>>>> either with svn diff or diff -Naur.
>>>>
>>>
>>> This is useful even if you are using Git for your project. Why? Because
>>> if, instead of relying on a released package, you decide to rely on the
>>> trunk or a release branch you need to connect your project to the ASF svn
>>> repo.
>>> And yes it's possible to have both, I did it, used those targets and was
>>> quite happy with them. I can agree it's a bit complicated, but not that
>>> much when you look into details: they make sense.
>>>
>>> It seems like it does not make a lot of sense to keep something like that
>>>> when companies might completely ignore it and choose their own
>>>> implementation strategies. Do you agree? Feedback?
>>>>
>>>
>>> You got mine :)
>>>
>>> Jacques
>>>
>>>
>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> I wonder though why this was introduced. If we have no feedback from any
>>>>> member of the community I think we can drop it. I don't see how to use
>>>>> it.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 22/06/2016 à 14:43, Michael Brohl a écrit :
>>>>>
>>>>> Hi Taher,
>>>>>>
>>>>>> no, I don't use it myself. This was just a guess by looking what the
>>>>>> task
>>>>>> does and it seemed to me this should be preserved.
>>>>>> No problem to drop it from my side.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>> ecomify GmbH
>>>>>> www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>>>>
>>>>>> Hi Michael,
>>>>>>>
>>>>>>> Are you sure you are using "run-test-list"? This is an old task
>>>>>>> using a
>>>>>>> target on the server called --testlist which essentially creates an
>>>>>>> ant
>>>>>>> file of all the suites in OFBiz and runs them one-by-one stopping
>>>>>>> OFBiz
>>>>>>> in
>>>>>>> between each run.
>>>>>>>
>>>>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>>>>> this a
>>>>>>> typo by you or are you actually using this target? The reason I ask
>>>>>>> is
>>>>>>> because I actually wanted to delete the entire
>>>>>>> TestListContainer.java and
>>>>>>> related files in the future. But now of course I hesitate.
>>>>>>>
>>>>>>> Thanks in advance for your feedback.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>>>>> michael.brohl@ecomify.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Taher,
>>>>>>>
>>>>>>>> First question:
>>>>>>>>
>>>>>>>> Don't drop:
>>>>>>>>
>>>>>>>> - build-dev
>>>>>>>> - build-production
>>>>>>>> - build-qa
>>>>>>>> - build-test
>>>>>>>> - refresh
>>>>>>>> - revert-dev
>>>>>>>> - run-test-list
>>>>>>>>
>>>>>>>> Drop:
>>>>>>>>
>>>>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>>>>> - copy-dtds
>>>>>>>> - download-PG-JDBC
>>>>>>>> - download-activemq
>>>>>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed
>>>>>>>> if
>>>>>>>> we
>>>>>>>> use Gradle/automatic dependency mechanism)
>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure (I don't use them):
>>>>>>>>
>>>>>>>> - create-tenant
>>>>>>>> - load-all-tenants
>>>>>>>> - load-demo-multitenant
>>>>>>>> - load-tenant
>>>>>>>> - load-tenant-data-readers
>>>>>>>> - gen-kek
>>>>>>>> - gitinfo
>>>>>>>> - run-test-list
>>>>>>>> - start-batch-secure
>>>>>>>> - start-both-secure
>>>>>>>> - start-pos-secure
>>>>>>>> - start-secure (...secure: not sure if these are needed anymore, I
>>>>>>>> think
>>>>>>>> Jacques can give some hints about them)
>>>>>>>> - svninfo
>>>>>>>>
>>>>>>>> Second question: +1
>>>>>>>>
>>>>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Michael Brohl
>>>>>>>> ecomify GmbH
>>>>>>>> www.ecomify.de
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>>> I have create the JIRA
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>>>>> for
>>>>>>>>> this project
>>>>>>>>>
>>>>>>>>> I have two questions in this thread
>>>>>>>>>
>>>>>>>>> First Question
>>>>>>>>> ------------------
>>>>>>>>> Can I drop the below tasks from the build system? They currently
>>>>>>>>> exist
>>>>>>>>> in
>>>>>>>>> Ant but I am not sure whether they are actively used or not. So if
>>>>>>>>> you
>>>>>>>>> want
>>>>>>>>> me to add any of these tasks please reply to this thread,
>>>>>>>>> otherwise I
>>>>>>>>> will
>>>>>>>>> not include them in gradle. Please note I added all multi tenant
>>>>>>>>> tasks
>>>>>>>>> because many of them are broken or have no functionality, so I am
>>>>>>>>> assuming
>>>>>>>>> people are doing multi-tenancy manually but not sure, so please
>>>>>>>>> help!
>>>>>>>>>
>>>>>>>>> - build-dev
>>>>>>>>> - build-production
>>>>>>>>> - build-qa
>>>>>>>>> - build-test
>>>>>>>>> - clean-ivy
>>>>>>>>> - copy-dtds
>>>>>>>>> - create-tenant
>>>>>>>>> - download-PG-JDBC
>>>>>>>>> - download-activemq
>>>>>>>>> - download-mySQL-JDBC
>>>>>>>>> - gen-kek
>>>>>>>>> - gitinfo
>>>>>>>>> - load-all-tenants
>>>>>>>>> - load-demo-multitenant
>>>>>>>>> - load-tenant
>>>>>>>>> - load-tenant-data-readers
>>>>>>>>> - refresh
>>>>>>>>> - revert-dev
>>>>>>>>> - run-test-list
>>>>>>>>> - start-batch
>>>>>>>>> - start-batch-secure
>>>>>>>>> - start-both-secure
>>>>>>>>> - start-pos-secure
>>>>>>>>> - start-secure
>>>>>>>>> - svninfo
>>>>>>>>>
>>>>>>>>> Second Question
>>>>>>>>> -----------------------
>>>>>>>>>
>>>>>>>>> it seems many of the load tasks are too specific. So I suggest to
>>>>>>>>> only
>>>>>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial,
>>>>>>>>> ext'
>>>>>>>>> instead of load-extseed.
>>>>>>>>>
>>>>>>>>> If you would like to add the other load data tasks, please specify
>>>>>>>>> which
>>>>>>>>> ones.
>>>>>>>>>
>>>>>>>>> Appreciate your early responses.
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hey Guys,
I've attached a text file in
https://issues.apache.org/jira/browse/OFBIZ-7534
This text file shows the old ant commands and how I implemented them (most
of them anyway) in Gradle. Please review it and provide your feedback:
- Does it look correct?
- Are the parameters corrects?
- Are there any important missing tasks?
- Do you want to provide shorter versions for some of the tasks?
Note, I only created two real short commands for OFBiz server commands:
loadDemo and testInteg. These exist because the most common command in
OFBiz would be ./gradlew cleanAll loadDemo testInteg
I look forward to your feedback.
Taher Alkhateeb
On Wed, Jun 22, 2016 at 11:12 PM, Taher Alkhateeb <
slidingfilaments@gmail.com> wrote:
> Hi Jacques,
>
> Thank you for the explanation. OK, between your feedback and the votes
> from other members, I'll keep them. Working on integration in gradle ...
>
> Cheers
>
> Taher Alkhateeb
>
> On Wed, Jun 22, 2016 at 11:08 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Taher,
>>
>> Inline...
>>
>> Le 22/06/2016 à 16:23, Taher Alkhateeb a écrit :
>>
>>> Hi Michael Jacques and everyone,
>>>
>>> So I also want to confirm that you really need the following tasks:
>>>
>>> - build-dev
>>> - build-production
>>> - build-qa
>>> - build-test
>>> - revert-dev
>>>
>>
>> I introduced those for a custom project and improved it in the following
>> project I worked on. So yes I use these targets. BTW I documented it at
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml
>> .
>>
>> Are you using them yourselves? Here are the reasons why I suggest to
>>> remove
>>> them:
>>> - First, you must have the patch command existing in your environment,
>>> thus
>>> making the build script brittle
>>>
>>
>> Actually it's a bit more complicated than that, see the comment above the
>> calculate-svn-patch-available target:
>> <!-- Following allow to use "svn patch" and fallback on "patch" if
>> necessary -->
>> and then
>> <!-- On Linux prefer patch because "svn patch" needs "ant exec and you
>> can't check patching errors -->
>>
>> - Second, it has this weird naming convention for patches and how they
>>> should be applied. I would imagine that every team and every company has
>>> its own style and methodology for patching and keeping track of files and
>>> changes. They use their own version control system and even different
>>> kinds
>>> of patches
>>> - It is dependent on a specific format of diff which you must generate
>>> either with svn diff or diff -Naur.
>>>
>>
>> This is useful even if you are using Git for your project. Why? Because
>> if, instead of relying on a released package, you decide to rely on the
>> trunk or a release branch you need to connect your project to the ASF svn
>> repo.
>> And yes it's possible to have both, I did it, used those targets and was
>> quite happy with them. I can agree it's a bit complicated, but not that
>> much when you look into details: they make sense.
>>
>> It seems like it does not make a lot of sense to keep something like that
>>> when companies might completely ignore it and choose their own
>>> implementation strategies. Do you agree? Feedback?
>>>
>>
>> You got mine :)
>>
>> Jacques
>>
>>
>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> I wonder though why this was introduced. If we have no feedback from any
>>>> member of the community I think we can drop it. I don't see how to use
>>>> it.
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 22/06/2016 à 14:43, Michael Brohl a écrit :
>>>>
>>>> Hi Taher,
>>>>>
>>>>> no, I don't use it myself. This was just a guess by looking what the
>>>>> task
>>>>> does and it seemed to me this should be preserved.
>>>>> No problem to drop it from my side.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>>>
>>>>> Hi Michael,
>>>>>>
>>>>>> Are you sure you are using "run-test-list"? This is an old task using
>>>>>> a
>>>>>> target on the server called --testlist which essentially creates an
>>>>>> ant
>>>>>> file of all the suites in OFBiz and runs them one-by-one stopping
>>>>>> OFBiz
>>>>>> in
>>>>>> between each run.
>>>>>>
>>>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>>>> this a
>>>>>> typo by you or are you actually using this target? The reason I ask is
>>>>>> because I actually wanted to delete the entire TestListContainer.java
>>>>>> and
>>>>>> related files in the future. But now of course I hesitate.
>>>>>>
>>>>>> Thanks in advance for your feedback.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>>>> michael.brohl@ecomify.de>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>
>>>>>>> First question:
>>>>>>>
>>>>>>> Don't drop:
>>>>>>>
>>>>>>> - build-dev
>>>>>>> - build-production
>>>>>>> - build-qa
>>>>>>> - build-test
>>>>>>> - refresh
>>>>>>> - revert-dev
>>>>>>> - run-test-list
>>>>>>>
>>>>>>> Drop:
>>>>>>>
>>>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>>>> - copy-dtds
>>>>>>> - download-PG-JDBC
>>>>>>> - download-activemq
>>>>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed
>>>>>>> if
>>>>>>> we
>>>>>>> use Gradle/automatic dependency mechanism)
>>>>>>>
>>>>>>>
>>>>>>> Not sure (I don't use them):
>>>>>>>
>>>>>>> - create-tenant
>>>>>>> - load-all-tenants
>>>>>>> - load-demo-multitenant
>>>>>>> - load-tenant
>>>>>>> - load-tenant-data-readers
>>>>>>> - gen-kek
>>>>>>> - gitinfo
>>>>>>> - run-test-list
>>>>>>> - start-batch-secure
>>>>>>> - start-both-secure
>>>>>>> - start-pos-secure
>>>>>>> - start-secure (...secure: not sure if these are needed anymore, I
>>>>>>> think
>>>>>>> Jacques can give some hints about them)
>>>>>>> - svninfo
>>>>>>>
>>>>>>> Second question: +1
>>>>>>>
>>>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Michael Brohl
>>>>>>> ecomify GmbH
>>>>>>> www.ecomify.de
>>>>>>>
>>>>>>>
>>>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>>> I have create the JIRA
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>>>> for
>>>>>>>> this project
>>>>>>>>
>>>>>>>> I have two questions in this thread
>>>>>>>>
>>>>>>>> First Question
>>>>>>>> ------------------
>>>>>>>> Can I drop the below tasks from the build system? They currently
>>>>>>>> exist
>>>>>>>> in
>>>>>>>> Ant but I am not sure whether they are actively used or not. So if
>>>>>>>> you
>>>>>>>> want
>>>>>>>> me to add any of these tasks please reply to this thread, otherwise
>>>>>>>> I
>>>>>>>> will
>>>>>>>> not include them in gradle. Please note I added all multi tenant
>>>>>>>> tasks
>>>>>>>> because many of them are broken or have no functionality, so I am
>>>>>>>> assuming
>>>>>>>> people are doing multi-tenancy manually but not sure, so please
>>>>>>>> help!
>>>>>>>>
>>>>>>>> - build-dev
>>>>>>>> - build-production
>>>>>>>> - build-qa
>>>>>>>> - build-test
>>>>>>>> - clean-ivy
>>>>>>>> - copy-dtds
>>>>>>>> - create-tenant
>>>>>>>> - download-PG-JDBC
>>>>>>>> - download-activemq
>>>>>>>> - download-mySQL-JDBC
>>>>>>>> - gen-kek
>>>>>>>> - gitinfo
>>>>>>>> - load-all-tenants
>>>>>>>> - load-demo-multitenant
>>>>>>>> - load-tenant
>>>>>>>> - load-tenant-data-readers
>>>>>>>> - refresh
>>>>>>>> - revert-dev
>>>>>>>> - run-test-list
>>>>>>>> - start-batch
>>>>>>>> - start-batch-secure
>>>>>>>> - start-both-secure
>>>>>>>> - start-pos-secure
>>>>>>>> - start-secure
>>>>>>>> - svninfo
>>>>>>>>
>>>>>>>> Second Question
>>>>>>>> -----------------------
>>>>>>>>
>>>>>>>> it seems many of the load tasks are too specific. So I suggest to
>>>>>>>> only
>>>>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial,
>>>>>>>> ext'
>>>>>>>> instead of load-extseed.
>>>>>>>>
>>>>>>>> If you would like to add the other load data tasks, please specify
>>>>>>>> which
>>>>>>>> ones.
>>>>>>>>
>>>>>>>> Appreciate your early responses.
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
Thank you for the explanation. OK, between your feedback and the votes from
other members, I'll keep them. Working on integration in gradle ...
Cheers
Taher Alkhateeb
On Wed, Jun 22, 2016 at 11:08 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi Taher,
>
> Inline...
>
> Le 22/06/2016 à 16:23, Taher Alkhateeb a écrit :
>
>> Hi Michael Jacques and everyone,
>>
>> So I also want to confirm that you really need the following tasks:
>>
>> - build-dev
>> - build-production
>> - build-qa
>> - build-test
>> - revert-dev
>>
>
> I introduced those for a custom project and improved it in the following
> project I worked on. So yes I use these targets. BTW I documented it at
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml
> .
>
> Are you using them yourselves? Here are the reasons why I suggest to remove
>> them:
>> - First, you must have the patch command existing in your environment,
>> thus
>> making the build script brittle
>>
>
> Actually it's a bit more complicated than that, see the comment above the
> calculate-svn-patch-available target:
> <!-- Following allow to use "svn patch" and fallback on "patch" if
> necessary -->
> and then
> <!-- On Linux prefer patch because "svn patch" needs "ant exec and you
> can't check patching errors -->
>
> - Second, it has this weird naming convention for patches and how they
>> should be applied. I would imagine that every team and every company has
>> its own style and methodology for patching and keeping track of files and
>> changes. They use their own version control system and even different
>> kinds
>> of patches
>> - It is dependent on a specific format of diff which you must generate
>> either with svn diff or diff -Naur.
>>
>
> This is useful even if you are using Git for your project. Why? Because
> if, instead of relying on a released package, you decide to rely on the
> trunk or a release branch you need to connect your project to the ASF svn
> repo.
> And yes it's possible to have both, I did it, used those targets and was
> quite happy with them. I can agree it's a bit complicated, but not that
> much when you look into details: they make sense.
>
> It seems like it does not make a lot of sense to keep something like that
>> when companies might completely ignore it and choose their own
>> implementation strategies. Do you agree? Feedback?
>>
>
> You got mine :)
>
> Jacques
>
>
>
>> Taher Alkhateeb
>>
>> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> I wonder though why this was introduced. If we have no feedback from any
>>> member of the community I think we can drop it. I don't see how to use
>>> it.
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 22/06/2016 à 14:43, Michael Brohl a écrit :
>>>
>>> Hi Taher,
>>>>
>>>> no, I don't use it myself. This was just a guess by looking what the
>>>> task
>>>> does and it seemed to me this should be preserved.
>>>> No problem to drop it from my side.
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>>
>>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>>
>>>> Hi Michael,
>>>>>
>>>>> Are you sure you are using "run-test-list"? This is an old task using a
>>>>> target on the server called --testlist which essentially creates an ant
>>>>> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz
>>>>> in
>>>>> between each run.
>>>>>
>>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>>> this a
>>>>> typo by you or are you actually using this target? The reason I ask is
>>>>> because I actually wanted to delete the entire TestListContainer.java
>>>>> and
>>>>> related files in the future. But now of course I hesitate.
>>>>>
>>>>> Thanks in advance for your feedback.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>>> michael.brohl@ecomify.de>
>>>>> wrote:
>>>>>
>>>>> Hi Taher,
>>>>>
>>>>>> First question:
>>>>>>
>>>>>> Don't drop:
>>>>>>
>>>>>> - build-dev
>>>>>> - build-production
>>>>>> - build-qa
>>>>>> - build-test
>>>>>> - refresh
>>>>>> - revert-dev
>>>>>> - run-test-list
>>>>>>
>>>>>> Drop:
>>>>>>
>>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>>> - copy-dtds
>>>>>> - download-PG-JDBC
>>>>>> - download-activemq
>>>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed if
>>>>>> we
>>>>>> use Gradle/automatic dependency mechanism)
>>>>>>
>>>>>>
>>>>>> Not sure (I don't use them):
>>>>>>
>>>>>> - create-tenant
>>>>>> - load-all-tenants
>>>>>> - load-demo-multitenant
>>>>>> - load-tenant
>>>>>> - load-tenant-data-readers
>>>>>> - gen-kek
>>>>>> - gitinfo
>>>>>> - run-test-list
>>>>>> - start-batch-secure
>>>>>> - start-both-secure
>>>>>> - start-pos-secure
>>>>>> - start-secure (...secure: not sure if these are needed anymore, I
>>>>>> think
>>>>>> Jacques can give some hints about them)
>>>>>> - svninfo
>>>>>>
>>>>>> Second question: +1
>>>>>>
>>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>> ecomify GmbH
>>>>>> www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>>> I have create the JIRA
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>>> for
>>>>>>> this project
>>>>>>>
>>>>>>> I have two questions in this thread
>>>>>>>
>>>>>>> First Question
>>>>>>> ------------------
>>>>>>> Can I drop the below tasks from the build system? They currently
>>>>>>> exist
>>>>>>> in
>>>>>>> Ant but I am not sure whether they are actively used or not. So if
>>>>>>> you
>>>>>>> want
>>>>>>> me to add any of these tasks please reply to this thread, otherwise I
>>>>>>> will
>>>>>>> not include them in gradle. Please note I added all multi tenant
>>>>>>> tasks
>>>>>>> because many of them are broken or have no functionality, so I am
>>>>>>> assuming
>>>>>>> people are doing multi-tenancy manually but not sure, so please help!
>>>>>>>
>>>>>>> - build-dev
>>>>>>> - build-production
>>>>>>> - build-qa
>>>>>>> - build-test
>>>>>>> - clean-ivy
>>>>>>> - copy-dtds
>>>>>>> - create-tenant
>>>>>>> - download-PG-JDBC
>>>>>>> - download-activemq
>>>>>>> - download-mySQL-JDBC
>>>>>>> - gen-kek
>>>>>>> - gitinfo
>>>>>>> - load-all-tenants
>>>>>>> - load-demo-multitenant
>>>>>>> - load-tenant
>>>>>>> - load-tenant-data-readers
>>>>>>> - refresh
>>>>>>> - revert-dev
>>>>>>> - run-test-list
>>>>>>> - start-batch
>>>>>>> - start-batch-secure
>>>>>>> - start-both-secure
>>>>>>> - start-pos-secure
>>>>>>> - start-secure
>>>>>>> - svninfo
>>>>>>>
>>>>>>> Second Question
>>>>>>> -----------------------
>>>>>>>
>>>>>>> it seems many of the load tasks are too specific. So I suggest to
>>>>>>> only
>>>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>>>>> instead of load-extseed.
>>>>>>>
>>>>>>> If you would like to add the other load data tasks, please specify
>>>>>>> which
>>>>>>> ones.
>>>>>>>
>>>>>>> Appreciate your early responses.
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Taher,
Inline...
Le 22/06/2016 � 16:23, Taher Alkhateeb a �crit :
> Hi Michael Jacques and everyone,
>
> So I also want to confirm that you really need the following tasks:
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - revert-dev
I introduced those for a custom project and improved it in the following project I worked on. So yes I use these targets. BTW I documented it at
https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml.
> Are you using them yourselves? Here are the reasons why I suggest to remove
> them:
> - First, you must have the patch command existing in your environment, thus
> making the build script brittle
Actually it's a bit more complicated than that, see the comment above the calculate-svn-patch-available target:
<!-- Following allow to use "svn patch" and fallback on "patch" if necessary -->
and then
<!-- On Linux prefer patch because "svn patch" needs "ant exec and you can't check patching errors -->
> - Second, it has this weird naming convention for patches and how they
> should be applied. I would imagine that every team and every company has
> its own style and methodology for patching and keeping track of files and
> changes. They use their own version control system and even different kinds
> of patches
> - It is dependent on a specific format of diff which you must generate
> either with svn diff or diff -Naur.
This is useful even if you are using Git for your project. Why? Because if, instead of relying on a released package, you decide to rely on the trunk
or a release branch you need to connect your project to the ASF svn repo.
And yes it's possible to have both, I did it, used those targets and was quite happy with them. I can agree it's a bit complicated, but not that much
when you look into details: they make sense.
> It seems like it does not make a lot of sense to keep something like that
> when companies might completely ignore it and choose their own
> implementation strategies. Do you agree? Feedback?
You got mine :)
Jacques
>
> Taher Alkhateeb
>
> On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> I wonder though why this was introduced. If we have no feedback from any
>> member of the community I think we can drop it. I don't see how to use it.
>>
>> Jacques
>>
>>
>>
>> Le 22/06/2016 � 14:43, Michael Brohl a �crit :
>>
>>> Hi Taher,
>>>
>>> no, I don't use it myself. This was just a guess by looking what the task
>>> does and it seemed to me this should be preserved.
>>> No problem to drop it from my side.
>>>
>>> Regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>>
>>>> Hi Michael,
>>>>
>>>> Are you sure you are using "run-test-list"? This is an old task using a
>>>> target on the server called --testlist which essentially creates an ant
>>>> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz
>>>> in
>>>> between each run.
>>>>
>>>> To me it seems like run-tests is doing the same thing but faster. Is
>>>> this a
>>>> typo by you or are you actually using this target? The reason I ask is
>>>> because I actually wanted to delete the entire TestListContainer.java and
>>>> related files in the future. But now of course I hesitate.
>>>>
>>>> Thanks in advance for your feedback.
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>>> michael.brohl@ecomify.de>
>>>> wrote:
>>>>
>>>> Hi Taher,
>>>>> First question:
>>>>>
>>>>> Don't drop:
>>>>>
>>>>> - build-dev
>>>>> - build-production
>>>>> - build-qa
>>>>> - build-test
>>>>> - refresh
>>>>> - revert-dev
>>>>> - run-test-list
>>>>>
>>>>> Drop:
>>>>>
>>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>>> - copy-dtds
>>>>> - download-PG-JDBC
>>>>> - download-activemq
>>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed if
>>>>> we
>>>>> use Gradle/automatic dependency mechanism)
>>>>>
>>>>>
>>>>> Not sure (I don't use them):
>>>>>
>>>>> - create-tenant
>>>>> - load-all-tenants
>>>>> - load-demo-multitenant
>>>>> - load-tenant
>>>>> - load-tenant-data-readers
>>>>> - gen-kek
>>>>> - gitinfo
>>>>> - run-test-list
>>>>> - start-batch-secure
>>>>> - start-both-secure
>>>>> - start-pos-secure
>>>>> - start-secure (...secure: not sure if these are needed anymore, I think
>>>>> Jacques can give some hints about them)
>>>>> - svninfo
>>>>>
>>>>> Second question: +1
>>>>>
>>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>>
>>>>> Hi Everyone,
>>>>>> I have create the JIRA
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>>> for
>>>>>> this project
>>>>>>
>>>>>> I have two questions in this thread
>>>>>>
>>>>>> First Question
>>>>>> ------------------
>>>>>> Can I drop the below tasks from the build system? They currently exist
>>>>>> in
>>>>>> Ant but I am not sure whether they are actively used or not. So if you
>>>>>> want
>>>>>> me to add any of these tasks please reply to this thread, otherwise I
>>>>>> will
>>>>>> not include them in gradle. Please note I added all multi tenant tasks
>>>>>> because many of them are broken or have no functionality, so I am
>>>>>> assuming
>>>>>> people are doing multi-tenancy manually but not sure, so please help!
>>>>>>
>>>>>> - build-dev
>>>>>> - build-production
>>>>>> - build-qa
>>>>>> - build-test
>>>>>> - clean-ivy
>>>>>> - copy-dtds
>>>>>> - create-tenant
>>>>>> - download-PG-JDBC
>>>>>> - download-activemq
>>>>>> - download-mySQL-JDBC
>>>>>> - gen-kek
>>>>>> - gitinfo
>>>>>> - load-all-tenants
>>>>>> - load-demo-multitenant
>>>>>> - load-tenant
>>>>>> - load-tenant-data-readers
>>>>>> - refresh
>>>>>> - revert-dev
>>>>>> - run-test-list
>>>>>> - start-batch
>>>>>> - start-batch-secure
>>>>>> - start-both-secure
>>>>>> - start-pos-secure
>>>>>> - start-secure
>>>>>> - svninfo
>>>>>>
>>>>>> Second Question
>>>>>> -----------------------
>>>>>>
>>>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>>>> instead of load-extseed.
>>>>>>
>>>>>> If you would like to add the other load data tasks, please specify
>>>>>> which
>>>>>> ones.
>>>>>>
>>>>>> Appreciate your early responses.
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>
>>>>>>
>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Michael Jacques and everyone,
So I also want to confirm that you really need the following tasks:
- build-dev
- build-production
- build-qa
- build-test
- revert-dev
Are you using them yourselves? Here are the reasons why I suggest to remove
them:
- First, you must have the patch command existing in your environment, thus
making the build script brittle
- Second, it has this weird naming convention for patches and how they
should be applied. I would imagine that every team and every company has
its own style and methodology for patching and keeping track of files and
changes. They use their own version control system and even different kinds
of patches
- It is dependent on a specific format of diff which you must generate
either with svn diff or diff -Naur.
It seems like it does not make a lot of sense to keep something like that
when companies might completely ignore it and choose their own
implementation strategies. Do you agree? Feedback?
Taher Alkhateeb
On Wed, Jun 22, 2016 at 4:01 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> I wonder though why this was introduced. If we have no feedback from any
> member of the community I think we can drop it. I don't see how to use it.
>
> Jacques
>
>
>
> Le 22/06/2016 à 14:43, Michael Brohl a écrit :
>
>> Hi Taher,
>>
>> no, I don't use it myself. This was just a guess by looking what the task
>> does and it seemed to me this should be preserved.
>> No problem to drop it from my side.
>>
>> Regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>>
>>> Hi Michael,
>>>
>>> Are you sure you are using "run-test-list"? This is an old task using a
>>> target on the server called --testlist which essentially creates an ant
>>> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz
>>> in
>>> between each run.
>>>
>>> To me it seems like run-tests is doing the same thing but faster. Is
>>> this a
>>> typo by you or are you actually using this target? The reason I ask is
>>> because I actually wanted to delete the entire TestListContainer.java and
>>> related files in the future. But now of course I hesitate.
>>>
>>> Thanks in advance for your feedback.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <
>>> michael.brohl@ecomify.de>
>>> wrote:
>>>
>>> Hi Taher,
>>>>
>>>> First question:
>>>>
>>>> Don't drop:
>>>>
>>>> - build-dev
>>>> - build-production
>>>> - build-qa
>>>> - build-test
>>>> - refresh
>>>> - revert-dev
>>>> - run-test-list
>>>>
>>>> Drop:
>>>>
>>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>>> - copy-dtds
>>>> - download-PG-JDBC
>>>> - download-activemq
>>>> - download-mySQL-JDBC (download tasks: assuming they are not needed if
>>>> we
>>>> use Gradle/automatic dependency mechanism)
>>>>
>>>>
>>>> Not sure (I don't use them):
>>>>
>>>> - create-tenant
>>>> - load-all-tenants
>>>> - load-demo-multitenant
>>>> - load-tenant
>>>> - load-tenant-data-readers
>>>> - gen-kek
>>>> - gitinfo
>>>> - run-test-list
>>>> - start-batch-secure
>>>> - start-both-secure
>>>> - start-pos-secure
>>>> - start-secure (...secure: not sure if these are needed anymore, I think
>>>> Jacques can give some hints about them)
>>>> - svninfo
>>>>
>>>> Second question: +1
>>>>
>>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>>
>>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>>
>>>> Hi Everyone,
>>>>>
>>>>> I have create the JIRA
>>>>> https://issues.apache.org/jira/browse/OFBIZ-7534
>>>>> for
>>>>> this project
>>>>>
>>>>> I have two questions in this thread
>>>>>
>>>>> First Question
>>>>> ------------------
>>>>> Can I drop the below tasks from the build system? They currently exist
>>>>> in
>>>>> Ant but I am not sure whether they are actively used or not. So if you
>>>>> want
>>>>> me to add any of these tasks please reply to this thread, otherwise I
>>>>> will
>>>>> not include them in gradle. Please note I added all multi tenant tasks
>>>>> because many of them are broken or have no functionality, so I am
>>>>> assuming
>>>>> people are doing multi-tenancy manually but not sure, so please help!
>>>>>
>>>>> - build-dev
>>>>> - build-production
>>>>> - build-qa
>>>>> - build-test
>>>>> - clean-ivy
>>>>> - copy-dtds
>>>>> - create-tenant
>>>>> - download-PG-JDBC
>>>>> - download-activemq
>>>>> - download-mySQL-JDBC
>>>>> - gen-kek
>>>>> - gitinfo
>>>>> - load-all-tenants
>>>>> - load-demo-multitenant
>>>>> - load-tenant
>>>>> - load-tenant-data-readers
>>>>> - refresh
>>>>> - revert-dev
>>>>> - run-test-list
>>>>> - start-batch
>>>>> - start-batch-secure
>>>>> - start-both-secure
>>>>> - start-pos-secure
>>>>> - start-secure
>>>>> - svninfo
>>>>>
>>>>> Second Question
>>>>> -----------------------
>>>>>
>>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>>> instead of load-extseed.
>>>>>
>>>>> If you would like to add the other load data tasks, please specify
>>>>> which
>>>>> ones.
>>>>>
>>>>> Appreciate your early responses.
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
I wonder though why this was introduced. If we have no feedback from any member of the community I think we can drop it. I don't see how to use it.
Jacques
Le 22/06/2016 � 14:43, Michael Brohl a �crit :
> Hi Taher,
>
> no, I don't use it myself. This was just a guess by looking what the task does and it seemed to me this should be preserved.
> No problem to drop it from my side.
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
>> Hi Michael,
>>
>> Are you sure you are using "run-test-list"? This is an old task using a
>> target on the server called --testlist which essentially creates an ant
>> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz in
>> between each run.
>>
>> To me it seems like run-tests is doing the same thing but faster. Is this a
>> typo by you or are you actually using this target? The reason I ask is
>> because I actually wanted to delete the entire TestListContainer.java and
>> related files in the future. But now of course I hesitate.
>>
>> Thanks in advance for your feedback.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <mi...@ecomify.de>
>> wrote:
>>
>>> Hi Taher,
>>>
>>> First question:
>>>
>>> Don't drop:
>>>
>>> - build-dev
>>> - build-production
>>> - build-qa
>>> - build-test
>>> - refresh
>>> - revert-dev
>>> - run-test-list
>>>
>>> Drop:
>>>
>>> - clean-ivy (assuming this is not needed if we use Gradle)
>>> - copy-dtds
>>> - download-PG-JDBC
>>> - download-activemq
>>> - download-mySQL-JDBC (download tasks: assuming they are not needed if we
>>> use Gradle/automatic dependency mechanism)
>>>
>>>
>>> Not sure (I don't use them):
>>>
>>> - create-tenant
>>> - load-all-tenants
>>> - load-demo-multitenant
>>> - load-tenant
>>> - load-tenant-data-readers
>>> - gen-kek
>>> - gitinfo
>>> - run-test-list
>>> - start-batch-secure
>>> - start-both-secure
>>> - start-pos-secure
>>> - start-secure (...secure: not sure if these are needed anymore, I think
>>> Jacques can give some hints about them)
>>> - svninfo
>>>
>>> Second question: +1
>>>
>>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>>
>>>
>>> Regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>>
>>>> Hi Everyone,
>>>>
>>>> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534
>>>> for
>>>> this project
>>>>
>>>> I have two questions in this thread
>>>>
>>>> First Question
>>>> ------------------
>>>> Can I drop the below tasks from the build system? They currently exist in
>>>> Ant but I am not sure whether they are actively used or not. So if you
>>>> want
>>>> me to add any of these tasks please reply to this thread, otherwise I will
>>>> not include them in gradle. Please note I added all multi tenant tasks
>>>> because many of them are broken or have no functionality, so I am assuming
>>>> people are doing multi-tenancy manually but not sure, so please help!
>>>>
>>>> - build-dev
>>>> - build-production
>>>> - build-qa
>>>> - build-test
>>>> - clean-ivy
>>>> - copy-dtds
>>>> - create-tenant
>>>> - download-PG-JDBC
>>>> - download-activemq
>>>> - download-mySQL-JDBC
>>>> - gen-kek
>>>> - gitinfo
>>>> - load-all-tenants
>>>> - load-demo-multitenant
>>>> - load-tenant
>>>> - load-tenant-data-readers
>>>> - refresh
>>>> - revert-dev
>>>> - run-test-list
>>>> - start-batch
>>>> - start-batch-secure
>>>> - start-both-secure
>>>> - start-pos-secure
>>>> - start-secure
>>>> - svninfo
>>>>
>>>> Second Question
>>>> -----------------------
>>>>
>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>> implement loadDemo and the rest are executed manually by users, for
>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>> instead of load-extseed.
>>>>
>>>> If you would like to add the other load data tasks, please specify which
>>>> ones.
>>>>
>>>> Appreciate your early responses.
>>>>
>>>> Taher Alkhateeb
>>>>
>>>>
>>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Taher,
no, I don't use it myself. This was just a guess by looking what the
task does and it seemed to me this should be preserved.
No problem to drop it from my side.
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 22.06.16 um 14:37 schrieb Taher Alkhateeb:
> Hi Michael,
>
> Are you sure you are using "run-test-list"? This is an old task using a
> target on the server called --testlist which essentially creates an ant
> file of all the suites in OFBiz and runs them one-by-one stopping OFBiz in
> between each run.
>
> To me it seems like run-tests is doing the same thing but faster. Is this a
> typo by you or are you actually using this target? The reason I ask is
> because I actually wanted to delete the entire TestListContainer.java and
> related files in the future. But now of course I hesitate.
>
> Thanks in advance for your feedback.
>
> Regards,
>
> Taher Alkhateeb
>
> On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> Hi Taher,
>>
>> First question:
>>
>> Don't drop:
>>
>> - build-dev
>> - build-production
>> - build-qa
>> - build-test
>> - refresh
>> - revert-dev
>> - run-test-list
>>
>> Drop:
>>
>> - clean-ivy (assuming this is not needed if we use Gradle)
>> - copy-dtds
>> - download-PG-JDBC
>> - download-activemq
>> - download-mySQL-JDBC (download tasks: assuming they are not needed if we
>> use Gradle/automatic dependency mechanism)
>>
>>
>> Not sure (I don't use them):
>>
>> - create-tenant
>> - load-all-tenants
>> - load-demo-multitenant
>> - load-tenant
>> - load-tenant-data-readers
>> - gen-kek
>> - gitinfo
>> - run-test-list
>> - start-batch-secure
>> - start-both-secure
>> - start-pos-secure
>> - start-secure (...secure: not sure if these are needed anymore, I think
>> Jacques can give some hints about them)
>> - svninfo
>>
>> Second question: +1
>>
>> but I'm not sure about the load-tenant... tasks (I don't use them).
>>
>>
>> Regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>>
>>> Hi Everyone,
>>>
>>> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534
>>> for
>>> this project
>>>
>>> I have two questions in this thread
>>>
>>> First Question
>>> ------------------
>>> Can I drop the below tasks from the build system? They currently exist in
>>> Ant but I am not sure whether they are actively used or not. So if you
>>> want
>>> me to add any of these tasks please reply to this thread, otherwise I will
>>> not include them in gradle. Please note I added all multi tenant tasks
>>> because many of them are broken or have no functionality, so I am assuming
>>> people are doing multi-tenancy manually but not sure, so please help!
>>>
>>> - build-dev
>>> - build-production
>>> - build-qa
>>> - build-test
>>> - clean-ivy
>>> - copy-dtds
>>> - create-tenant
>>> - download-PG-JDBC
>>> - download-activemq
>>> - download-mySQL-JDBC
>>> - gen-kek
>>> - gitinfo
>>> - load-all-tenants
>>> - load-demo-multitenant
>>> - load-tenant
>>> - load-tenant-data-readers
>>> - refresh
>>> - revert-dev
>>> - run-test-list
>>> - start-batch
>>> - start-batch-secure
>>> - start-both-secure
>>> - start-pos-secure
>>> - start-secure
>>> - svninfo
>>>
>>> Second Question
>>> -----------------------
>>>
>>> it seems many of the load tasks are too specific. So I suggest to only
>>> implement loadDemo and the rest are executed manually by users, for
>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>> instead of load-extseed.
>>>
>>> If you would like to add the other load data tasks, please specify which
>>> ones.
>>>
>>> Appreciate your early responses.
>>>
>>> Taher Alkhateeb
>>>
>>>
>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Michael,
Are you sure you are using "run-test-list"? This is an old task using a
target on the server called --testlist which essentially creates an ant
file of all the suites in OFBiz and runs them one-by-one stopping OFBiz in
between each run.
To me it seems like run-tests is doing the same thing but faster. Is this a
typo by you or are you actually using this target? The reason I ask is
because I actually wanted to delete the entire TestListContainer.java and
related files in the future. But now of course I hesitate.
Thanks in advance for your feedback.
Regards,
Taher Alkhateeb
On Wed, Jun 22, 2016 at 12:00 AM, Michael Brohl <mi...@ecomify.de>
wrote:
> Hi Taher,
>
> First question:
>
> Don't drop:
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - refresh
> - revert-dev
> - run-test-list
>
> Drop:
>
> - clean-ivy (assuming this is not needed if we use Gradle)
> - copy-dtds
> - download-PG-JDBC
> - download-activemq
> - download-mySQL-JDBC (download tasks: assuming they are not needed if we
> use Gradle/automatic dependency mechanism)
>
>
> Not sure (I don't use them):
>
> - create-tenant
> - load-all-tenants
> - load-demo-multitenant
> - load-tenant
> - load-tenant-data-readers
> - gen-kek
> - gitinfo
> - run-test-list
> - start-batch-secure
> - start-both-secure
> - start-pos-secure
> - start-secure (...secure: not sure if these are needed anymore, I think
> Jacques can give some hints about them)
> - svninfo
>
> Second question: +1
>
> but I'm not sure about the load-tenant... tasks (I don't use them).
>
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>
>> Hi Everyone,
>>
>> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534
>> for
>> this project
>>
>> I have two questions in this thread
>>
>> First Question
>> ------------------
>> Can I drop the below tasks from the build system? They currently exist in
>> Ant but I am not sure whether they are actively used or not. So if you
>> want
>> me to add any of these tasks please reply to this thread, otherwise I will
>> not include them in gradle. Please note I added all multi tenant tasks
>> because many of them are broken or have no functionality, so I am assuming
>> people are doing multi-tenancy manually but not sure, so please help!
>>
>> - build-dev
>> - build-production
>> - build-qa
>> - build-test
>> - clean-ivy
>> - copy-dtds
>> - create-tenant
>> - download-PG-JDBC
>> - download-activemq
>> - download-mySQL-JDBC
>> - gen-kek
>> - gitinfo
>> - load-all-tenants
>> - load-demo-multitenant
>> - load-tenant
>> - load-tenant-data-readers
>> - refresh
>> - revert-dev
>> - run-test-list
>> - start-batch
>> - start-batch-secure
>> - start-both-secure
>> - start-pos-secure
>> - start-secure
>> - svninfo
>>
>> Second Question
>> -----------------------
>>
>> it seems many of the load tasks are too specific. So I suggest to only
>> implement loadDemo and the rest are executed manually by users, for
>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>> instead of load-extseed.
>>
>> If you would like to add the other load data tasks, please specify which
>> ones.
>>
>> Appreciate your early responses.
>>
>> Taher Alkhateeb
>>
>>
>
>
INFRA-12138 resolved [was Re: Important Changes to Trunk and Use of
Ant & Gradle]
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/06/2016 � 23:30, Jacques Le Roux a �crit :
> Unfortunately currently the link between Confluence and Jira is broken: https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12138
Just FYI *INFRA-12138* <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12138> is resolved
Jacques
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Tue, Jun 21, 2016 at 11:30 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> - gen-kek
>>
>
> Never used it, but Jacopo put it in recent
>
Actually, I didn't create it: it has been created long ago by Adam; but I
edited it to work with Shiro.
In my opinion it can be dropped and possibly re-implemented in a cleaner
way in the future if/when needed.
Jacopo
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Inline...
Le 21/06/2016 � 23:00, Michael Brohl a �crit :
> Hi Taher,
>
> First question:
>
> Don't drop:
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - refresh
> - revert-dev
> - run-test-list
>
>
> Drop:
>
> - clean-ivy (assuming this is not needed if we use Gradle)
> - copy-dtds
Nope, this one is useful to copy the updated XDSs from the trunk to the "website" (ie under http://ofbiz.apache.org/)
> - download-PG-JDBC
> - download-activemq
> - download-mySQL-JDBC (download tasks: assuming they are not needed if we use Gradle/automatic dependency mechanism)
>
>
> Not sure (I don't use them):
>
> - create-tenant
> - load-all-tenants
> - load-demo-multitenant
> - load-tenant
> - load-tenant-data-readers
Those are used in a multi-tenant context
> - gen-kek
Never used it, but Jacopo put it in recently
> - gitinfo
Used by external projects which use Git
> - run-test-list
I guess this will become redundant with Gradle
> - start-batch-secure
> - start-both-secure
> - start-pos-secure
> - start-secure (...secure: not sure if these are needed anymore, I think Jacques can give some hints about them)
This is needed as soon as you use RMI, JMX, Spring, or/and any external librairies within your OFBiz instance see
https://cwiki.apache.org/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability for details. Unfortunately currently the link between
Confluence and Jira is broken: https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12138
> - svninfo
It can be used by custom projects but is for sure used by the demos: it generates the information you read at the bottom on each page.
>
> Second question: +1
Same here: +1
> but I'm not sure about the load-tenant... tasks (I don't use them).
I guess at least Pierre will chime in...
Cheers
Jacques
>
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
>> Hi Everyone,
>>
>> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534 for
>> this project
>>
>> I have two questions in this thread
>>
>> First Question
>> ------------------
>> Can I drop the below tasks from the build system? They currently exist in
>> Ant but I am not sure whether they are actively used or not. So if you want
>> me to add any of these tasks please reply to this thread, otherwise I will
>> not include them in gradle. Please note I added all multi tenant tasks
>> because many of them are broken or have no functionality, so I am assuming
>> people are doing multi-tenancy manually but not sure, so please help!
>>
>> - build-dev
>> - build-production
>> - build-qa
>> - build-test
>> - clean-ivy
>> - copy-dtds
>> - create-tenant
>> - download-PG-JDBC
>> - download-activemq
>> - download-mySQL-JDBC
>> - gen-kek
>> - gitinfo
>> - load-all-tenants
>> - load-demo-multitenant
>> - load-tenant
>> - load-tenant-data-readers
>> - refresh
>> - revert-dev
>> - run-test-list
>> - start-batch
>> - start-batch-secure
>> - start-both-secure
>> - start-pos-secure
>> - start-secure
>> - svninfo
>>
>> Second Question
>> -----------------------
>>
>> it seems many of the load tasks are too specific. So I suggest to only
>> implement loadDemo and the rest are executed manually by users, for
>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>> instead of load-extseed.
>>
>> If you would like to add the other load data tasks, please specify which
>> ones.
>>
>> Appreciate your early responses.
>>
>> Taher Alkhateeb
>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Taher,
First question:
Don't drop:
- build-dev
- build-production
- build-qa
- build-test
- refresh
- revert-dev
- run-test-list
Drop:
- clean-ivy (assuming this is not needed if we use Gradle)
- copy-dtds
- download-PG-JDBC
- download-activemq
- download-mySQL-JDBC (download tasks: assuming they are not needed if we use Gradle/automatic dependency mechanism)
Not sure (I don't use them):
- create-tenant
- load-all-tenants
- load-demo-multitenant
- load-tenant
- load-tenant-data-readers
- gen-kek
- gitinfo
- run-test-list
- start-batch-secure
- start-both-secure
- start-pos-secure
- start-secure (...secure: not sure if these are needed anymore, I think Jacques can give some hints about them)
- svninfo
Second question: +1
but I'm not sure about the load-tenant... tasks (I don't use them).
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 21.06.16 um 22:09 schrieb Taher Alkhateeb:
> Hi Everyone,
>
> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534 for
> this project
>
> I have two questions in this thread
>
> First Question
> ------------------
> Can I drop the below tasks from the build system? They currently exist in
> Ant but I am not sure whether they are actively used or not. So if you want
> me to add any of these tasks please reply to this thread, otherwise I will
> not include them in gradle. Please note I added all multi tenant tasks
> because many of them are broken or have no functionality, so I am assuming
> people are doing multi-tenancy manually but not sure, so please help!
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - clean-ivy
> - copy-dtds
> - create-tenant
> - download-PG-JDBC
> - download-activemq
> - download-mySQL-JDBC
> - gen-kek
> - gitinfo
> - load-all-tenants
> - load-demo-multitenant
> - load-tenant
> - load-tenant-data-readers
> - refresh
> - revert-dev
> - run-test-list
> - start-batch
> - start-batch-secure
> - start-both-secure
> - start-pos-secure
> - start-secure
> - svninfo
>
> Second Question
> -----------------------
>
> it seems many of the load tasks are too specific. So I suggest to only
> implement loadDemo and the rest are executed manually by users, for
> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
> instead of load-extseed.
>
> If you would like to add the other load data tasks, please specify which
> ones.
>
> Appreciate your early responses.
>
> Taher Alkhateeb
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by gil portenseigne <gi...@nereide.fr>.
Hello Taher,
First question, from the given list I personally only use :
- download-PG-JDBC
to easily get through ivy the last postgresql driver
- start-batch
that can be avoided using shell tricks, so no problem
No opinions against others removal
For the load-task, if its easily documented with a feature like ant -p,
it's ok for me.
Regards
Gil
On 21/06/2016 22:09, Taher Alkhateeb wrote:
> Hi Everyone,
>
> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534 for
> this project
>
> I have two questions in this thread
>
> First Question
> ------------------
> Can I drop the below tasks from the build system? They currently exist in
> Ant but I am not sure whether they are actively used or not. So if you want
> me to add any of these tasks please reply to this thread, otherwise I will
> not include them in gradle. Please note I added all multi tenant tasks
> because many of them are broken or have no functionality, so I am assuming
> people are doing multi-tenancy manually but not sure, so please help!
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - clean-ivy
> - copy-dtds
> - create-tenant
> - download-PG-JDBC
> - download-activemq
> - download-mySQL-JDBC
> - gen-kek
> - gitinfo
> - load-all-tenants
> - load-demo-multitenant
> - load-tenant
> - load-tenant-data-readers
> - refresh
> - revert-dev
> - run-test-list
> - start-batch
> - start-batch-secure
> - start-both-secure
> - start-pos-secure
> - start-secure
> - svninfo
>
> Second Question
> -----------------------
>
> it seems many of the load tasks are too specific. So I suggest to only
> implement loadDemo and the rest are executed manually by users, for
> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
> instead of load-extseed.
>
> If you would like to add the other load data tasks, please specify which
> ones.
>
> Appreciate your early responses.
>
> Taher Alkhateeb
>
> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Everyone,
>>
>> Thank you all for your support and kinds words. This is truly a wonderful
>> atmosphere and I am lucky, honoured, and privileged to work with you all on
>> this project.
>>
>> My patch is almost done, but definitely there is a lot of work to be done
>> which includes the following:
>> - I have one failing test out of 889 that I need to dig through, maybe you
>> guy can help
>> - I want to change / delete / add some tasks
>> - Documentation needs to be updated in multiple areas
>> - Testing, testing, testing, testing, testing, testing, testing, testing,
>> testing
>>
>> So the plan of action is as follows:
>> - I will continue the discussion on this thread for a few questions that I
>> need an answer for.
>> - I will issue a JIRA to hold the patch and everything else
>>
>> Please consider helping, this is something that definitely needs a team,
>> more than one brain! If you are working on something not urgent, please
>> consider dropping it for a while and jump along for help.
>>
>> I will post another email soon with the JIRA details and list of questions
>> I need answer for.
>>
>> Again, thank you, you guys rock, I love OFBiz and this community!
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>>
>>
>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <ni...@nereide.fr>
>> wrote:
>>
>>> I'm in over for these technical aspects but the motivation and enthusiasm
>>> for many PMC and commiter tells me that seems a good way.
>>>
>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>> directly on trunk
>>>
>>> Thks Taher to your engine energy on this subject !
>>>
>>> Nicolas
>>>
>>>
>>>
>>> Le 21/06/2016 10:43, Jacques Le Roux a �crit :
>>>
>>>> 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 <deepak.dixit@hotwaxsystems.com
>>>>>> wrote:
>>>>>>
>>>>>> +1 for Gradle.
>>>>>>> Are we going to remove ant from framework completely or planning to
>>>>>>> keep
>>>>>>> both ant and gradle?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> --
>>>>>>> Deepak Dixit
>>>>>>> www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>> Hi Everyone
>>>>>>>> This is the second of two emails to inform the community about what
>>>>>>>> has
>>>>>>>> been happening around how we are planning to handle external
>>>>>>>> dependencies
>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>> the use
>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>> trying to
>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>
>>>>>>> difficult.
>>>>>>>
>>>>>>>> This was because our Ant scripts:
>>>>>>>>
>>>>>>>> - are massive and contain a lot of code
>>>>>>>> - are complex
>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>> - have no dependency management
>>>>>>>> - need everything to be declared
>>>>>>>>
>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>> limitations we
>>>>>>>> are facing are because of our build tool \u2013 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
>>>>>>>>
>>>>>>>>
>>>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pierre Smits <pi...@gmail.com>.
Inline
Op dinsdag 21 juni 2016 heeft Taher Alkhateeb <sl...@gmail.com>
het volgende geschreven:
> Hi Everyone,
>
> I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534
> for
> this project
>
> I have two questions in this thread
>
> First Question
> ------------------
> Can I drop the below tasks from the build system? They currently exist in
> Ant but I am not sure whether they are actively used or not. So if you want
> me to add any of these tasks please reply to this thread, otherwise I will
> not include them in gradle. Please note I added all multi tenant tasks
> because many of them are broken or have no functionality, so I am assuming
> people are doing multi-tenancy manually but not sure, so please help!
>
> - build-dev
> - build-production
> - build-qa
> - build-test
> - clean-ivy
> - copy-dtds
> - create-tenant
Don't drop, until replaced by gradlle equivalent. Used to setup a tenant
instanciation in a multi-tenant setup. This has dependencies that set the
tenant admin Id an password and execute the initial data load for the
tenant. For these dependencies the same 'don't drop, until.....' applies.
> - download-PG-JDBC
Don't drop, until replaced by gradlle equivalent. Used for PostgreSQL based
test and/or production environment
- download-activemq
Don't drop, until replaced by gradlle equivalent. Used for clustered test
and/or production environment
- download-mySQL-JDBC
Don't drop, until replaced by gradlle equivalent. Used for MySQL based
test and/or production environment
> - gen-kek
> - gitinfo
> - load-all-tenants
Drop. Used for multi tenant demo setup. Deprecated.
> - load-demo-multitenant
Drop. Used for multi tenant demo setup. Deprecated.
> - load-tenant
> - load-tenant-data-readers
> - refresh
> - revert-dev
> - run-test-list
> - start-batch
> - start-batch-secure
> - start-both-secure
> - start-pos-secure
> - start-secure
> - svninfo
>
> Second Question
> -----------------------
>
> it seems many of the load tasks are too specific. So I suggest to only
> implement loadDemo and the rest are executed manually by users, for
> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
> instead of load-extseed.
>
>
Then there is no need to maintain the load-demo variant, as it can be
executed like the other data loading mechanism. It is better not to confuse
potential adopters by serving them 2 variants that basically do the same,
but wit different data sets.
> If you would like to add the other load data tasks, please specify which
> ones.
>
> Appreciate your early responses.
>
> Taher Alkhateeb
>
> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com <javascript:;>
> > wrote:
>
> > Hi Everyone,
> >
> > Thank you all for your support and kinds words. This is truly a wonderful
> > atmosphere and I am lucky, honoured, and privileged to work with you all
> on
> > this project.
> >
> > My patch is almost done, but definitely there is a lot of work to be done
> > which includes the following:
> > - I have one failing test out of 889 that I need to dig through, maybe
> you
> > guy can help
> > - I want to change / delete / add some tasks
> > - Documentation needs to be updated in multiple areas
> > - Testing, testing, testing, testing, testing, testing, testing, testing,
> > testing
> >
> > So the plan of action is as follows:
> > - I will continue the discussion on this thread for a few questions that
> I
> > need an answer for.
> > - I will issue a JIRA to hold the patch and everything else
> >
> > Please consider helping, this is something that definitely needs a team,
> > more than one brain! If you are working on something not urgent, please
> > consider dropping it for a while and jump along for help.
> >
> > I will post another email soon with the JIRA details and list of
> questions
> > I need answer for.
> >
> > Again, thank you, you guys rock, I love OFBiz and this community!
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> >
> >
> > On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <
> nicolas.malin@nereide.fr <javascript:;>>
> > wrote:
> >
> >> I'm in over for these technical aspects but the motivation and
> enthusiasm
> >> for many PMC and commiter tells me that seems a good way.
> >>
> >> So now I will learn gradle ;) and I'm in favor to realize this change
> >> directly on trunk
> >>
> >> Thks Taher to your engine energy on this subject !
> >>
> >> Nicolas
> >>
> >>
> >>
> >> Le 21/06/2016 10:43, Jacques Le Roux a écrit :
> >>
> >>> 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 <
> deepak.dixit@hotwaxsystems.com <javascript:;>
> >>>>> >
> >>>>> wrote:
> >>>>>
> >>>>> +1 for Gradle.
> >>>>>>
> >>>>>> Are we going to remove ant from framework completely or planning to
> >>>>>> keep
> >>>>>> both ant and gradle?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thanks & Regards
> >>>>>> --
> >>>>>> Deepak Dixit
> >>>>>> www.hotwaxsystems.com
> >>>>>>
> >>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
> <javascript:;>
> >>>>>> <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/
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Taher,
Right, it was not a problem of space but licence. With the Gradle solution we no longer have licence issues with external jars, another good point to
this solution :)
Jacques
Le 22/06/2016 � 10:46, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> How about we actually download all JDBC drivers automatically regardless of
> the selected database. Their size is very small and it is worth making the
> build script smaller no? And also anyway some people use different versions
> of the database and have to change the driver version, in this case it
> would be a much cleaner solution for them to go to the build script and
> change the version (simple string) than to actually download the jar file
> or modify the logic for the download tasks.
>
> With that being said, thank you all for your input, I will draft the first
> patch based on your feedback very soon. I will try to consolidate your
> opinions as much as possible but may differ. So please take it lightly as
> everything can be changed upon your request, I'm just trying to balance all
> opinions and come up with something nice and clean.
>
> Again, I really appreciate the support! I will update you soon.
>
> On Wed, Jun 22, 2016 at 11:38 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Le 22/06/2016 � 10:05, Julien NICOLAS a �crit :
>>
>>>
>>> On 22/06/2016 09:53, Julien NICOLAS wrote:
>>>
>>>>
>>>> On 21/06/2016 22:09, Taher Alkhateeb wrote:
>>>>
>>>>> - download-PG-JDBC
>>>>>
>>>> If it's possible, keep this one :)
>>>>
>>> Ok, I don't see the information of Michael that with Graddle, we don't
>>> need a task for that because of the Graddle dependency functionality. So my
>>> mistake, forgot it :)
>>>
>> I think you are right about this one and I believe we should keep all Ant
>> JDBC driver download targets. Except if Gradle is able to infer that it
>> would be possible in certain circumstances an user could need one of those
>> drivers.
>> This would need to parse entityengine.xml and I highly doubt this can be
>> done w/o some human intervention. On the other hand if similar Gradle
>> tasks are introduced, then of course I'd not see any reasons to not drop
>> them. Same for all Ant targets actually.
>>
>> Hope I'm clear enough :)
>>
>> Jacques
>>
>>
>>>>> Second Question
>>>>> -----------------------
>>>>>
>>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>>> implement loadDemo and the rest are executed manually by users, for
>>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>>> instead of load-extseed.
>>>>>
>>>> I think load-seed is important as well, so if you can keep the load-seed
>>>> task, it could be fine.
>>>>
>>>> Thanks!
>>>>
>>>> Julien.
>>>>
>>>>> If you would like to add the other load data tasks, please specify which
>>>>> ones.
>>>>>
>>>>> Appreciate your early responses.
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <
>>>>> slidingfilaments@gmail.com
>>>>>
>>>>>> wrote:
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Thank you all for your support and kinds words. This is truly a
>>>>>> wonderful
>>>>>> atmosphere and I am lucky, honoured, and privileged to work with you
>>>>>> all on
>>>>>> this project.
>>>>>>
>>>>>> My patch is almost done, but definitely there is a lot of work to be
>>>>>> done
>>>>>> which includes the following:
>>>>>> - I have one failing test out of 889 that I need to dig through, maybe
>>>>>> you
>>>>>> guy can help
>>>>>> - I want to change / delete / add some tasks
>>>>>> - Documentation needs to be updated in multiple areas
>>>>>> - Testing, testing, testing, testing, testing, testing, testing,
>>>>>> testing,
>>>>>> testing
>>>>>>
>>>>>> So the plan of action is as follows:
>>>>>> - I will continue the discussion on this thread for a few questions
>>>>>> that I
>>>>>> need an answer for.
>>>>>> - I will issue a JIRA to hold the patch and everything else
>>>>>>
>>>>>> Please consider helping, this is something that definitely needs a
>>>>>> team,
>>>>>> more than one brain! If you are working on something not urgent, please
>>>>>> consider dropping it for a while and jump along for help.
>>>>>>
>>>>>> I will post another email soon with the JIRA details and list of
>>>>>> questions
>>>>>> I need answer for.
>>>>>>
>>>>>> Again, thank you, you guys rock, I love OFBiz and this community!
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <
>>>>>> nicolas.malin@nereide.fr>
>>>>>> wrote:
>>>>>>
>>>>>> I'm in over for these technical aspects but the motivation and
>>>>>>> enthusiasm
>>>>>>> for many PMC and commiter tells me that seems a good way.
>>>>>>>
>>>>>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>>>>>> directly on trunk
>>>>>>>
>>>>>>> Thks Taher to your engine energy on this subject !
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 21/06/2016 10:43, Jacques Le Roux a �crit :
>>>>>>>
>>>>>>> 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 <
>>>>>>>>>> deepak.dixit@hotwaxsystems.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> +1 for Gradle.
>>>>>>>>>>
>>>>>>>>>>> Are we going to remove ant from framework completely or planning
>>>>>>>>>>> to
>>>>>>>>>>> keep
>>>>>>>>>>> both ant and gradle?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>> --
>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <
>>>>>>>>>>> sharan.foga@gmail.com
>>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Everyone
>>>>>>>>>>>
>>>>>>>>>>>> This is the second of two emails to inform the community about
>>>>>>>>>>>> what
>>>>>>>>>>>> has
>>>>>>>>>>>> been happening around how we are planning to handle external
>>>>>>>>>>>> dependencies
>>>>>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>>>>>> the use
>>>>>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>>>>>> trying to
>>>>>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>>>>>
>>>>>>>>>>>> difficult.
>>>>>>>>>>> This was because our Ant scripts:
>>>>>>>>>>>> - are massive and contain a lot of code
>>>>>>>>>>>> - are complex
>>>>>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>>>>>> - have no dependency management
>>>>>>>>>>>> - need everything to be declared
>>>>>>>>>>>>
>>>>>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>>>>>> limitations we
>>>>>>>>>>>> are facing are because of our build tool \u2013 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
How about we actually download all JDBC drivers automatically regardless of
the selected database. Their size is very small and it is worth making the
build script smaller no? And also anyway some people use different versions
of the database and have to change the driver version, in this case it
would be a much cleaner solution for them to go to the build script and
change the version (simple string) than to actually download the jar file
or modify the logic for the download tasks.
With that being said, thank you all for your input, I will draft the first
patch based on your feedback very soon. I will try to consolidate your
opinions as much as possible but may differ. So please take it lightly as
everything can be changed upon your request, I'm just trying to balance all
opinions and come up with something nice and clean.
Again, I really appreciate the support! I will update you soon.
On Wed, Jun 22, 2016 at 11:38 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Le 22/06/2016 à 10:05, Julien NICOLAS a écrit :
>
>>
>>
>> On 22/06/2016 09:53, Julien NICOLAS wrote:
>>
>>>
>>>
>>> On 21/06/2016 22:09, Taher Alkhateeb wrote:
>>>
>>>> - download-PG-JDBC
>>>>
>>> If it's possible, keep this one :)
>>>
>> Ok, I don't see the information of Michael that with Graddle, we don't
>> need a task for that because of the Graddle dependency functionality. So my
>> mistake, forgot it :)
>>
>
> I think you are right about this one and I believe we should keep all Ant
> JDBC driver download targets. Except if Gradle is able to infer that it
> would be possible in certain circumstances an user could need one of those
> drivers.
> This would need to parse entityengine.xml and I highly doubt this can be
> done w/o some human intervention. On the other hand if similar Gradle
> tasks are introduced, then of course I'd not see any reasons to not drop
> them. Same for all Ant targets actually.
>
> Hope I'm clear enough :)
>
> Jacques
>
>
>>>> Second Question
>>>> -----------------------
>>>>
>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>> implement loadDemo and the rest are executed manually by users, for
>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>> instead of load-extseed.
>>>>
>>> I think load-seed is important as well, so if you can keep the load-seed
>>> task, it could be fine.
>>>
>>> Thanks!
>>>
>>> Julien.
>>>
>>>>
>>>> If you would like to add the other load data tasks, please specify which
>>>> ones.
>>>>
>>>> Appreciate your early responses.
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Thank you all for your support and kinds words. This is truly a
>>>>> wonderful
>>>>> atmosphere and I am lucky, honoured, and privileged to work with you
>>>>> all on
>>>>> this project.
>>>>>
>>>>> My patch is almost done, but definitely there is a lot of work to be
>>>>> done
>>>>> which includes the following:
>>>>> - I have one failing test out of 889 that I need to dig through, maybe
>>>>> you
>>>>> guy can help
>>>>> - I want to change / delete / add some tasks
>>>>> - Documentation needs to be updated in multiple areas
>>>>> - Testing, testing, testing, testing, testing, testing, testing,
>>>>> testing,
>>>>> testing
>>>>>
>>>>> So the plan of action is as follows:
>>>>> - I will continue the discussion on this thread for a few questions
>>>>> that I
>>>>> need an answer for.
>>>>> - I will issue a JIRA to hold the patch and everything else
>>>>>
>>>>> Please consider helping, this is something that definitely needs a
>>>>> team,
>>>>> more than one brain! If you are working on something not urgent, please
>>>>> consider dropping it for a while and jump along for help.
>>>>>
>>>>> I will post another email soon with the JIRA details and list of
>>>>> questions
>>>>> I need answer for.
>>>>>
>>>>> Again, thank you, you guys rock, I love OFBiz and this community!
>>>>>
>>>>> Regards,
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <
>>>>> nicolas.malin@nereide.fr>
>>>>> wrote:
>>>>>
>>>>> I'm in over for these technical aspects but the motivation and
>>>>>> enthusiasm
>>>>>> for many PMC and commiter tells me that seems a good way.
>>>>>>
>>>>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>>>>> directly on trunk
>>>>>>
>>>>>> Thks Taher to your engine energy on this subject !
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 21/06/2016 10:43, Jacques Le Roux a écrit :
>>>>>>
>>>>>> 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 <
>>>>>>>>> deepak.dixit@hotwaxsystems.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1 for Gradle.
>>>>>>>>>
>>>>>>>>>> Are we going to remove ant from framework completely or planning
>>>>>>>>>> to
>>>>>>>>>> keep
>>>>>>>>>> both ant and gradle?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <
>>>>>>>>>> sharan.foga@gmail.com
>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Everyone
>>>>>>>>>>
>>>>>>>>>>> This is the second of two emails to inform the community about
>>>>>>>>>>> what
>>>>>>>>>>> has
>>>>>>>>>>> been happening around how we are planning to handle external
>>>>>>>>>>> dependencies
>>>>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>>>>> the use
>>>>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>>>>> trying to
>>>>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>>>>
>>>>>>>>>>> difficult.
>>>>>>>>>>
>>>>>>>>>> This was because our Ant scripts:
>>>>>>>>>>>
>>>>>>>>>>> - are massive and contain a lot of code
>>>>>>>>>>> - are complex
>>>>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>>>>> - have no dependency management
>>>>>>>>>>> - need everything to be declared
>>>>>>>>>>>
>>>>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>>>>> limitations we
>>>>>>>>>>> are facing are because of our build tool – Ant.
>>>>>>>>>>>
>>>>>>>>>>> Ant is verbose so it needs everything to be declared. We did a
>>>>>>>>>>> brief
>>>>>>>>>>> assessment of Maven and found it better than Ant but not a good
>>>>>>>>>>> fit
>>>>>>>>>>> for
>>>>>>>>>>> OFBiz because it has strict requirements for the
>>>>>>>>>>> convention-over-configuration rules to work. Instead we decided
>>>>>>>>>>> to
>>>>>>>>>>> take a
>>>>>>>>>>> closer look at Gradle.
>>>>>>>>>>>
>>>>>>>>>>> So why Gradle?
>>>>>>>>>>> As Taher was already looking at Gradle for unit testing, we
>>>>>>>>>>> decided
>>>>>>>>>>> to
>>>>>>>>>>> look at what we would need to do to totally replace Ant with
>>>>>>>>>>> Gradle.
>>>>>>>>>>> We
>>>>>>>>>>> received some great support and feedback from David, who is
>>>>>>>>>>> already
>>>>>>>>>>> using
>>>>>>>>>>> Gradle with Moqui.
>>>>>>>>>>>
>>>>>>>>>>> After some preliminary tests we found that Gradle has some very
>>>>>>>>>>> good
>>>>>>>>>>> features such as:
>>>>>>>>>>>
>>>>>>>>>>> - a much shorter code base (e.g. one single file of around
>>>>>>>>>>> 250
>>>>>>>>>>> lines
>>>>>>>>>>>
>>>>>>>>>>> of
>>>>>>>>>>
>>>>>>>>>> code replaces all the build.xml files and thousands of lines of
>>>>>>>>>>> code)
>>>>>>>>>>> - Programming is DSL based and links in well with Groovy
>>>>>>>>>>> (e.g.
>>>>>>>>>>> the
>>>>>>>>>>> script is short because despite heavy custom requirements for
>>>>>>>>>>> OFBiz,
>>>>>>>>>>> two
>>>>>>>>>>> small functions took care of the complex directory structure)
>>>>>>>>>>> - It handles all the external jar files by downloading any
>>>>>>>>>>>
>>>>>>>>>>> dependencies
>>>>>>>>>>
>>>>>>>>>> directly via internet
>>>>>>>>>>> - Jars can be upgraded by simply changing a string
>>>>>>>>>>> - It has matured a lot and has a high level of support in
>>>>>>>>>>> tools,IDEs,
>>>>>>>>>>> books, documentation
>>>>>>>>>>> - It also has a lot of plugins which means that it works
>>>>>>>>>>> with
>>>>>>>>>>> pretty
>>>>>>>>>>> much all build systems, supports multiple programming languages,
>>>>>>>>>>> and
>>>>>>>>>>> many
>>>>>>>>>>> other features (e.g. OSGi)
>>>>>>>>>>>
>>>>>>>>>>> We understand that it can help us make OFBiz more modular and
>>>>>>>>>>> also
>>>>>>>>>>>
>>>>>>>>>>> setting
>>>>>>>>>>
>>>>>>>>>> up a framework for managing addons would be a lot easier.
>>>>>>>>>>>
>>>>>>>>>>> So what's been done?
>>>>>>>>>>> Taher has been working very hard on a patch for the trunk that
>>>>>>>>>>> completely
>>>>>>>>>>> replaces Ant with Gradle. (Huge thanks to David for providing
>>>>>>>>>>> some
>>>>>>>>>>>
>>>>>>>>>>> example
>>>>>>>>>>
>>>>>>>>>> scripts to help us get started!) The patch is now ready to be
>>>>>>>>>>> applied to
>>>>>>>>>>> the trunk and includes the following:
>>>>>>>>>>>
>>>>>>>>>>> - java -jar ofbiz.jar is now replaced with -> gradlew
>>>>>>>>>>> 'ofbiz
>>>>>>>>>>> --whatever-options-here'
>>>>>>>>>>> - In addition to gradlew 'ofbiz' we also have gradlew
>>>>>>>>>>> 'ofbizDebug
>>>>>>>>>>> --whatever'. What does that mean? It means we can run debug on
>>>>>>>>>>> ALL
>>>>>>>>>>> ofbiz
>>>>>>>>>>> commands, not just start
>>>>>>>>>>> - If we decide to change the source directory structure in
>>>>>>>>>>> components
>>>>>>>>>>> say from /src to /src/main, it would literally be a change of 5
>>>>>>>>>>>
>>>>>>>>>>> characters
>>>>>>>>>>
>>>>>>>>>> in the build script
>>>>>>>>>>> - We can immediately move all jar files if we want to a
>>>>>>>>>>> unified
>>>>>>>>>>> location in /lib for example
>>>>>>>>>>> - We can delete most of the jars and declare them as
>>>>>>>>>>> dependencies
>>>>>>>>>>> saving space and resources
>>>>>>>>>>> - We can automate the creation of the .classpath file so
>>>>>>>>>>> when we
>>>>>>>>>>> update libraries no need to do this manually (under development)
>>>>>>>>>>> - We can ignore components that are not define in the xml
>>>>>>>>>>> files
>>>>>>>>>>> for
>>>>>>>>>>> loading (under development)
>>>>>>>>>>> - We can introduce unit tests with about 10 minutes of work
>>>>>>>>>>>
>>>>>>>>>>> We are finding that the flexibility and control we are getting
>>>>>>>>>>> with
>>>>>>>>>>>
>>>>>>>>>>> Gradle
>>>>>>>>>>
>>>>>>>>>> is truly amazing. We know that Gradle will be a major change to
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>> project
>>>>>>>>>>
>>>>>>>>>> but we think that it will significantly improve the project by
>>>>>>>>>>> removing a
>>>>>>>>>>> lot of build complexity and take care of that essential
>>>>>>>>>>> dependency
>>>>>>>>>>> management that we need to comply with.
>>>>>>>>>>>
>>>>>>>>>>> Our next steps will be to apply the patch to the trunk and then
>>>>>>>>>>> continue
>>>>>>>>>>> the re-factoring work. We will need to organise some knowledge
>>>>>>>>>>> transfer
>>>>>>>>>>>
>>>>>>>>>>> so
>>>>>>>>>>
>>>>>>>>>> that all our committers understand what the changes are and how
>>>>>>>>>>> they
>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>>
>>>>>>>>>> need to work in the future.
>>>>>>>>>>>
>>>>>>>>>>> The PMC are very, very excited about having Gradle as part of
>>>>>>>>>>> future
>>>>>>>>>>> of
>>>>>>>>>>> OFBiz and we hope that the community will think so too. As
>>>>>>>>>>> always,
>>>>>>>>>>>
>>>>>>>>>>> feedback
>>>>>>>>>>
>>>>>>>>>> welcome.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Sharan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>
>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 22/06/2016 � 10:05, Julien NICOLAS a �crit :
>
>
> On 22/06/2016 09:53, Julien NICOLAS wrote:
>>
>>
>> On 21/06/2016 22:09, Taher Alkhateeb wrote:
>>> - download-PG-JDBC
>> If it's possible, keep this one :)
> Ok, I don't see the information of Michael that with Graddle, we don't need a task for that because of the Graddle dependency functionality. So my
> mistake, forgot it :)
I think you are right about this one and I believe we should keep all Ant JDBC driver download targets. Except if Gradle is able to infer that it
would be possible in certain circumstances an user could need one of those drivers.
This would need to parse entityengine.xml and I highly doubt this can be done w/o some human intervention. On the other hand if similar Gradle tasks
are introduced, then of course I'd not see any reasons to not drop them. Same for all Ant targets actually.
Hope I'm clear enough :)
Jacques
>>>
>>> Second Question
>>> -----------------------
>>>
>>> it seems many of the load tasks are too specific. So I suggest to only
>>> implement loadDemo and the rest are executed manually by users, for
>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>> instead of load-extseed.
>> I think load-seed is important as well, so if you can keep the load-seed task, it could be fine.
>>
>> Thanks!
>>
>> Julien.
>>>
>>> If you would like to add the other load data tasks, please specify which
>>> ones.
>>>
>>> Appreciate your early responses.
>>>
>>> Taher Alkhateeb
>>>
>>> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>>> wrote:
>>>> Hi Everyone,
>>>>
>>>> Thank you all for your support and kinds words. This is truly a wonderful
>>>> atmosphere and I am lucky, honoured, and privileged to work with you all on
>>>> this project.
>>>>
>>>> My patch is almost done, but definitely there is a lot of work to be done
>>>> which includes the following:
>>>> - I have one failing test out of 889 that I need to dig through, maybe you
>>>> guy can help
>>>> - I want to change / delete / add some tasks
>>>> - Documentation needs to be updated in multiple areas
>>>> - Testing, testing, testing, testing, testing, testing, testing, testing,
>>>> testing
>>>>
>>>> So the plan of action is as follows:
>>>> - I will continue the discussion on this thread for a few questions that I
>>>> need an answer for.
>>>> - I will issue a JIRA to hold the patch and everything else
>>>>
>>>> Please consider helping, this is something that definitely needs a team,
>>>> more than one brain! If you are working on something not urgent, please
>>>> consider dropping it for a while and jump along for help.
>>>>
>>>> I will post another email soon with the JIRA details and list of questions
>>>> I need answer for.
>>>>
>>>> Again, thank you, you guys rock, I love OFBiz and this community!
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>>
>>>>
>>>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <ni...@nereide.fr>
>>>> wrote:
>>>>
>>>>> I'm in over for these technical aspects but the motivation and enthusiasm
>>>>> for many PMC and commiter tells me that seems a good way.
>>>>>
>>>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>>>> directly on trunk
>>>>>
>>>>> Thks Taher to your engine energy on this subject !
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>>
>>>>> Le 21/06/2016 10:43, Jacques Le Roux a �crit :
>>>>>
>>>>>> 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 <deepak.dixit@hotwaxsystems.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> +1 for Gradle.
>>>>>>>>> Are we going to remove ant from framework completely or planning to
>>>>>>>>> keep
>>>>>>>>> both ant and gradle?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Everyone
>>>>>>>>>> This is the second of two emails to inform the community about what
>>>>>>>>>> has
>>>>>>>>>> been happening around how we are planning to handle external
>>>>>>>>>> dependencies
>>>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>>>> the use
>>>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>>>> trying to
>>>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>>>
>>>>>>>>> difficult.
>>>>>>>>>
>>>>>>>>>> This was because our Ant scripts:
>>>>>>>>>>
>>>>>>>>>> - are massive and contain a lot of code
>>>>>>>>>> - are complex
>>>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>>>> - have no dependency management
>>>>>>>>>> - need everything to be declared
>>>>>>>>>>
>>>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>>>> limitations we
>>>>>>>>>> are facing are because of our build tool \u2013 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Julien NICOLAS <ju...@nereide.fr>.
On 22/06/2016 09:53, Julien NICOLAS wrote:
>
>
> On 21/06/2016 22:09, Taher Alkhateeb wrote:
>> - download-PG-JDBC
> If it's possible, keep this one :)
Ok, I don't see the information of Michael that with Graddle, we don't
need a task for that because of the Graddle dependency functionality. So
my mistake, forgot it :)
>>
>> Second Question
>> -----------------------
>>
>> it seems many of the load tasks are too specific. So I suggest to only
>> implement loadDemo and the rest are executed manually by users, for
>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>> instead of load-extseed.
> I think load-seed is important as well, so if you can keep the
> load-seed task, it could be fine.
>
> Thanks!
>
> Julien.
>>
>> If you would like to add the other load data tasks, please specify which
>> ones.
>>
>> Appreciate your early responses.
>>
>> Taher Alkhateeb
>>
>> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb
>> <slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> Thank you all for your support and kinds words. This is truly a
>>> wonderful
>>> atmosphere and I am lucky, honoured, and privileged to work with you
>>> all on
>>> this project.
>>>
>>> My patch is almost done, but definitely there is a lot of work to be
>>> done
>>> which includes the following:
>>> - I have one failing test out of 889 that I need to dig through,
>>> maybe you
>>> guy can help
>>> - I want to change / delete / add some tasks
>>> - Documentation needs to be updated in multiple areas
>>> - Testing, testing, testing, testing, testing, testing, testing,
>>> testing,
>>> testing
>>>
>>> So the plan of action is as follows:
>>> - I will continue the discussion on this thread for a few questions
>>> that I
>>> need an answer for.
>>> - I will issue a JIRA to hold the patch and everything else
>>>
>>> Please consider helping, this is something that definitely needs a
>>> team,
>>> more than one brain! If you are working on something not urgent, please
>>> consider dropping it for a while and jump along for help.
>>>
>>> I will post another email soon with the JIRA details and list of
>>> questions
>>> I need answer for.
>>>
>>> Again, thank you, you guys rock, I love OFBiz and this community!
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>>
>>>
>>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin
>>> <ni...@nereide.fr>
>>> wrote:
>>>
>>>> I'm in over for these technical aspects but the motivation and
>>>> enthusiasm
>>>> for many PMC and commiter tells me that seems a good way.
>>>>
>>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>>> directly on trunk
>>>>
>>>> Thks Taher to your engine energy on this subject !
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>> Le 21/06/2016 10:43, Jacques Le Roux a �crit :
>>>>
>>>>> 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
>>>>>>> <deepak.dixit@hotwaxsystems.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> +1 for Gradle.
>>>>>>>> Are we going to remove ant from framework completely or
>>>>>>>> planning to
>>>>>>>> keep
>>>>>>>> both ant and gradle?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks & Regards
>>>>>>>> --
>>>>>>>> Deepak Dixit
>>>>>>>> www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga
>>>>>>>> <sharan.foga@gmail.com
>>>>>>>> <javascript:;>> wrote:
>>>>>>>>
>>>>>>>> Hi Everyone
>>>>>>>>> This is the second of two emails to inform the community about
>>>>>>>>> what
>>>>>>>>> has
>>>>>>>>> been happening around how we are planning to handle external
>>>>>>>>> dependencies
>>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>>> the use
>>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>>> trying to
>>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>>
>>>>>>>> difficult.
>>>>>>>>
>>>>>>>>> This was because our Ant scripts:
>>>>>>>>>
>>>>>>>>> - are massive and contain a lot of code
>>>>>>>>> - are complex
>>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>>> - have no dependency management
>>>>>>>>> - need everything to be declared
>>>>>>>>>
>>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>>> limitations we
>>>>>>>>> are facing are because of our build tool \u2013 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
>>>>>>>>>
>>>>>>>>>
>>>>>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Julien NICOLAS <ju...@nereide.fr>.
On 21/06/2016 22:09, Taher Alkhateeb wrote:
> - download-PG-JDBC
If it's possible, keep this one :)
>
> Second Question
> -----------------------
>
> it seems many of the load tasks are too specific. So I suggest to only
> implement loadDemo and the rest are executed manually by users, for
> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
> instead of load-extseed.
I think load-seed is important as well, so if you can keep the load-seed
task, it could be fine.
Thanks!
Julien.
>
> If you would like to add the other load data tasks, please specify which
> ones.
>
> Appreciate your early responses.
>
> Taher Alkhateeb
>
> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Everyone,
>>
>> Thank you all for your support and kinds words. This is truly a wonderful
>> atmosphere and I am lucky, honoured, and privileged to work with you all on
>> this project.
>>
>> My patch is almost done, but definitely there is a lot of work to be done
>> which includes the following:
>> - I have one failing test out of 889 that I need to dig through, maybe you
>> guy can help
>> - I want to change / delete / add some tasks
>> - Documentation needs to be updated in multiple areas
>> - Testing, testing, testing, testing, testing, testing, testing, testing,
>> testing
>>
>> So the plan of action is as follows:
>> - I will continue the discussion on this thread for a few questions that I
>> need an answer for.
>> - I will issue a JIRA to hold the patch and everything else
>>
>> Please consider helping, this is something that definitely needs a team,
>> more than one brain! If you are working on something not urgent, please
>> consider dropping it for a while and jump along for help.
>>
>> I will post another email soon with the JIRA details and list of questions
>> I need answer for.
>>
>> Again, thank you, you guys rock, I love OFBiz and this community!
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>>
>>
>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <ni...@nereide.fr>
>> wrote:
>>
>>> I'm in over for these technical aspects but the motivation and enthusiasm
>>> for many PMC and commiter tells me that seems a good way.
>>>
>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>> directly on trunk
>>>
>>> Thks Taher to your engine energy on this subject !
>>>
>>> Nicolas
>>>
>>>
>>>
>>> Le 21/06/2016 10:43, Jacques Le Roux a �crit :
>>>
>>>> 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 <deepak.dixit@hotwaxsystems.com
>>>>>> wrote:
>>>>>>
>>>>>> +1 for Gradle.
>>>>>>> Are we going to remove ant from framework completely or planning to
>>>>>>> keep
>>>>>>> both ant and gradle?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> --
>>>>>>> Deepak Dixit
>>>>>>> www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>> Hi Everyone
>>>>>>>> This is the second of two emails to inform the community about what
>>>>>>>> has
>>>>>>>> been happening around how we are planning to handle external
>>>>>>>> dependencies
>>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>>> the use
>>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>>> trying to
>>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>>
>>>>>>> difficult.
>>>>>>>
>>>>>>>> This was because our Ant scripts:
>>>>>>>>
>>>>>>>> - are massive and contain a lot of code
>>>>>>>> - are complex
>>>>>>>> - are very brittle and make it very hard to change things
>>>>>>>> - have no dependency management
>>>>>>>> - need everything to be declared
>>>>>>>>
>>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>>> limitations we
>>>>>>>> are facing are because of our build tool \u2013 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
>>>>>>>>
>>>>>>>>
>>>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Everyone,
I have create the JIRA https://issues.apache.org/jira/browse/OFBIZ-7534 for
this project
I have two questions in this thread
First Question
------------------
Can I drop the below tasks from the build system? They currently exist in
Ant but I am not sure whether they are actively used or not. So if you want
me to add any of these tasks please reply to this thread, otherwise I will
not include them in gradle. Please note I added all multi tenant tasks
because many of them are broken or have no functionality, so I am assuming
people are doing multi-tenancy manually but not sure, so please help!
- build-dev
- build-production
- build-qa
- build-test
- clean-ivy
- copy-dtds
- create-tenant
- download-PG-JDBC
- download-activemq
- download-mySQL-JDBC
- gen-kek
- gitinfo
- load-all-tenants
- load-demo-multitenant
- load-tenant
- load-tenant-data-readers
- refresh
- revert-dev
- run-test-list
- start-batch
- start-batch-secure
- start-both-secure
- start-pos-secure
- start-secure
- svninfo
Second Question
-----------------------
it seems many of the load tasks are too specific. So I suggest to only
implement loadDemo and the rest are executed manually by users, for
example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
instead of load-extseed.
If you would like to add the other load data tasks, please specify which
ones.
Appreciate your early responses.
Taher Alkhateeb
On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Everyone,
>
> Thank you all for your support and kinds words. This is truly a wonderful
> atmosphere and I am lucky, honoured, and privileged to work with you all on
> this project.
>
> My patch is almost done, but definitely there is a lot of work to be done
> which includes the following:
> - I have one failing test out of 889 that I need to dig through, maybe you
> guy can help
> - I want to change / delete / add some tasks
> - Documentation needs to be updated in multiple areas
> - Testing, testing, testing, testing, testing, testing, testing, testing,
> testing
>
> So the plan of action is as follows:
> - I will continue the discussion on this thread for a few questions that I
> need an answer for.
> - I will issue a JIRA to hold the patch and everything else
>
> Please consider helping, this is something that definitely needs a team,
> more than one brain! If you are working on something not urgent, please
> consider dropping it for a while and jump along for help.
>
> I will post another email soon with the JIRA details and list of questions
> I need answer for.
>
> Again, thank you, you guys rock, I love OFBiz and this community!
>
> Regards,
>
> Taher Alkhateeb
>
>
>
> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <ni...@nereide.fr>
> wrote:
>
>> I'm in over for these technical aspects but the motivation and enthusiasm
>> for many PMC and commiter tells me that seems a good way.
>>
>> So now I will learn gradle ;) and I'm in favor to realize this change
>> directly on trunk
>>
>> Thks Taher to your engine energy on this subject !
>>
>> Nicolas
>>
>>
>>
>> Le 21/06/2016 10:43, Jacques Le Roux a écrit :
>>
>>> 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 <deepak.dixit@hotwaxsystems.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>> +1 for Gradle.
>>>>>>
>>>>>> Are we going to remove ant from framework completely or planning to
>>>>>> keep
>>>>>> both ant and gradle?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks & Regards
>>>>>> --
>>>>>> Deepak Dixit
>>>>>> www.hotwaxsystems.com
>>>>>>
>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>>>> <javascript:;>> wrote:
>>>>>>
>>>>>> Hi Everyone
>>>>>>>
>>>>>>> This is the second of two emails to inform the community about what
>>>>>>> has
>>>>>>> been happening around how we are planning to handle external
>>>>>>> dependencies
>>>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>>>> the use
>>>>>>> of Gradle to help us put together a unit test framework. While
>>>>>>> trying to
>>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>>
>>>>>> difficult.
>>>>>>
>>>>>>> This was because our Ant scripts:
>>>>>>>
>>>>>>> - are massive and contain a lot of code
>>>>>>> - are complex
>>>>>>> - are very brittle and make it very hard to change things
>>>>>>> - have no dependency management
>>>>>>> - need everything to be declared
>>>>>>>
>>>>>>> We realised very quickly that the re-factoring issues and
>>>>>>> limitations we
>>>>>>> are facing are because of our build tool – Ant.
>>>>>>>
>>>>>>> Ant is verbose so it needs everything to be declared. We did a brief
>>>>>>> assessment of Maven and found it better than Ant but not a good fit
>>>>>>> for
>>>>>>> OFBiz because it has strict requirements for the
>>>>>>> convention-over-configuration rules to work. Instead we decided to
>>>>>>> take a
>>>>>>> closer look at Gradle.
>>>>>>>
>>>>>>> So why Gradle?
>>>>>>> As Taher was already looking at Gradle for unit testing, we decided
>>>>>>> to
>>>>>>> look at what we would need to do to totally replace Ant with Gradle.
>>>>>>> We
>>>>>>> received some great support and feedback from David, who is already
>>>>>>> using
>>>>>>> Gradle with Moqui.
>>>>>>>
>>>>>>> After some preliminary tests we found that Gradle has some very good
>>>>>>> features such as:
>>>>>>>
>>>>>>> - a much shorter code base (e.g. one single file of around 250
>>>>>>> lines
>>>>>>>
>>>>>> of
>>>>>>
>>>>>>> code replaces all the build.xml files and thousands of lines of code)
>>>>>>> - Programming is DSL based and links in well with Groovy (e.g.
>>>>>>> the
>>>>>>> script is short because despite heavy custom requirements for OFBiz,
>>>>>>> two
>>>>>>> small functions took care of the complex directory structure)
>>>>>>> - It handles all the external jar files by downloading any
>>>>>>>
>>>>>> dependencies
>>>>>>
>>>>>>> directly via internet
>>>>>>> - Jars can be upgraded by simply changing a string
>>>>>>> - It has matured a lot and has a high level of support in
>>>>>>> tools,IDEs,
>>>>>>> books, documentation
>>>>>>> - It also has a lot of plugins which means that it works with
>>>>>>> pretty
>>>>>>> much all build systems, supports multiple programming languages, and
>>>>>>> many
>>>>>>> other features (e.g. OSGi)
>>>>>>>
>>>>>>> We understand that it can help us make OFBiz more modular and also
>>>>>>>
>>>>>> setting
>>>>>>
>>>>>>> up a framework for managing addons would be a lot easier.
>>>>>>>
>>>>>>> So what's been done?
>>>>>>> Taher has been working very hard on a patch for the trunk that
>>>>>>> completely
>>>>>>> replaces Ant with Gradle. (Huge thanks to David for providing some
>>>>>>>
>>>>>> example
>>>>>>
>>>>>>> scripts to help us get started!) The patch is now ready to be
>>>>>>> applied to
>>>>>>> the trunk and includes the following:
>>>>>>>
>>>>>>> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
>>>>>>> --whatever-options-here'
>>>>>>> - In addition to gradlew 'ofbiz' we also have gradlew
>>>>>>> 'ofbizDebug
>>>>>>> --whatever'. What does that mean? It means we can run debug on ALL
>>>>>>> ofbiz
>>>>>>> commands, not just start
>>>>>>> - If we decide to change the source directory structure in
>>>>>>> components
>>>>>>> say from /src to /src/main, it would literally be a change of 5
>>>>>>>
>>>>>> characters
>>>>>>
>>>>>>> in the build script
>>>>>>> - We can immediately move all jar files if we want to a unified
>>>>>>> location in /lib for example
>>>>>>> - We can delete most of the jars and declare them as
>>>>>>> dependencies
>>>>>>> saving space and resources
>>>>>>> - We can automate the creation of the .classpath file so when we
>>>>>>> update libraries no need to do this manually (under development)
>>>>>>> - We can ignore components that are not define in the xml files
>>>>>>> for
>>>>>>> loading (under development)
>>>>>>> - We can introduce unit tests with about 10 minutes of work
>>>>>>>
>>>>>>> We are finding that the flexibility and control we are getting with
>>>>>>>
>>>>>> Gradle
>>>>>>
>>>>>>> is truly amazing. We know that Gradle will be a major change to the
>>>>>>>
>>>>>> project
>>>>>>
>>>>>>> but we think that it will significantly improve the project by
>>>>>>> removing a
>>>>>>> lot of build complexity and take care of that essential dependency
>>>>>>> management that we need to comply with.
>>>>>>>
>>>>>>> Our next steps will be to apply the patch to the trunk and then
>>>>>>> continue
>>>>>>> the re-factoring work. We will need to organise some knowledge
>>>>>>> transfer
>>>>>>>
>>>>>> so
>>>>>>
>>>>>>> that all our committers understand what the changes are and how they
>>>>>>>
>>>>>> would
>>>>>>
>>>>>>> need to work in the future.
>>>>>>>
>>>>>>> The PMC are very, very excited about having Gradle as part of future
>>>>>>> of
>>>>>>> OFBiz and we hope that the community will think so too. As always,
>>>>>>>
>>>>>> feedback
>>>>>>
>>>>>>> welcome.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Sharan
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Everyone,
Thank you all for your support and kinds words. This is truly a wonderful
atmosphere and I am lucky, honoured, and privileged to work with you all on
this project.
My patch is almost done, but definitely there is a lot of work to be done
which includes the following:
- I have one failing test out of 889 that I need to dig through, maybe you
guy can help
- I want to change / delete / add some tasks
- Documentation needs to be updated in multiple areas
- Testing, testing, testing, testing, testing, testing, testing, testing,
testing
So the plan of action is as follows:
- I will continue the discussion on this thread for a few questions that I
need an answer for.
- I will issue a JIRA to hold the patch and everything else
Please consider helping, this is something that definitely needs a team,
more than one brain! If you are working on something not urgent, please
consider dropping it for a while and jump along for help.
I will post another email soon with the JIRA details and list of questions
I need answer for.
Again, thank you, you guys rock, I love OFBiz and this community!
Regards,
Taher Alkhateeb
On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <ni...@nereide.fr>
wrote:
> I'm in over for these technical aspects but the motivation and enthusiasm
> for many PMC and commiter tells me that seems a good way.
>
> So now I will learn gradle ;) and I'm in favor to realize this change
> directly on trunk
>
> Thks Taher to your engine energy on this subject !
>
> Nicolas
>
>
>
> Le 21/06/2016 10:43, Jacques Le Roux a écrit :
>
>> 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 <de...@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>> +1 for Gradle.
>>>>>
>>>>> Are we going to remove ant from framework completely or planning to
>>>>> keep
>>>>> both ant and gradle?
>>>>>
>>>>>
>>>>>
>>>>> Thanks & Regards
>>>>> --
>>>>> Deepak Dixit
>>>>> www.hotwaxsystems.com
>>>>>
>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>>> <javascript:;>> wrote:
>>>>>
>>>>> Hi Everyone
>>>>>>
>>>>>> This is the second of two emails to inform the community about what
>>>>>> has
>>>>>> been happening around how we are planning to handle external
>>>>>> dependencies
>>>>>> in the trunk. Two weeks ago the community discussed and agreed to the
>>>>>> use
>>>>>> of Gradle to help us put together a unit test framework. While trying
>>>>>> to
>>>>>> get this set up while Ant remained as our build tool became very
>>>>>>
>>>>> difficult.
>>>>>
>>>>>> This was because our Ant scripts:
>>>>>>
>>>>>> - are massive and contain a lot of code
>>>>>> - are complex
>>>>>> - are very brittle and make it very hard to change things
>>>>>> - have no dependency management
>>>>>> - need everything to be declared
>>>>>>
>>>>>> We realised very quickly that the re-factoring issues and limitations
>>>>>> we
>>>>>> are facing are because of our build tool – Ant.
>>>>>>
>>>>>> Ant is verbose so it needs everything to be declared. We did a brief
>>>>>> assessment of Maven and found it better than Ant but not a good fit
>>>>>> for
>>>>>> OFBiz because it has strict requirements for the
>>>>>> convention-over-configuration rules to work. Instead we decided to
>>>>>> take a
>>>>>> closer look at Gradle.
>>>>>>
>>>>>> So why Gradle?
>>>>>> As Taher was already looking at Gradle for unit testing, we decided to
>>>>>> look at what we would need to do to totally replace Ant with Gradle.
>>>>>> We
>>>>>> received some great support and feedback from David, who is already
>>>>>> using
>>>>>> Gradle with Moqui.
>>>>>>
>>>>>> After some preliminary tests we found that Gradle has some very good
>>>>>> features such as:
>>>>>>
>>>>>> - a much shorter code base (e.g. one single file of around 250
>>>>>> lines
>>>>>>
>>>>> of
>>>>>
>>>>>> code replaces all the build.xml files and thousands of lines of code)
>>>>>> - Programming is DSL based and links in well with Groovy (e.g.
>>>>>> the
>>>>>> script is short because despite heavy custom requirements for OFBiz,
>>>>>> two
>>>>>> small functions took care of the complex directory structure)
>>>>>> - It handles all the external jar files by downloading any
>>>>>>
>>>>> dependencies
>>>>>
>>>>>> directly via internet
>>>>>> - Jars can be upgraded by simply changing a string
>>>>>> - It has matured a lot and has a high level of support in
>>>>>> tools,IDEs,
>>>>>> books, documentation
>>>>>> - It also has a lot of plugins which means that it works with
>>>>>> pretty
>>>>>> much all build systems, supports multiple programming languages, and
>>>>>> many
>>>>>> other features (e.g. OSGi)
>>>>>>
>>>>>> We understand that it can help us make OFBiz more modular and also
>>>>>>
>>>>> setting
>>>>>
>>>>>> up a framework for managing addons would be a lot easier.
>>>>>>
>>>>>> So what's been done?
>>>>>> Taher has been working very hard on a patch for the trunk that
>>>>>> completely
>>>>>> replaces Ant with Gradle. (Huge thanks to David for providing some
>>>>>>
>>>>> example
>>>>>
>>>>>> scripts to help us get started!) The patch is now ready to be applied
>>>>>> to
>>>>>> the trunk and includes the following:
>>>>>>
>>>>>> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
>>>>>> --whatever-options-here'
>>>>>> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
>>>>>> --whatever'. What does that mean? It means we can run debug on ALL
>>>>>> ofbiz
>>>>>> commands, not just start
>>>>>> - If we decide to change the source directory structure in
>>>>>> components
>>>>>> say from /src to /src/main, it would literally be a change of 5
>>>>>>
>>>>> characters
>>>>>
>>>>>> in the build script
>>>>>> - We can immediately move all jar files if we want to a unified
>>>>>> location in /lib for example
>>>>>> - We can delete most of the jars and declare them as dependencies
>>>>>> saving space and resources
>>>>>> - We can automate the creation of the .classpath file so when we
>>>>>> update libraries no need to do this manually (under development)
>>>>>> - We can ignore components that are not define in the xml files
>>>>>> for
>>>>>> loading (under development)
>>>>>> - We can introduce unit tests with about 10 minutes of work
>>>>>>
>>>>>> We are finding that the flexibility and control we are getting with
>>>>>>
>>>>> Gradle
>>>>>
>>>>>> is truly amazing. We know that Gradle will be a major change to the
>>>>>>
>>>>> project
>>>>>
>>>>>> but we think that it will significantly improve the project by
>>>>>> removing a
>>>>>> lot of build complexity and take care of that essential dependency
>>>>>> management that we need to comply with.
>>>>>>
>>>>>> Our next steps will be to apply the patch to the trunk and then
>>>>>> continue
>>>>>> the re-factoring work. We will need to organise some knowledge
>>>>>> transfer
>>>>>>
>>>>> so
>>>>>
>>>>>> that all our committers understand what the changes are and how they
>>>>>>
>>>>> would
>>>>>
>>>>>> need to work in the future.
>>>>>>
>>>>>> The PMC are very, very excited about having Gradle as part of future
>>>>>> of
>>>>>> OFBiz and we hope that the community will think so too. As always,
>>>>>>
>>>>> feedback
>>>>>
>>>>>> welcome.
>>>>>>
>>>>>> Thanks
>>>>>> Sharan
>>>>>>
>>>>>>
>>>
>>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Nicolas Malin <ni...@nereide.fr>.
I'm in over for these technical aspects but the motivation and
enthusiasm for many PMC and commiter tells me that seems a good way.
So now I will learn gradle ;) and I'm in favor to realize this change
directly on trunk
Thks Taher to your engine energy on this subject !
Nicolas
Le 21/06/2016 10:43, Jacques Le Roux a �crit :
> 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 <de...@hotwaxsystems.com>
>>> wrote:
>>>
>>>> +1 for Gradle.
>>>>
>>>> Are we going to remove ant from framework completely or planning to
>>>> keep
>>>> both ant and gradle?
>>>>
>>>>
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>>
>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>>> <javascript:;>> wrote:
>>>>
>>>>> Hi Everyone
>>>>>
>>>>> This is the second of two emails to inform the community about
>>>>> what has
>>>>> been happening around how we are planning to handle external
>>>>> dependencies
>>>>> in the trunk. Two weeks ago the community discussed and agreed to
>>>>> the use
>>>>> of Gradle to help us put together a unit test framework. While
>>>>> trying to
>>>>> get this set up while Ant remained as our build tool became very
>>>> difficult.
>>>>> This was because our Ant scripts:
>>>>>
>>>>> - are massive and contain a lot of code
>>>>> - are complex
>>>>> - are very brittle and make it very hard to change things
>>>>> - have no dependency management
>>>>> - need everything to be declared
>>>>>
>>>>> We realised very quickly that the re-factoring issues and
>>>>> limitations we
>>>>> are facing are because of our build tool \u2013 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
>>>>>
>>
>>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <de...@hotwaxsystems.com>
>> wrote:
>>
>>> +1 for Gradle.
>>>
>>> Are we going to remove ant from framework completely or planning to keep
>>> both ant and gradle?
>>>
>>>
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>>
>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>>> <javascript:;>> wrote:
>>>
>>>> Hi Everyone
>>>>
>>>> This is the second of two emails to inform the community about what has
>>>> been happening around how we are planning to handle external dependencies
>>>> in the trunk. Two weeks ago the community discussed and agreed to the use
>>>> of Gradle to help us put together a unit test framework. While trying to
>>>> get this set up while Ant remained as our build tool became very
>>> difficult.
>>>> This was because our Ant scripts:
>>>>
>>>> - are massive and contain a lot of code
>>>> - are complex
>>>> - are very brittle and make it very hard to change things
>>>> - have no dependency management
>>>> - need everything to be declared
>>>>
>>>> We realised very quickly that the re-factoring issues and limitations we
>>>> are facing are because of our build tool \u2013 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
>>>>
>
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Michael Brohl <mi...@ecomify.de>.
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 <de...@hotwaxsystems.com>
> wrote:
>
>> +1 for Gradle.
>>
>> Are we going to remove ant from framework completely or planning to keep
>> both ant and gradle?
>>
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
>> <javascript:;>> wrote:
>>
>>> Hi Everyone
>>>
>>> This is the second of two emails to inform the community about what has
>>> been happening around how we are planning to handle external dependencies
>>> in the trunk. Two weeks ago the community discussed and agreed to the use
>>> of Gradle to help us put together a unit test framework. While trying to
>>> get this set up while Ant remained as our build tool became very
>> difficult.
>>> This was because our Ant scripts:
>>>
>>> - are massive and contain a lot of code
>>> - are complex
>>> - are very brittle and make it very hard to change things
>>> - have no dependency management
>>> - need everything to be declared
>>>
>>> We realised very quickly that the re-factoring issues and limitations we
>>> are facing are because of our build tool – Ant.
>>>
>>> Ant is verbose so it needs everything to be declared. We did a brief
>>> assessment of Maven and found it better than Ant but not a good fit for
>>> OFBiz because it has strict requirements for the
>>> convention-over-configuration rules to work. Instead we decided to take a
>>> closer look at Gradle.
>>>
>>> So why Gradle?
>>> As Taher was already looking at Gradle for unit testing, we decided to
>>> look at what we would need to do to totally replace Ant with Gradle. We
>>> received some great support and feedback from David, who is already using
>>> Gradle with Moqui.
>>>
>>> After some preliminary tests we found that Gradle has some very good
>>> features such as:
>>>
>>> - a much shorter code base (e.g. one single file of around 250 lines
>> of
>>> code replaces all the build.xml files and thousands of lines of code)
>>> - Programming is DSL based and links in well with Groovy (e.g. the
>>> script is short because despite heavy custom requirements for OFBiz, two
>>> small functions took care of the complex directory structure)
>>> - It handles all the external jar files by downloading any
>> dependencies
>>> directly via internet
>>> - Jars can be upgraded by simply changing a string
>>> - It has matured a lot and has a high level of support in tools,IDEs,
>>> books, documentation
>>> - It also has a lot of plugins which means that it works with pretty
>>> much all build systems, supports multiple programming languages, and many
>>> other features (e.g. OSGi)
>>>
>>> We understand that it can help us make OFBiz more modular and also
>> setting
>>> up a framework for managing addons would be a lot easier.
>>>
>>> So what's been done?
>>> Taher has been working very hard on a patch for the trunk that completely
>>> replaces Ant with Gradle. (Huge thanks to David for providing some
>> example
>>> scripts to help us get started!) The patch is now ready to be applied to
>>> the trunk and includes the following:
>>>
>>> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
>>> --whatever-options-here'
>>> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
>>> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
>>> commands, not just start
>>> - If we decide to change the source directory structure in components
>>> say from /src to /src/main, it would literally be a change of 5
>> characters
>>> in the build script
>>> - We can immediately move all jar files if we want to a unified
>>> location in /lib for example
>>> - We can delete most of the jars and declare them as dependencies
>>> saving space and resources
>>> - We can automate the creation of the .classpath file so when we
>>> update libraries no need to do this manually (under development)
>>> - We can ignore components that are not define in the xml files for
>>> loading (under development)
>>> - We can introduce unit tests with about 10 minutes of work
>>>
>>> We are finding that the flexibility and control we are getting with
>> Gradle
>>> is truly amazing. We know that Gradle will be a major change to the
>> project
>>> but we think that it will significantly improve the project by removing a
>>> lot of build complexity and take care of that essential dependency
>>> management that we need to comply with.
>>>
>>> Our next steps will be to apply the patch to the trunk and then continue
>>> the re-factoring work. We will need to organise some knowledge transfer
>> so
>>> that all our committers understand what the changes are and how they
>> would
>>> need to work in the future.
>>>
>>> The PMC are very, very excited about having Gradle as part of future of
>>> OFBiz and we hope that the community will think so too. As always,
>> feedback
>>> welcome.
>>>
>>> Thanks
>>> Sharan
>>>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Gavin Mabie <kw...@gmail.com>.
+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 <
pranay.pandey@hotwaxsystems.com> 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 <
> slidingfilaments@gmail.com> 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 <de...@hotwaxsystems.com>
> > wrote:
> >
> > > +1 for Gradle.
> > >
> > > Are we going to remove ant from framework completely or planning to
> keep
> > > both ant and gradle?
> > >
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > www.hotwaxsystems.com
> > >
> > > On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
> > > <javascript:;>> wrote:
> > >
> > > > Hi Everyone
> > > >
> > > > This is the second of two emails to inform the community about what
> has
> > > > been happening around how we are planning to handle external
> > dependencies
> > > > in the trunk. Two weeks ago the community discussed and agreed to the
> > use
> > > > of Gradle to help us put together a unit test framework. While trying
> > to
> > > > get this set up while Ant remained as our build tool became very
> > > difficult.
> > > > This was because our Ant scripts:
> > > >
> > > > - are massive and contain a lot of code
> > > > - are complex
> > > > - are very brittle and make it very hard to change things
> > > > - have no dependency management
> > > > - need everything to be declared
> > > >
> > > > We realised very quickly that the re-factoring issues and limitations
> > we
> > > > are facing are because of our build tool – Ant.
> > > >
> > > > Ant is verbose so it needs everything to be declared. We did a brief
> > > > assessment of Maven and found it better than Ant but not a good fit
> for
> > > > OFBiz because it has strict requirements for the
> > > > convention-over-configuration rules to work. Instead we decided to
> > take a
> > > > closer look at Gradle.
> > > >
> > > > So why Gradle?
> > > > As Taher was already looking at Gradle for unit testing, we decided
> to
> > > > look at what we would need to do to totally replace Ant with Gradle.
> We
> > > > received some great support and feedback from David, who is already
> > using
> > > > Gradle with Moqui.
> > > >
> > > > After some preliminary tests we found that Gradle has some very good
> > > > features such as:
> > > >
> > > > - a much shorter code base (e.g. one single file of around 250
> lines
> > > of
> > > > code replaces all the build.xml files and thousands of lines of code)
> > > > - Programming is DSL based and links in well with Groovy (e.g.
> the
> > > > script is short because despite heavy custom requirements for OFBiz,
> > two
> > > > small functions took care of the complex directory structure)
> > > > - It handles all the external jar files by downloading any
> > > dependencies
> > > > directly via internet
> > > > - Jars can be upgraded by simply changing a string
> > > > - It has matured a lot and has a high level of support in
> > tools,IDEs,
> > > > books, documentation
> > > > - It also has a lot of plugins which means that it works with
> pretty
> > > > much all build systems, supports multiple programming languages, and
> > many
> > > > other features (e.g. OSGi)
> > > >
> > > > We understand that it can help us make OFBiz more modular and also
> > > setting
> > > > up a framework for managing addons would be a lot easier.
> > > >
> > > > So what's been done?
> > > > Taher has been working very hard on a patch for the trunk that
> > completely
> > > > replaces Ant with Gradle. (Huge thanks to David for providing some
> > > example
> > > > scripts to help us get started!) The patch is now ready to be applied
> > to
> > > > the trunk and includes the following:
> > > >
> > > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > > --whatever-options-here'
> > > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > > --whatever'. What does that mean? It means we can run debug on ALL
> > ofbiz
> > > > commands, not just start
> > > > - If we decide to change the source directory structure in
> > components
> > > > say from /src to /src/main, it would literally be a change of 5
> > > characters
> > > > in the build script
> > > > - We can immediately move all jar files if we want to a unified
> > > > location in /lib for example
> > > > - We can delete most of the jars and declare them as dependencies
> > > > saving space and resources
> > > > - We can automate the creation of the .classpath file so when we
> > > > update libraries no need to do this manually (under development)
> > > > - We can ignore components that are not define in the xml files
> for
> > > > loading (under development)
> > > > - We can introduce unit tests with about 10 minutes of work
> > > >
> > > > We are finding that the flexibility and control we are getting with
> > > Gradle
> > > > is truly amazing. We know that Gradle will be a major change to the
> > > project
> > > > but we think that it will significantly improve the project by
> > removing a
> > > > lot of build complexity and take care of that essential dependency
> > > > management that we need to comply with.
> > > >
> > > > Our next steps will be to apply the patch to the trunk and then
> > continue
> > > > the re-factoring work. We will need to organise some knowledge
> transfer
> > > so
> > > > that all our committers understand what the changes are and how they
> > > would
> > > > need to work in the future.
> > > >
> > > > The PMC are very, very excited about having Gradle as part of future
> of
> > > > OFBiz and we hope that the community will think so too. As always,
> > > feedback
> > > > welcome.
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > >
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Pranay Pandey <pr...@hotwaxsystems.com>.
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 <
slidingfilaments@gmail.com> 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 <de...@hotwaxsystems.com>
> wrote:
>
> > +1 for Gradle.
> >
> > Are we going to remove ant from framework completely or planning to keep
> > both ant and gradle?
> >
> >
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > www.hotwaxsystems.com
> >
> > On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
> > <javascript:;>> wrote:
> >
> > > Hi Everyone
> > >
> > > This is the second of two emails to inform the community about what has
> > > been happening around how we are planning to handle external
> dependencies
> > > in the trunk. Two weeks ago the community discussed and agreed to the
> use
> > > of Gradle to help us put together a unit test framework. While trying
> to
> > > get this set up while Ant remained as our build tool became very
> > difficult.
> > > This was because our Ant scripts:
> > >
> > > - are massive and contain a lot of code
> > > - are complex
> > > - are very brittle and make it very hard to change things
> > > - have no dependency management
> > > - need everything to be declared
> > >
> > > We realised very quickly that the re-factoring issues and limitations
> we
> > > are facing are because of our build tool – Ant.
> > >
> > > Ant is verbose so it needs everything to be declared. We did a brief
> > > assessment of Maven and found it better than Ant but not a good fit for
> > > OFBiz because it has strict requirements for the
> > > convention-over-configuration rules to work. Instead we decided to
> take a
> > > closer look at Gradle.
> > >
> > > So why Gradle?
> > > As Taher was already looking at Gradle for unit testing, we decided to
> > > look at what we would need to do to totally replace Ant with Gradle. We
> > > received some great support and feedback from David, who is already
> using
> > > Gradle with Moqui.
> > >
> > > After some preliminary tests we found that Gradle has some very good
> > > features such as:
> > >
> > > - a much shorter code base (e.g. one single file of around 250 lines
> > of
> > > code replaces all the build.xml files and thousands of lines of code)
> > > - Programming is DSL based and links in well with Groovy (e.g. the
> > > script is short because despite heavy custom requirements for OFBiz,
> two
> > > small functions took care of the complex directory structure)
> > > - It handles all the external jar files by downloading any
> > dependencies
> > > directly via internet
> > > - Jars can be upgraded by simply changing a string
> > > - It has matured a lot and has a high level of support in
> tools,IDEs,
> > > books, documentation
> > > - It also has a lot of plugins which means that it works with pretty
> > > much all build systems, supports multiple programming languages, and
> many
> > > other features (e.g. OSGi)
> > >
> > > We understand that it can help us make OFBiz more modular and also
> > setting
> > > up a framework for managing addons would be a lot easier.
> > >
> > > So what's been done?
> > > Taher has been working very hard on a patch for the trunk that
> completely
> > > replaces Ant with Gradle. (Huge thanks to David for providing some
> > example
> > > scripts to help us get started!) The patch is now ready to be applied
> to
> > > the trunk and includes the following:
> > >
> > > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > > --whatever-options-here'
> > > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > > --whatever'. What does that mean? It means we can run debug on ALL
> ofbiz
> > > commands, not just start
> > > - If we decide to change the source directory structure in
> components
> > > say from /src to /src/main, it would literally be a change of 5
> > characters
> > > in the build script
> > > - We can immediately move all jar files if we want to a unified
> > > location in /lib for example
> > > - We can delete most of the jars and declare them as dependencies
> > > saving space and resources
> > > - We can automate the creation of the .classpath file so when we
> > > update libraries no need to do this manually (under development)
> > > - We can ignore components that are not define in the xml files for
> > > loading (under development)
> > > - We can introduce unit tests with about 10 minutes of work
> > >
> > > We are finding that the flexibility and control we are getting with
> > Gradle
> > > is truly amazing. We know that Gradle will be a major change to the
> > project
> > > but we think that it will significantly improve the project by
> removing a
> > > lot of build complexity and take care of that essential dependency
> > > management that we need to comply with.
> > >
> > > Our next steps will be to apply the patch to the trunk and then
> continue
> > > the re-factoring work. We will need to organise some knowledge transfer
> > so
> > > that all our committers understand what the changes are and how they
> > would
> > > need to work in the future.
> > >
> > > The PMC are very, very excited about having Gradle as part of future of
> > > OFBiz and we hope that the community will think so too. As always,
> > feedback
> > > welcome.
> > >
> > > Thanks
> > > Sharan
> > >
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <de...@hotwaxsystems.com>
wrote:
> +1 for Gradle.
>
> Are we going to remove ant from framework completely or planning to keep
> both ant and gradle?
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sharan.foga@gmail.com
> <javascript:;>> wrote:
>
> > Hi Everyone
> >
> > This is the second of two emails to inform the community about what has
> > been happening around how we are planning to handle external dependencies
> > in the trunk. Two weeks ago the community discussed and agreed to the use
> > of Gradle to help us put together a unit test framework. While trying to
> > get this set up while Ant remained as our build tool became very
> difficult.
> > This was because our Ant scripts:
> >
> > - are massive and contain a lot of code
> > - are complex
> > - are very brittle and make it very hard to change things
> > - have no dependency management
> > - need everything to be declared
> >
> > We realised very quickly that the re-factoring issues and limitations we
> > are facing are because of our build tool – Ant.
> >
> > Ant is verbose so it needs everything to be declared. We did a brief
> > assessment of Maven and found it better than Ant but not a good fit for
> > OFBiz because it has strict requirements for the
> > convention-over-configuration rules to work. Instead we decided to take a
> > closer look at Gradle.
> >
> > So why Gradle?
> > As Taher was already looking at Gradle for unit testing, we decided to
> > look at what we would need to do to totally replace Ant with Gradle. We
> > received some great support and feedback from David, who is already using
> > Gradle with Moqui.
> >
> > After some preliminary tests we found that Gradle has some very good
> > features such as:
> >
> > - a much shorter code base (e.g. one single file of around 250 lines
> of
> > code replaces all the build.xml files and thousands of lines of code)
> > - Programming is DSL based and links in well with Groovy (e.g. the
> > script is short because despite heavy custom requirements for OFBiz, two
> > small functions took care of the complex directory structure)
> > - It handles all the external jar files by downloading any
> dependencies
> > directly via internet
> > - Jars can be upgraded by simply changing a string
> > - It has matured a lot and has a high level of support in tools,IDEs,
> > books, documentation
> > - It also has a lot of plugins which means that it works with pretty
> > much all build systems, supports multiple programming languages, and many
> > other features (e.g. OSGi)
> >
> > We understand that it can help us make OFBiz more modular and also
> setting
> > up a framework for managing addons would be a lot easier.
> >
> > So what's been done?
> > Taher has been working very hard on a patch for the trunk that completely
> > replaces Ant with Gradle. (Huge thanks to David for providing some
> example
> > scripts to help us get started!) The patch is now ready to be applied to
> > the trunk and includes the following:
> >
> > - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> > --whatever-options-here'
> > - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> > --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> > commands, not just start
> > - If we decide to change the source directory structure in components
> > say from /src to /src/main, it would literally be a change of 5
> characters
> > in the build script
> > - We can immediately move all jar files if we want to a unified
> > location in /lib for example
> > - We can delete most of the jars and declare them as dependencies
> > saving space and resources
> > - We can automate the creation of the .classpath file so when we
> > update libraries no need to do this manually (under development)
> > - We can ignore components that are not define in the xml files for
> > loading (under development)
> > - We can introduce unit tests with about 10 minutes of work
> >
> > We are finding that the flexibility and control we are getting with
> Gradle
> > is truly amazing. We know that Gradle will be a major change to the
> project
> > but we think that it will significantly improve the project by removing a
> > lot of build complexity and take care of that essential dependency
> > management that we need to comply with.
> >
> > Our next steps will be to apply the patch to the trunk and then continue
> > the re-factoring work. We will need to organise some knowledge transfer
> so
> > that all our committers understand what the changes are and how they
> would
> > need to work in the future.
> >
> > The PMC are very, very excited about having Gradle as part of future of
> > OFBiz and we hope that the community will think so too. As always,
> feedback
> > welcome.
> >
> > Thanks
> > Sharan
> >
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
+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 <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 \u2013 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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Ashish Vijaywargiya <as...@hotwaxsystems.com>.
+1 for moving to Gradle!
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
+1 for switching to Gradle.
Jacopo
On Mon, Jun 20, 2016 at 2:50 PM, Sharan Foga <sh...@gmail.com> wrote:
> Hi Everyone
>
> This is the second of two emails to inform the community about what has
> been happening around how we are planning to handle external dependencies
> in the trunk. Two weeks ago the community discussed and agreed to the use
> of Gradle to help us put together a unit test framework. While trying to
> get this set up while Ant remained as our build tool became very difficult.
> This was because our Ant scripts:
>
> - are massive and contain a lot of code
> - are complex
> - are very brittle and make it very hard to change things
> - have no dependency management
> - need everything to be declared
>
> We realised very quickly that the re-factoring issues and limitations we
> are facing are because of our build tool – Ant.
>
> Ant is verbose so it needs everything to be declared. We did a brief
> assessment of Maven and found it better than Ant but not a good fit for
> OFBiz because it has strict requirements for the
> convention-over-configuration rules to work. Instead we decided to take a
> closer look at Gradle.
>
> So why Gradle?
> As Taher was already looking at Gradle for unit testing, we decided to
> look at what we would need to do to totally replace Ant with Gradle. We
> received some great support and feedback from David, who is already using
> Gradle with Moqui.
>
> After some preliminary tests we found that Gradle has some very good
> features such as:
>
> - a much shorter code base (e.g. one single file of around 250 lines of
> code replaces all the build.xml files and thousands of lines of code)
> - Programming is DSL based and links in well with Groovy (e.g. the
> script is short because despite heavy custom requirements for OFBiz, two
> small functions took care of the complex directory structure)
> - It handles all the external jar files by downloading any dependencies
> directly via internet
> - Jars can be upgraded by simply changing a string
> - It has matured a lot and has a high level of support in tools,IDEs,
> books, documentation
> - It also has a lot of plugins which means that it works with pretty
> much all build systems, supports multiple programming languages, and many
> other features (e.g. OSGi)
>
> We understand that it can help us make OFBiz more modular and also setting
> up a framework for managing addons would be a lot easier.
>
> So what's been done?
> Taher has been working very hard on a patch for the trunk that completely
> replaces Ant with Gradle. (Huge thanks to David for providing some example
> scripts to help us get started!) The patch is now ready to be applied to
> the trunk and includes the following:
>
> - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz
> --whatever-options-here'
> - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug
> --whatever'. What does that mean? It means we can run debug on ALL ofbiz
> commands, not just start
> - If we decide to change the source directory structure in components
> say from /src to /src/main, it would literally be a change of 5 characters
> in the build script
> - We can immediately move all jar files if we want to a unified
> location in /lib for example
> - We can delete most of the jars and declare them as dependencies
> saving space and resources
> - We can automate the creation of the .classpath file so when we
> update libraries no need to do this manually (under development)
> - We can ignore components that are not define in the xml files for
> loading (under development)
> - We can introduce unit tests with about 10 minutes of work
>
> We are finding that the flexibility and control we are getting with Gradle
> is truly amazing. We know that Gradle will be a major change to the project
> but we think that it will significantly improve the project by removing a
> lot of build complexity and take care of that essential dependency
> management that we need to comply with.
>
> Our next steps will be to apply the patch to the trunk and then continue
> the re-factoring work. We will need to organise some knowledge transfer so
> that all our committers understand what the changes are and how they would
> need to work in the future.
>
> The PMC are very, very excited about having Gradle as part of future of
> OFBiz and we hope that the community will think so too. As always, feedback
> welcome.
>
> Thanks
> Sharan
>
Re: Important Changes to Trunk and Use of Ant & Gradle
Posted by Michael Brohl <mi...@ecomify.de>.
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