You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2014/08/20 14:51:41 UTC
Discussion: migrating from Ant to Gradle
http://www.gradle.org
What do you think?
We could write more powerful and elegant build scripts, add also have a dependency management system. It is licensed under ASL2.0.
Jacopo
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 20/08/2014 17:26, Ron Wheeler a écrit :
> Making the decision about whether to do it and in which release can be kept as 2 separate decisions.
>
A branch is not necessarily created to be released. It can simply be merged later in trunk when everybody agree (lazy consensus:
http://www.apache.org/foundation/voting.html)
For instance I currently maintain (merge trunk in it each week) a branch for a planned SEO feature:
https://issues.apache.org/jira/browse/OFBIZ-5312
http://svn.apache.org/viewvc?view=revision&revision=1540814
Someone interested by the feature can test it and use it in her/his own development (this one is very near trunk)
https://issues.apache.org/jira/browse/OFBIZ-5312?focusedCommentId=13815600
> The discussion about benefits, skill sets, technical implications is one issue.
> How will the decision be made (criteria, etc.)?
> Who will investigate? What tests need to be done to prove the viability. What document will record the conversations and analysis?
>
> When will it be done? How it should be integrated into the release roadmap and development structure? Who will redo and test the scripts? Who will
> redo the documentation?
> These are all separate issues that only become important after the decision is made to actually do it.
All those are certainly good questions, at this hour I have not the energy to answer :)
Jacques
>
> Ron
>
> On 20/08/2014 10:34 AM, Pierre Smits wrote:
>> Jacopo,
>>
>> What scripts do you have in mind that need to be enhanced or added? Can you
>> outline your thoughts for each?
>>
>> Replacing current ant scripts or even encasing these in another convention
>> means that users (both system administrators and developers) need to update
>> their knowledge and skills. Plus all related documents need to reviewed as
>> well. This all takes time. And should therefore be planned.
>>
>> We have keep in mind that the majority of our user base is not a group of
>> developers but businesses. And these businesses have ease of operations and
>> trustworthiness in mind. Not ease of development.
>>
>> Nevertheless, if we are to go on this path I suggest that we do this isn a
>> separate development branch. That eventually can be brought back to a
>> release.
>>
>> Regards,
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Wed, Aug 20, 2014 at 2:51 PM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> http://www.gradle.org
>>>
>>> What do you think?
>>> We could write more powerful and elegant build scripts, add also have a
>>> dependency management system. It is licensed under ASL2.0.
>>>
>>> Jacopo
>
>
Re: Discussion: migrating from Ant to Gradle
Posted by Ron Wheeler <rw...@artifact-software.com>.
Making the decision about whether to do it and in which release can be
kept as 2 separate decisions.
The discussion about benefits, skill sets, technical implications is one
issue.
How will the decision be made (criteria, etc.)?
Who will investigate? What tests need to be done to prove the
viability. What document will record the conversations and analysis?
When will it be done? How it should be integrated into the release
roadmap and development structure? Who will redo and test the scripts?
Who will redo the documentation?
These are all separate issues that only become important after the
decision is made to actually do it.
Ron
On 20/08/2014 10:34 AM, Pierre Smits wrote:
> Jacopo,
>
> What scripts do you have in mind that need to be enhanced or added? Can you
> outline your thoughts for each?
>
> Replacing current ant scripts or even encasing these in another convention
> means that users (both system administrators and developers) need to update
> their knowledge and skills. Plus all related documents need to reviewed as
> well. This all takes time. And should therefore be planned.
>
> We have keep in mind that the majority of our user base is not a group of
> developers but businesses. And these businesses have ease of operations and
> trustworthiness in mind. Not ease of development.
>
> Nevertheless, if we are to go on this path I suggest that we do this isn a
> separate development branch. That eventually can be brought back to a
> release.
>
> Regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Wed, Aug 20, 2014 at 2:51 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> http://www.gradle.org
>>
>> What do you think?
>> We could write more powerful and elegant build scripts, add also have a
>> dependency management system. It is licensed under ASL2.0.
>>
>> Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Discussion: migrating from Ant to Gradle
Posted by Pierre Smits <pi...@gmail.com>.
Jacopo,
What scripts do you have in mind that need to be enhanced or added? Can you
outline your thoughts for each?
Replacing current ant scripts or even encasing these in another convention
means that users (both system administrators and developers) need to update
their knowledge and skills. Plus all related documents need to reviewed as
well. This all takes time. And should therefore be planned.
We have keep in mind that the majority of our user base is not a group of
developers but businesses. And these businesses have ease of operations and
trustworthiness in mind. Not ease of development.
Nevertheless, if we are to go on this path I suggest that we do this isn a
separate development branch. That eventually can be brought back to a
release.
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Aug 20, 2014 at 2:51 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:
> http://www.gradle.org
>
> What do you think?
> We could write more powerful and elegant build scripts, add also have a
> dependency management system. It is licensed under ASL2.0.
>
> Jacopo
Re: Discussion: migrating from Ant to Gradle
Posted by Hans Bakker <ma...@antwebsystems.com>.
+1 having a new feature branch, and then merge after review AND
automated tests.
On 21/08/14 17:40, Jacques Le Roux wrote:
>
> Le 21/08/2014 07:41, Jacopo Cappellato a écrit :
>> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>
>>> This is one reason which would refrain me to jump right now. With of
>>> course all the burden and especially the inherent risks of permutation.
>>>
>>> I think that Pierre's idea of a branch is a reasonable compromise
>>>
>>> Jacques
>> Of course, if we will ever try the switch to Gradle, this would be
>> done in the trunk only, not backported to releases; so the
>> instability period will only affect the trunk.
>> This is exactly the purpose of trunk vs release branches.
>> The fact that there are persons that use the trunk in production, and
>> that don't want it too change much because this may cause them to
>> work to keep their custom tools/code up-to-date, is a burden that
>> slows down the evolution of OFBiz.
>>
>> Jacopo
>>
> I think you did not get me right. Like I have explained to Ron,
> branches are not only to get stabilised releases. So my idea would be
> to have a new feature branch where we can make the desired changes
> before merging them in the trunk, when happy with them.
>
> This is for instance what I did for the jQuery move. What I did also
> for the missed Tom Burn's new help (now a Neogia addon I have been
> told). And what I'm doing for the SEO branch I created for OFBIZ-5312
> which I want to merge back in trunk before we freeze a branch for the
> next release.
>
> So yes it's a bit a burden, but it's a way to (more) safely integrate
> new features in the trunk.
>
> Jacques
Re: Discussion: migrating from Ant to Gradle
Posted by Adrian Crum <ad...@sandglass-software.com>.
That is one person's opinion. The reason OFBiz got to where it is today
is because of innovation, and a certain fearlessness in trying new
things. But that fearlessness ended years ago.
Moqui exists because the OFBiz community turned its back on innovation.
I don't see Moqui ever making it into this project - simply because
every time it has been suggested, there has been opposition.
The project is doomed to be locked in its current state until the PMC
decides to embrace change.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/21/2014 7:47 PM, Jacques Le Roux wrote:
>
> Le 21/08/2014 15:48, Al Byers a écrit :
>> As a "pro" it should stated that migrating to gradle would - wait for
>> it -
>> help in the migration to and/or from moqui.org, as it is one its many
>> advanced built-in tools. I appreciate the groovy-everywhere
>> consistency of
>> moqui and believe that it would be a good direction for OFBiz to head.
>
> I'd not be against that, still a long term goal...
> For now OFBiz has a much larger users base than Moqui, sot it's less
> flexible (one of the reason David created Moqui).
> We must be cautious with our technical moves; nothing impossible though,
> especially Gradle indeed
>
> Jacques
>
>>
>>
>> On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> I think you did not get me right. Like I have explained to Ron,
>>>> branches
>>> are not only to get stabilised releases. So my idea would be to have
>>> a new
>>> feature branch where we can make the desired changes before merging
>>> them in
>>> the trunk, when happy with them.
>>>> This is for instance what I did for the jQuery move. What I did also
>>>> for
>>> the missed Tom Burn's new help (now a Neogia addon I have been told).
>>> And
>>> what I'm doing for the SEO branch I created for OFBIZ-5312 which I
>>> want to
>>> merge back in trunk before we freeze a branch for the next release.
>>>> So yes it's a bit a burden, but it's a way to (more) safely integrate
>>> new features in the trunk.
>>>> Jacques
>>> Experimental branches are useful for running experiments that impact a
>>> large amount of code or require several commits (and committers) to be
>>> completed; especially when the community is divided about the
>>> opportunity
>>> to integrate them. The examples you provided belongs to this group...
>>> the
>>> ant->gradle switch I am not sure because we could easily implement the
>>> gradle scripts while leaving the ant scripts in place and then remove
>>> the
>>> ant scripts only when we will have enough confidence.
>>> But really it is too early to talk about how to do this work... at the
>>> moment we can just focus on the pros/cons of this switch.
>>>
>>> Jacopo
>>>
>>>
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/08/2014 15:48, Al Byers a écrit :
> As a "pro" it should stated that migrating to gradle would - wait for it -
> help in the migration to and/or from moqui.org, as it is one its many
> advanced built-in tools. I appreciate the groovy-everywhere consistency of
> moqui and believe that it would be a good direction for OFBiz to head.
I'd not be against that, still a long term goal...
For now OFBiz has a much larger users base than Moqui, sot it's less flexible (one of the reason David created Moqui).
We must be cautious with our technical moves; nothing impossible though, especially Gradle indeed
Jacques
>
>
> On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> I think you did not get me right. Like I have explained to Ron, branches
>> are not only to get stabilised releases. So my idea would be to have a new
>> feature branch where we can make the desired changes before merging them in
>> the trunk, when happy with them.
>>> This is for instance what I did for the jQuery move. What I did also for
>> the missed Tom Burn's new help (now a Neogia addon I have been told). And
>> what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to
>> merge back in trunk before we freeze a branch for the next release.
>>> So yes it's a bit a burden, but it's a way to (more) safely integrate
>> new features in the trunk.
>>> Jacques
>> Experimental branches are useful for running experiments that impact a
>> large amount of code or require several commits (and committers) to be
>> completed; especially when the community is divided about the opportunity
>> to integrate them. The examples you provided belongs to this group... the
>> ant->gradle switch I am not sure because we could easily implement the
>> gradle scripts while leaving the ant scripts in place and then remove the
>> ant scripts only when we will have enough confidence.
>> But really it is too early to talk about how to do this work... at the
>> moment we can just focus on the pros/cons of this switch.
>>
>> Jacopo
>>
>>
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Adrian signaled ant builds have a nice autocompleter. What about Graddle?
One think I don't like (though it improved, and hopegully will continue to improve) is the autocompletion in Groovy scripts in Eclipse (I used Kepler,
I guess that's why people turn to IntelliJ), compared to Java
Le 22/08/2014 12:06, David E. Jones a écrit :
> With Moqui Framework I started using Ant and then migrated to Gradle. In doing so there are some things to be aware of:
>
> 1. because of the convention over configuration goal (defaults can generally be overridden, but it's a bit painful) it is a good idea to restructure things like the src directories to use the Maven style, ie things like "src/main/java" instead of plain "src", and then along with that it's nice to split out things like "src/main/groovy" for groovy classes that are built (not scripts interpreted/compiled at runtime, those are best elsewhere), and "src/main/resources" instead of the various "config" directories and other classpath resources
>
> 2. jar files can still be kept locally (using a local repository), and lib directories with jars can even be included with a wildcard, but it is also possible to use Maven repositories to get the jar files by specifying each jar explicitly in the gradle build file; for Moqui I went with a combination of these, using a local directory repository but also listing all jar files explicitly in anticipation of maybe using a remote repository in the future (for various reasons I like to have all jar files in the source repo instead of downloading at build time; and this way you have more control over dependency creep that sometimes happens when you pull jars plus all their dependencies from a remote repo)
>
> 3. there are various API details to get used to with Gradle, much like learning the XML elements supported in Ant, but the documentation for Gradle is really pretty good and especially these days examples are plentiful
>
> Overall using Gradle resulted in much simpler build files, it just takes care of a lot of things automagically that are pretty manual with Ant. OFBiz has some impressively complex build files that could perhaps be simplified a lot with Gradle (and/or made more flexible with support for Groovy scripting and the Gradle DSL).
>
> On a side note, using Spock for testing is very easy with Gradle... though not sure how it compares to using it with Ant as I've never tried it.
>
> Hope that helps...
>
> -David
>
>
>
> On Aug 21, 2014, at 6:48 AM, Al Byers <by...@automationgroups.com> wrote:
>
>> As a "pro" it should stated that migrating to gradle would - wait for it -
>> help in the migration to and/or from moqui.org, as it is one its many
>> advanced built-in tools. I appreciate the groovy-everywhere consistency of
>> moqui and believe that it would be a good direction for OFBiz to head.
>>
>>
>> On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> I think you did not get me right. Like I have explained to Ron, branches
>>> are not only to get stabilised releases. So my idea would be to have a new
>>> feature branch where we can make the desired changes before merging them in
>>> the trunk, when happy with them.
>>>> This is for instance what I did for the jQuery move. What I did also for
>>> the missed Tom Burn's new help (now a Neogia addon I have been told). And
>>> what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to
>>> merge back in trunk before we freeze a branch for the next release.
>>>> So yes it's a bit a burden, but it's a way to (more) safely integrate
>>> new features in the trunk.
>>>> Jacques
>>> Experimental branches are useful for running experiments that impact a
>>> large amount of code or require several commits (and committers) to be
>>> completed; especially when the community is divided about the opportunity
>>> to integrate them. The examples you provided belongs to this group... the
>>> ant->gradle switch I am not sure because we could easily implement the
>>> gradle scripts while leaving the ant scripts in place and then remove the
>>> ant scripts only when we will have enough confidence.
>>> But really it is too early to talk about how to do this work... at the
>>> moment we can just focus on the pros/cons of this switch.
>>>
>>> Jacopo
>>>
>>>
>
>
Re: Discussion: migrating from Ant to Gradle
Posted by "David E. Jones" <de...@me.com>.
With Moqui Framework I started using Ant and then migrated to Gradle. In doing so there are some things to be aware of:
1. because of the convention over configuration goal (defaults can generally be overridden, but it's a bit painful) it is a good idea to restructure things like the src directories to use the Maven style, ie things like "src/main/java" instead of plain "src", and then along with that it's nice to split out things like "src/main/groovy" for groovy classes that are built (not scripts interpreted/compiled at runtime, those are best elsewhere), and "src/main/resources" instead of the various "config" directories and other classpath resources
2. jar files can still be kept locally (using a local repository), and lib directories with jars can even be included with a wildcard, but it is also possible to use Maven repositories to get the jar files by specifying each jar explicitly in the gradle build file; for Moqui I went with a combination of these, using a local directory repository but also listing all jar files explicitly in anticipation of maybe using a remote repository in the future (for various reasons I like to have all jar files in the source repo instead of downloading at build time; and this way you have more control over dependency creep that sometimes happens when you pull jars plus all their dependencies from a remote repo)
3. there are various API details to get used to with Gradle, much like learning the XML elements supported in Ant, but the documentation for Gradle is really pretty good and especially these days examples are plentiful
Overall using Gradle resulted in much simpler build files, it just takes care of a lot of things automagically that are pretty manual with Ant. OFBiz has some impressively complex build files that could perhaps be simplified a lot with Gradle (and/or made more flexible with support for Groovy scripting and the Gradle DSL).
On a side note, using Spock for testing is very easy with Gradle... though not sure how it compares to using it with Ant as I've never tried it.
Hope that helps...
-David
On Aug 21, 2014, at 6:48 AM, Al Byers <by...@automationgroups.com> wrote:
> As a "pro" it should stated that migrating to gradle would - wait for it -
> help in the migration to and/or from moqui.org, as it is one its many
> advanced built-in tools. I appreciate the groovy-everywhere consistency of
> moqui and believe that it would be a good direction for OFBiz to head.
>
>
> On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>>
>> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> I think you did not get me right. Like I have explained to Ron, branches
>> are not only to get stabilised releases. So my idea would be to have a new
>> feature branch where we can make the desired changes before merging them in
>> the trunk, when happy with them.
>>>
>>> This is for instance what I did for the jQuery move. What I did also for
>> the missed Tom Burn's new help (now a Neogia addon I have been told). And
>> what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to
>> merge back in trunk before we freeze a branch for the next release.
>>>
>>> So yes it's a bit a burden, but it's a way to (more) safely integrate
>> new features in the trunk.
>>>
>>> Jacques
>>
>> Experimental branches are useful for running experiments that impact a
>> large amount of code or require several commits (and committers) to be
>> completed; especially when the community is divided about the opportunity
>> to integrate them. The examples you provided belongs to this group... the
>> ant->gradle switch I am not sure because we could easily implement the
>> gradle scripts while leaving the ant scripts in place and then remove the
>> ant scripts only when we will have enough confidence.
>> But really it is too early to talk about how to do this work... at the
>> moment we can just focus on the pros/cons of this switch.
>>
>> Jacopo
>>
>>
Re: Discussion: migrating from Ant to Gradle
Posted by Al Byers <by...@automationgroups.com>.
As a "pro" it should stated that migrating to gradle would - wait for it -
help in the migration to and/or from moqui.org, as it is one its many
advanced built-in tools. I appreciate the groovy-everywhere consistency of
moqui and believe that it would be a good direction for OFBiz to head.
On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:
>
> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > I think you did not get me right. Like I have explained to Ron, branches
> are not only to get stabilised releases. So my idea would be to have a new
> feature branch where we can make the desired changes before merging them in
> the trunk, when happy with them.
> >
> > This is for instance what I did for the jQuery move. What I did also for
> the missed Tom Burn's new help (now a Neogia addon I have been told). And
> what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to
> merge back in trunk before we freeze a branch for the next release.
> >
> > So yes it's a bit a burden, but it's a way to (more) safely integrate
> new features in the trunk.
> >
> > Jacques
>
> Experimental branches are useful for running experiments that impact a
> large amount of code or require several commits (and committers) to be
> completed; especially when the community is divided about the opportunity
> to integrate them. The examples you provided belongs to this group... the
> ant->gradle switch I am not sure because we could easily implement the
> gradle scripts while leaving the ant scripts in place and then remove the
> ant scripts only when we will have enough confidence.
> But really it is too early to talk about how to do this work... at the
> moment we can just focus on the pros/cons of this switch.
>
> Jacopo
>
>
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/08/2014 15:17, Jacopo Cappellato a écrit :
> On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> I think you did not get me right. Like I have explained to Ron, branches are not only to get stabilised releases. So my idea would be to have a new feature branch where we can make the desired changes before merging them in the trunk, when happy with them.
>>
>> This is for instance what I did for the jQuery move. What I did also for the missed Tom Burn's new help (now a Neogia addon I have been told). And what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to merge back in trunk before we freeze a branch for the next release.
>>
>> So yes it's a bit a burden, but it's a way to (more) safely integrate new features in the trunk.
>>
>> Jacques
> Experimental branches are useful for running experiments that impact a large amount of code or require several commits (and committers) to be completed; especially when the community is divided about the opportunity to integrate them. The examples you provided belongs to this group... the ant->gradle switch I am not sure because we could easily implement the gradle scripts while leaving the ant scripts in place and then remove the ant scripts only when we will have enough confidence.
That would have my agreement
Jacques
> But really it is too early to talk about how to do this work... at the moment we can just focus on the pros/cons of this switch.
>
> Jacopo
>
>
>
Re: Discussion: migrating from Ant to Gradle
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> I think you did not get me right. Like I have explained to Ron, branches are not only to get stabilised releases. So my idea would be to have a new feature branch where we can make the desired changes before merging them in the trunk, when happy with them.
>
> This is for instance what I did for the jQuery move. What I did also for the missed Tom Burn's new help (now a Neogia addon I have been told). And what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to merge back in trunk before we freeze a branch for the next release.
>
> So yes it's a bit a burden, but it's a way to (more) safely integrate new features in the trunk.
>
> Jacques
Experimental branches are useful for running experiments that impact a large amount of code or require several commits (and committers) to be completed; especially when the community is divided about the opportunity to integrate them. The examples you provided belongs to this group... the ant->gradle switch I am not sure because we could easily implement the gradle scripts while leaving the ant scripts in place and then remove the ant scripts only when we will have enough confidence.
But really it is too early to talk about how to do this work... at the moment we can just focus on the pros/cons of this switch.
Jacopo
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/08/2014 07:41, Jacopo Cappellato a écrit :
> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>>
>> I think that Pierre's idea of a branch is a reasonable compromise
>>
>> Jacques
> Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
> This is exactly the purpose of trunk vs release branches.
> The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
>
> Jacopo
>
I think you did not get me right. Like I have explained to Ron, branches are not only to get stabilised releases. So my idea would be to have a new
feature branch where we can make the desired changes before merging them in the trunk, when happy with them.
This is for instance what I did for the jQuery move. What I did also for the missed Tom Burn's new help (now a Neogia addon I have been told). And
what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to merge back in trunk before we freeze a branch for the next release.
So yes it's a bit a burden, but it's a way to (more) safely integrate new features in the trunk.
Jacques
Re: Discussion: continuous deployment was: Discussion: migrating from
Ant to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacopo,
One of the ideas we suggest is to introduce gradle alongside ant at the top
level directory (build.gradle next to build.xml) and replace some of the
scripts that currently exist under /tools with tasks and projects in gradle
(e.g. mergefromtrunk.sh). It is also quite trivial to design time-based
tasks which can be called from the continuous integration server (updating
infrastructure, automating workflow, etc ...). We can then start to slowly
replace ant across the project without a sudden full replacement given the
full inter-operability between ant and gradle.
Please let us know how can we be of help if you choose to integrate gradle!
Cheers!
Taher Alkhateeb
On Thu, Aug 21, 2014 at 9:39 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:
> What you describe is (I guess) essentially this:
>
> https://www.atlassian.com/git/workflows#!workflow-gitflow
>
> and I know it (we have projects following this pattern) and it works
> pretty well; this is *not* the workflow that OFBiz community is currently
> implementing. Theres is no right or wrong workflow... it depends on the
> project and requirements.
> The fact that your company is following a different workflow that works
> for you is great but it doesn't mean that the OFBiz community has to act
> accordingly.
> I am wide open to discuss the migration to different workflows and tools
> (like Git) but for now let's stick to what we have and not on what you have
> decided for your company.
>
> Jacopo
>
>
> On Aug 21, 2014, at 8:13 AM, Hans Bakker <ma...@antwebsystems.com>
> wrote:
>
> > Jacopo,
> >
> > Sorry to react on your comment at the end of your post below.
> >
> > May i ask you to study continuous deployment? Up to now the trunk was
> always very stable. Once in a while some problems, but they never lasted
> more than a couple of days.
> >
> > At AntWebsystems we are supporting continuous deployment (expect a
> linkedin post on this) and we upgrade our production OFBiz version every
> month by hand picking a trunk version which we think works. Then this
> version will run on our demo server for one month and when no problems will
> be put in production. This is working fine for the last 3 years.
> >
> > So what we are doing is upgrading the ofbiz core system every month,
> which a step in the direction of continuous deployment. However, the goal
> is that before any commit is going into trunk it should be tested (selenium
> and junit) and approved by at least another committer (peer review)
> >
> > I would like to know how others think about continuous testing and
> continuous deployment. If you make the master (sorry trunk) branch
> deliberately unstable and not create development branches, you kill the
> continous deployment principle.
> >
> > You want innovation?
> > 1. Convert to GIT
> > 2. install Gerrit for peer review
> > 3. Install Jenkins for running all tests daily, also run tests for the
> development branches
> > 4. Do not allow any change in the master branch ofbiz system without a
> successful junit or selenium test and peer approval.
> >
> > then you will have a production ready 'master' branch most of the time
> and the demo server can act as a staging server.
> >
> > Regards, Hans
> >
> >
> >
> >
> > On 21/08/14 12:41, Jacopo Cappellato wrote:
> >> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
> >>
> >>> This is one reason which would refrain me to jump right now. With of
> course all the burden and especially the inherent risks of permutation.
> >>>
> >>> I think that Pierre's idea of a branch is a reasonable compromise
> >>>
> >>> Jacques
> >> Of course, if we will ever try the switch to Gradle, this would be done
> in the trunk only, not backported to releases; so the instability period
> will only affect the trunk.
> >> This is exactly the purpose of trunk vs release branches.
> >> The fact that there are persons that use the trunk in production, and
> that don't want it too change much because this may cause them to work to
> keep their custom tools/code up-to-date, is a burden that slows down the
> evolution of OFBiz.
> >>
> >> Jacopo
> >
>
>
Re: Discussion: continuous deployment was: Discussion: migrating from Ant to Gradle
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
What you describe is (I guess) essentially this:
https://www.atlassian.com/git/workflows#!workflow-gitflow
and I know it (we have projects following this pattern) and it works pretty well; this is *not* the workflow that OFBiz community is currently implementing. Theres is no right or wrong workflow... it depends on the project and requirements.
The fact that your company is following a different workflow that works for you is great but it doesn't mean that the OFBiz community has to act accordingly.
I am wide open to discuss the migration to different workflows and tools (like Git) but for now let's stick to what we have and not on what you have decided for your company.
Jacopo
On Aug 21, 2014, at 8:13 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> Jacopo,
>
> Sorry to react on your comment at the end of your post below.
>
> May i ask you to study continuous deployment? Up to now the trunk was always very stable. Once in a while some problems, but they never lasted more than a couple of days.
>
> At AntWebsystems we are supporting continuous deployment (expect a linkedin post on this) and we upgrade our production OFBiz version every month by hand picking a trunk version which we think works. Then this version will run on our demo server for one month and when no problems will be put in production. This is working fine for the last 3 years.
>
> So what we are doing is upgrading the ofbiz core system every month, which a step in the direction of continuous deployment. However, the goal is that before any commit is going into trunk it should be tested (selenium and junit) and approved by at least another committer (peer review)
>
> I would like to know how others think about continuous testing and continuous deployment. If you make the master (sorry trunk) branch deliberately unstable and not create development branches, you kill the continous deployment principle.
>
> You want innovation?
> 1. Convert to GIT
> 2. install Gerrit for peer review
> 3. Install Jenkins for running all tests daily, also run tests for the development branches
> 4. Do not allow any change in the master branch ofbiz system without a successful junit or selenium test and peer approval.
>
> then you will have a production ready 'master' branch most of the time and the demo server can act as a staging server.
>
> Regards, Hans
>
>
>
>
> On 21/08/14 12:41, Jacopo Cappellato wrote:
>> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>>>
>>> I think that Pierre's idea of a branch is a reasonable compromise
>>>
>>> Jacques
>> Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
>> This is exactly the purpose of trunk vs release branches.
>> The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
>>
>> Jacopo
>
Re: Discussion: continuous deployment was: Discussion: migrating
from Ant to Gradle
Posted by Adrian Crum <ad...@sandglass-software.com>.
I have been a member of this community for 10 years, and I don't agree
that "Up to now the trunk was always very stable." The trunk has always
been the bleeding edge of OFBiz development and design - and that is the
reason we have release branches.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/21/2014 7:13 AM, Hans Bakker wrote:
> Jacopo,
>
> Sorry to react on your comment at the end of your post below.
>
> May i ask you to study continuous deployment? Up to now the trunk was
> always very stable. Once in a while some problems, but they never lasted
> more than a couple of days.
>
> At AntWebsystems we are supporting continuous deployment (expect a
> linkedin post on this) and we upgrade our production OFBiz version every
> month by hand picking a trunk version which we think works. Then this
> version will run on our demo server for one month and when no problems
> will be put in production. This is working fine for the last 3 years.
>
> So what we are doing is upgrading the ofbiz core system every month,
> which a step in the direction of continuous deployment. However, the
> goal is that before any commit is going into trunk it should be tested
> (selenium and junit) and approved by at least another committer (peer
> review)
>
> I would like to know how others think about continuous testing and
> continuous deployment. If you make the master (sorry trunk) branch
> deliberately unstable and not create development branches, you kill the
> continous deployment principle.
>
> You want innovation?
> 1. Convert to GIT
> 2. install Gerrit for peer review
> 3. Install Jenkins for running all tests daily, also run tests for the
> development branches
> 4. Do not allow any change in the master branch ofbiz system without a
> successful junit or selenium test and peer approval.
>
> then you will have a production ready 'master' branch most of the time
> and the demo server can act as a staging server.
>
> Regards, Hans
>
>
>
>
> On 21/08/14 12:41, Jacopo Cappellato wrote:
>> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>
>>> This is one reason which would refrain me to jump right now. With of
>>> course all the burden and especially the inherent risks of permutation.
>>>
>>> I think that Pierre's idea of a branch is a reasonable compromise
>>>
>>> Jacques
>> Of course, if we will ever try the switch to Gradle, this would be
>> done in the trunk only, not backported to releases; so the instability
>> period will only affect the trunk.
>> This is exactly the purpose of trunk vs release branches.
>> The fact that there are persons that use the trunk in production, and
>> that don't want it too change much because this may cause them to work
>> to keep their custom tools/code up-to-date, is a burden that slows
>> down the evolution of OFBiz.
>>
>> Jacopo
>
Discussion: continuous deployment was: Discussion: migrating from
Ant to Gradle
Posted by Hans Bakker <ma...@antwebsystems.com>.
Jacopo,
Sorry to react on your comment at the end of your post below.
May i ask you to study continuous deployment? Up to now the trunk was
always very stable. Once in a while some problems, but they never lasted
more than a couple of days.
At AntWebsystems we are supporting continuous deployment (expect a
linkedin post on this) and we upgrade our production OFBiz version every
month by hand picking a trunk version which we think works. Then this
version will run on our demo server for one month and when no problems
will be put in production. This is working fine for the last 3 years.
So what we are doing is upgrading the ofbiz core system every month,
which a step in the direction of continuous deployment. However, the
goal is that before any commit is going into trunk it should be tested
(selenium and junit) and approved by at least another committer (peer
review)
I would like to know how others think about continuous testing and
continuous deployment. If you make the master (sorry trunk) branch
deliberately unstable and not create development branches, you kill the
continous deployment principle.
You want innovation?
1. Convert to GIT
2. install Gerrit for peer review
3. Install Jenkins for running all tests daily, also run tests for the
development branches
4. Do not allow any change in the master branch ofbiz system without a
successful junit or selenium test and peer approval.
then you will have a production ready 'master' branch most of the time
and the demo server can act as a staging server.
Regards, Hans
On 21/08/14 12:41, Jacopo Cappellato wrote:
> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>>
>> I think that Pierre's idea of a branch is a reasonable compromise
>>
>> Jacques
> Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
> This is exactly the purpose of trunk vs release branches.
> The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
>
> Jacopo
Re: Discussion: migrating from Ant to Gradle
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>
> I think that Pierre's idea of a branch is a reasonable compromise
>
> Jacques
Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
This is exactly the purpose of trunk vs release branches.
The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
Jacopo
Re: Discussion: migrating from Ant to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 20/08/2014 15:13, Taher Alkhateeb a écrit :
> Hi Jacopo,
>
> We have worked with gradle for a few months now and find it very useful! It
> has convention over configuration like maven but also full power under the
> hood if needed. Ant is a first class citizen in gradle and you can build on
> top of existing build scripts if needed. Also lately the support ecosystem
> is growing including support tools and plugins. It works with Jenkins and
> eclipse at the very least.
>
> The only down side I can think of is maturity level in comparison to Ant.
This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
I think that Pierre's idea of a branch is a reasonable compromise
Jacques
>
> My 2 cents
>
> Taher Alkhateeb
> On Aug 20, 2014 4:00 PM, "Adrian Crum" <ad...@sandglass-software.com>
> wrote:
>
>> I like the auto-complete that ant XML files provide.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 8/20/2014 1:51 PM, Jacopo Cappellato wrote:
>>
>>> http://www.gradle.org
>>>
>>> What do you think?
>>> We could write more powerful and elegant build scripts, add also have a
>>> dependency management system. It is licensed under ASL2.0.
>>>
>>> Jacopo
>>>
>>>
Re: Discussion: migrating from Ant to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacopo,
We have worked with gradle for a few months now and find it very useful! It
has convention over configuration like maven but also full power under the
hood if needed. Ant is a first class citizen in gradle and you can build on
top of existing build scripts if needed. Also lately the support ecosystem
is growing including support tools and plugins. It works with Jenkins and
eclipse at the very least.
The only down side I can think of is maturity level in comparison to Ant.
My 2 cents
Taher Alkhateeb
On Aug 20, 2014 4:00 PM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> I like the auto-complete that ant XML files provide.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 8/20/2014 1:51 PM, Jacopo Cappellato wrote:
>
>> http://www.gradle.org
>>
>> What do you think?
>> We could write more powerful and elegant build scripts, add also have a
>> dependency management system. It is licensed under ASL2.0.
>>
>> Jacopo
>>
>>
Re: Discussion: migrating from Ant to Gradle
Posted by Adrian Crum <ad...@sandglass-software.com>.
I like the auto-complete that ant XML files provide.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/20/2014 1:51 PM, Jacopo Cappellato wrote:
> http://www.gradle.org
>
> What do you think?
> We could write more powerful and elegant build scripts, add also have a dependency management system. It is licensed under ASL2.0.
>
> Jacopo
>