Should few Gradle tasks be interactive has were similars in Ant?

[Jacques Le Roux]

Hi,

See https://issues.apache.org/jira/browse/OFBIZ-7773 and https://issues.apache.org/jira/browse/OFBIZ-7772

Opinions (about the question in title: "Should we?")

Thanks

Jacques

[Jacques Le Roux]

Le 10/07/2016 à 12:48, Jacques Le Roux a écrit :

> Hi,
>
> See https://issues.apache.org/jira/browse/OFBIZ-7773 and https://issues.apache.org/jira/browse/OFBIZ-7772
>
> Opinions (about the question in title: "Should we?")
>
> Thanks
>
> Jacques
>
>

This could help https://mrhaki.blogspot.fr/2010/09/gradle-goodness-get-user-input-values.html

Jacques

[Michael Brohl-3]

Hi Jacques,

I think builds should work without interaction on the command line,
which makes automation difficult and is less error prone.

I think it is sufficient to provide the functionality with task
parameters. If one wants interactive wizards, he could provide some for
the project.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 10.07.16 um 12:48 schrieb Jacques Le Roux:

> Hi,
>
> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
> https://issues.apache.org/jira/browse/OFBIZ-7772
>
> Opinions (about the question in title: "Should we?")
>
> Thanks
>
> Jacques
>

[taher]

Hi Jacques and all,

Michael makes a good point. It is not a very good practice to have user
input in build scripts.

Now, it is easy to create such tasks, and you can even make the input from
a full GUI application if you want to using swing. But the time and effort
to put into these tasks is not worth it for multiple reasons:

1- You cannot automate it
2- The command prompt would have some issues because the gradle status bar
(at the bottom with progress %) might obscure it
3- It is harder to test
4- It blocks! now remember Gradle is a multi-process system. It can execute
tasks in parallel increasing efficiency and throughput. What happens if you
mix commands together? This complicates matters
5- Many other tasks require flags which did not have user input. Take for
example the data loading tasks and the integration testing tasks.

If someone is sophisticated enough to create a new component or a new
tenant in the system I doubt they would need THAT much hand-holding.
Furthermore, everything is thoroughly documented in README.md that it would
take less than a few seconds to copy paste the command and change the flags
to your liking.

Regards,

Taher Alkhateeb

On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <[hidden email]>
wrote:

> Hi Jacques,
>
> I think builds should work without interaction on the command line, which
> makes automation difficult and is less error prone.
>
> I think it is sufficient to provide the functionality with task
> parameters. If one wants interactive wizards, he could provide some for the
> project.
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
>
> Hi,
>>
>> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>> https://issues.apache.org/jira/browse/OFBIZ-7772
>>
>> Opinions (about the question in title: "Should we?")
>>
>> Thanks
>>
>> Jacques
>>
>>
>
>

[Jacques Le Roux]

Thanks Michael, Taher for you thorough answers.

Agreed, when I Googled for "gradle interactive task" the 1st answer was https://docs.gradle.org/current/userguide/continuous_build.html

That's why I asked "Should we?" :)

Jacques


Le 10/07/2016 à 13:42, Taher Alkhateeb a écrit :

> Hi Jacques and all,
>
> Michael makes a good point. It is not a very good practice to have user
> input in build scripts.
>
> Now, it is easy to create such tasks, and you can even make the input from
> a full GUI application if you want to using swing. But the time and effort
> to put into these tasks is not worth it for multiple reasons:
>
> 1- You cannot automate it
> 2- The command prompt would have some issues because the gradle status bar
> (at the bottom with progress %) might obscure it
> 3- It is harder to test
> 4- It blocks! now remember Gradle is a multi-process system. It can execute
> tasks in parallel increasing efficiency and throughput. What happens if you
> mix commands together? This complicates matters
> 5- Many other tasks require flags which did not have user input. Take for
> example the data loading tasks and the integration testing tasks.
>
> If someone is sophisticated enough to create a new component or a new
> tenant in the system I doubt they would need THAT much hand-holding.
> Furthermore, everything is thoroughly documented in README.md that it would
> take less than a few seconds to copy paste the command and change the flags
> to your liking.
>
> Regards,
>
> Taher Alkhateeb
>
> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <[hidden email]>
> wrote:
>
>> Hi Jacques,
>>
>> I think builds should work without interaction on the command line, which
>> makes automation difficult and is less error prone.
>>
>> I think it is sufficient to provide the functionality with task
>> parameters. If one wants interactive wizards, he could provide some for the
>> project.
>>
>> Regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
>>
>> Hi,
>>> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>>> https://issues.apache.org/jira/browse/OFBIZ-7772
>>>
>>> Opinions (about the question in title: "Should we?")
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>

[Pierre Smits]

Taher raises a good point when he mentioned an adopter being sophisticated
enough, as it leads back to one of the most basic questions: for whom is
OFBiz intended?

Is the message to our adopters: 'Don't use our product if you're not
sophisticated (or qualified) enough, as we don't want to provide you with
some basic scripts that facilitate you'?

I guess that was never the intent. But I welcome a shared agreement on that
matter, as this clears up the confusion who it is this projects wants to
have as adopters of the product or as contributors.

When we have a clear answer to that aspect, we can clear this discussion
very easy.

When it is 'we only want those who meet the onboarding criteria (and I do
trust you will then define explicitly what they are)', then we don't need
to have these kind of discussions and any issue that doesn't make the cut
can be closed.

When it is 'we welcome all kinds of adopters and contributors', it is my
believe that we should build in hurdles down the line (in code, or what
qualifies as an issue or a discussion), but we should adhere more to that
intent.

So basically, the scripts to create tenants or components the gradle way is
a degradation in service. Something that worked and was testable in ant.
And now we are told: we shouldn't because it is difficult to test. Or,
because it another 'feature' obscures something.

Perhaps those who are implementing the gradle scripts are having a problem
with looking beyond the obvious, and the only thing they see is: gradle,
gradle and gradle. And anything else is wrong.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Jacques and all,
>
> Michael makes a good point. It is not a very good practice to have user
> input in build scripts.
>
> Now, it is easy to create such tasks, and you can even make the input from
> a full GUI application if you want to using swing. But the time and effort
> to put into these tasks is not worth it for multiple reasons:
>
> 1- You cannot automate it
> 2- The command prompt would have some issues because the gradle status bar
> (at the bottom with progress %) might obscure it
> 3- It is harder to test
> 4- It blocks! now remember Gradle is a multi-process system. It can execute
> tasks in parallel increasing efficiency and throughput. What happens if you
> mix commands together? This complicates matters
> 5- Many other tasks require flags which did not have user input. Take for
> example the data loading tasks and the integration testing tasks.
>
> If someone is sophisticated enough to create a new component or a new
> tenant in the system I doubt they would need THAT much hand-holding.
> Furthermore, everything is thoroughly documented in README.md that it would
> take less than a few seconds to copy paste the command and change the flags
> to your liking.
>
> Regards,
>
> Taher Alkhateeb
>
> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <[hidden email]>
> wrote:
>
> > Hi Jacques,
> >
> > I think builds should work without interaction on the command line, which
> > makes automation difficult and is less error prone.
> >
> > I think it is sufficient to provide the functionality with task
> > parameters. If one wants interactive wizards, he could provide some for
> the
> > project.
> >
> > Regards,
> >
> > Michael Brohl
> > ecomify GmbH
> > www.ecomify.de
> >
> >
> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
> >
> > Hi,
> >>
> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
> >> https://issues.apache.org/jira/browse/OFBIZ-7772
> >>
> >> Opinions (about the question in title: "Should we?")
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
> >
> >
>

[Pierre Smits]

Michael raises a good point when he mentioned: 'If one wants interactive
wizards, he could provide some for the project'.

Does that mean that he will commit those patches when they are provided?

A simple thing for an contributor could be to e.g. bring back ant scripts
that will facilitate such functions as ./ant create-component and ./ant
create-tenant.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Jul 10, 2016 at 3:42 PM, Pierre Smits <[hidden email]>
wrote:

> Taher raises a good point when he mentioned an adopter being sophisticated
> enough, as it leads back to one of the most basic questions: for whom is
> OFBiz intended?
>
> Is the message to our adopters: 'Don't use our product if you're not
> sophisticated (or qualified) enough, as we don't want to provide you with
> some basic scripts that facilitate you'?
>
> I guess that was never the intent. But I welcome a shared agreement on
> that matter, as this clears up the confusion who it is this projects wants
> to have as adopters of the product or as contributors.
>
> When we have a clear answer to that aspect, we can clear this discussion
> very easy.
>
> When it is 'we only want those who meet the onboarding criteria (and I do
> trust you will then define explicitly what they are)', then we don't need
> to have these kind of discussions and any issue that doesn't make the cut
> can be closed.
>
> When it is 'we welcome all kinds of adopters and contributors', it is my
> believe that we should build in hurdles down the line (in code, or what
> qualifies as an issue or a discussion), but we should adhere more to that
> intent.
>
> So basically, the scripts to create tenants or components the gradle way
> is a degradation in service. Something that worked and was testable in ant.
> And now we are told: we shouldn't because it is difficult to test. Or,
> because it another 'feature' obscures something.
>
> Perhaps those who are implementing the gradle scripts are having a problem
> with looking beyond the obvious, and the only thing they see is: gradle,
> gradle and gradle. And anything else is wrong.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <
> [hidden email]> wrote:
>
>> Hi Jacques and all,
>>
>> Michael makes a good point. It is not a very good practice to have user
>> input in build scripts.
>>
>> Now, it is easy to create such tasks, and you can even make the input from
>> a full GUI application if you want to using swing. But the time and effort
>> to put into these tasks is not worth it for multiple reasons:
>>
>> 1- You cannot automate it
>> 2- The command prompt would have some issues because the gradle status bar
>> (at the bottom with progress %) might obscure it
>> 3- It is harder to test
>> 4- It blocks! now remember Gradle is a multi-process system. It can
>> execute
>> tasks in parallel increasing efficiency and throughput. What happens if
>> you
>> mix commands together? This complicates matters
>> 5- Many other tasks require flags which did not have user input. Take for
>> example the data loading tasks and the integration testing tasks.
>>
>> If someone is sophisticated enough to create a new component or a new
>> tenant in the system I doubt they would need THAT much hand-holding.
>> Furthermore, everything is thoroughly documented in README.md that it
>> would
>> take less than a few seconds to copy paste the command and change the
>> flags
>> to your liking.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <[hidden email]>
>> wrote:
>>
>> > Hi Jacques,
>> >
>> > I think builds should work without interaction on the command line,
>> which
>> > makes automation difficult and is less error prone.
>> >
>> > I think it is sufficient to provide the functionality with task
>> > parameters. If one wants interactive wizards, he could provide some for
>> the
>> > project.
>> >
>> > Regards,
>> >
>> > Michael Brohl
>> > ecomify GmbH
>> > www.ecomify.de
>> >
>> >
>> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
>> >
>> > Hi,
>> >>
>> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>> >> https://issues.apache.org/jira/browse/OFBIZ-7772
>> >>
>> >> Opinions (about the question in title: "Should we?")
>> >>
>> >> Thanks
>> >>
>> >> Jacques
>> >>
>> >>
>> >
>> >
>>
>
>

[Pierre Smits]

Do I need to remind all that we only had 1 build script before gradle? It
was ./ant build.

Any other script was intended for either implementers, or administrators,
or developers or OFBiz contributors with privileges.

None of those were intended for the OFBiz server. The only scripts to be
regarded as an intended (primarily, not as a dependent or inherited)
service were/are rc scripts in the tools folder.

Best regards,


Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Jul 10, 2016 at 3:46 PM, Pierre Smits <[hidden email]>
wrote:

> Michael raises a good point when he mentioned: 'If one wants interactive
> wizards, he could provide some for the project'.
>
> Does that mean that he will commit those patches when they are provided?
>
> A simple thing for an contributor could be to e.g. bring back ant scripts
> that will facilitate such functions as ./ant create-component and ./ant
> create-tenant.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sun, Jul 10, 2016 at 3:42 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> Taher raises a good point when he mentioned an adopter being
>> sophisticated enough, as it leads back to one of the most basic questions:
>> for whom is OFBiz intended?
>>
>> Is the message to our adopters: 'Don't use our product if you're not
>> sophisticated (or qualified) enough, as we don't want to provide you with
>> some basic scripts that facilitate you'?
>>
>> I guess that was never the intent. But I welcome a shared agreement on
>> that matter, as this clears up the confusion who it is this projects wants
>> to have as adopters of the product or as contributors.
>>
>> When we have a clear answer to that aspect, we can clear this discussion
>> very easy.
>>
>> When it is 'we only want those who meet the onboarding criteria (and I do
>> trust you will then define explicitly what they are)', then we don't need
>> to have these kind of discussions and any issue that doesn't make the cut
>> can be closed.
>>
>> When it is 'we welcome all kinds of adopters and contributors', it is my
>> believe that we should build in hurdles down the line (in code, or what
>> qualifies as an issue or a discussion), but we should adhere more to that
>> intent.
>>
>> So basically, the scripts to create tenants or components the gradle way
>> is a degradation in service. Something that worked and was testable in ant.
>> And now we are told: we shouldn't because it is difficult to test. Or,
>> because it another 'feature' obscures something.
>>
>> Perhaps those who are implementing the gradle scripts are having a
>> problem with looking beyond the obvious, and the only thing they see is:
>> gradle, gradle and gradle. And anything else is wrong.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <
>> [hidden email]> wrote:
>>
>>> Hi Jacques and all,
>>>
>>> Michael makes a good point. It is not a very good practice to have user
>>> input in build scripts.
>>>
>>> Now, it is easy to create such tasks, and you can even make the input
>>> from
>>> a full GUI application if you want to using swing. But the time and
>>> effort
>>> to put into these tasks is not worth it for multiple reasons:
>>>
>>> 1- You cannot automate it
>>> 2- The command prompt would have some issues because the gradle status
>>> bar
>>> (at the bottom with progress %) might obscure it
>>> 3- It is harder to test
>>> 4- It blocks! now remember Gradle is a multi-process system. It can
>>> execute
>>> tasks in parallel increasing efficiency and throughput. What happens if
>>> you
>>> mix commands together? This complicates matters
>>> 5- Many other tasks require flags which did not have user input. Take for
>>> example the data loading tasks and the integration testing tasks.
>>>
>>> If someone is sophisticated enough to create a new component or a new
>>> tenant in the system I doubt they would need THAT much hand-holding.
>>> Furthermore, everything is thoroughly documented in README.md that it
>>> would
>>> take less than a few seconds to copy paste the command and change the
>>> flags
>>> to your liking.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <[hidden email]
>>> >
>>> wrote:
>>>
>>> > Hi Jacques,
>>> >
>>> > I think builds should work without interaction on the command line,
>>> which
>>> > makes automation difficult and is less error prone.
>>> >
>>> > I think it is sufficient to provide the functionality with task
>>> > parameters. If one wants interactive wizards, he could provide some
>>> for the
>>> > project.
>>> >
>>> > Regards,
>>> >
>>> > Michael Brohl
>>> > ecomify GmbH
>>> > www.ecomify.de
>>> >
>>> >
>>> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
>>> >
>>> > Hi,
>>> >>
>>> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>>> >> https://issues.apache.org/jira/browse/OFBIZ-7772
>>> >>
>>> >> Opinions (about the question in title: "Should we?")
>>> >>
>>> >> Thanks
>>> >>
>>> >> Jacques
>>> >>
>>> >>
>>> >
>>> >
>>>
>>
>>
>

[taher]

Hi Pierre and everyone,

If other people want to add interactive tasks I will happily volunteer to
implement them.

With that being said I recommend that we do not Implement them not for
difficulty but for correctness. The createComponent and createTenant tasks
were very difficult to implement and the most complex to both understand
the old ant logic and implement on Gradle. So it's not like we took any
shortcuts. If you look at the build script you'll see how complex these two
tasks are.

Just because something used to exist does not mean it was right. And for
correctness we need to be consistent. Either every task has a corresponding
interactive task or no interactive tasks exists. This of course is my own
opinion and everyone is welcome to express other opinions.

Cheers ..

Taher Alkhateeb
On Jul 10, 2016 4:49 PM, "Pierre Smits" <[hidden email]> wrote:

> Do I need to remind all that we only had 1 build script before gradle? It
> was ./ant build.
>
> Any other script was intended for either implementers, or administrators,
> or developers or OFBiz contributors with privileges.
>
> None of those were intended for the OFBiz server. The only scripts to be
> regarded as an intended (primarily, not as a dependent or inherited)
> service were/are rc scripts in the tools folder.
>
> Best regards,
>
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sun, Jul 10, 2016 at 3:46 PM, Pierre Smits <[hidden email]>
> wrote:
>
> > Michael raises a good point when he mentioned: 'If one wants interactive
> > wizards, he could provide some for the project'.
> >
> > Does that mean that he will commit those patches when they are provided?
> >
> > A simple thing for an contributor could be to e.g. bring back ant scripts
> > that will facilitate such functions as ./ant create-component and ./ant
> > create-tenant.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sun, Jul 10, 2016 at 3:42 PM, Pierre Smits <[hidden email]>
> > wrote:
> >
> >> Taher raises a good point when he mentioned an adopter being
> >> sophisticated enough, as it leads back to one of the most basic
> questions:
> >> for whom is OFBiz intended?
> >>
> >> Is the message to our adopters: 'Don't use our product if you're not
> >> sophisticated (or qualified) enough, as we don't want to provide you
> with
> >> some basic scripts that facilitate you'?
> >>
> >> I guess that was never the intent. But I welcome a shared agreement on
> >> that matter, as this clears up the confusion who it is this projects
> wants
> >> to have as adopters of the product or as contributors.
> >>
> >> When we have a clear answer to that aspect, we can clear this discussion
> >> very easy.
> >>
> >> When it is 'we only want those who meet the onboarding criteria (and I
> do
> >> trust you will then define explicitly what they are)', then we don't
> need
> >> to have these kind of discussions and any issue that doesn't make the
> cut
> >> can be closed.
> >>
> >> When it is 'we welcome all kinds of adopters and contributors', it is my
> >> believe that we should build in hurdles down the line (in code, or what
> >> qualifies as an issue or a discussion), but we should adhere more to
> that
> >> intent.
> >>
> >> So basically, the scripts to create tenants or components the gradle way
> >> is a degradation in service. Something that worked and was testable in
> ant.
> >> And now we are told: we shouldn't because it is difficult to test. Or,
> >> because it another 'feature' obscures something.
> >>
> >> Perhaps those who are implementing the gradle scripts are having a
> >> problem with looking beyond the obvious, and the only thing they see is:
> >> gradle, gradle and gradle. And anything else is wrong.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM <http://www.orrtiz.com>
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <
> >> [hidden email]> wrote:
> >>
> >>> Hi Jacques and all,
> >>>
> >>> Michael makes a good point. It is not a very good practice to have user
> >>> input in build scripts.
> >>>
> >>> Now, it is easy to create such tasks, and you can even make the input
> >>> from
> >>> a full GUI application if you want to using swing. But the time and
> >>> effort
> >>> to put into these tasks is not worth it for multiple reasons:
> >>>
> >>> 1- You cannot automate it
> >>> 2- The command prompt would have some issues because the gradle status
> >>> bar
> >>> (at the bottom with progress %) might obscure it
> >>> 3- It is harder to test
> >>> 4- It blocks! now remember Gradle is a multi-process system. It can
> >>> execute
> >>> tasks in parallel increasing efficiency and throughput. What happens if
> >>> you
> >>> mix commands together? This complicates matters
> >>> 5- Many other tasks require flags which did not have user input. Take
> for
> >>> example the data loading tasks and the integration testing tasks.
> >>>
> >>> If someone is sophisticated enough to create a new component or a new
> >>> tenant in the system I doubt they would need THAT much hand-holding.
> >>> Furthermore, everything is thoroughly documented in README.md that it
> >>> would
> >>> take less than a few seconds to copy paste the command and change the
> >>> flags
> >>> to your liking.
> >>>
> >>> Regards,
> >>>
> >>> Taher Alkhateeb
> >>>
> >>> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <
> [hidden email]
> >>> >
> >>> wrote:
> >>>
> >>> > Hi Jacques,
> >>> >
> >>> > I think builds should work without interaction on the command line,
> >>> which
> >>> > makes automation difficult and is less error prone.
> >>> >
> >>> > I think it is sufficient to provide the functionality with task
> >>> > parameters. If one wants interactive wizards, he could provide some
> >>> for the
> >>> > project.
> >>> >
> >>> > Regards,
> >>> >
> >>> > Michael Brohl
> >>> > ecomify GmbH
> >>> > www.ecomify.de
> >>> >
> >>> >
> >>> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
> >>> >
> >>> > Hi,
> >>> >>
> >>> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
> >>> >> https://issues.apache.org/jira/browse/OFBIZ-7772
> >>> >>
> >>> >> Opinions (about the question in title: "Should we?")
> >>> >>
> >>> >> Thanks
> >>> >>
> >>> >> Jacques
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>

[Pierre Smits]

Hi Taher,

As far as I can tell from the issue
https://issues.apache.org/jira/browse/OFBIZ-3971 the create-tenant
enhancement wasn't perceived as difficult to implement. Nor did I find it
difficult to develop it, before I submitted the patch.

Best regards,


Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Jul 10, 2016 at 5:23 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Pierre and everyone,
>
> If other people want to add interactive tasks I will happily volunteer to
> implement them.
>
> With that being said I recommend that we do not Implement them not for
> difficulty but for correctness. The createComponent and createTenant tasks
> were very difficult to implement and the most complex to both understand
> the old ant logic and implement on Gradle. So it's not like we took any
> shortcuts. If you look at the build script you'll see how complex these two
> tasks are.
>
> Just because something used to exist does not mean it was right. And for
> correctness we need to be consistent. Either every task has a corresponding
> interactive task or no interactive tasks exists. This of course is my own
> opinion and everyone is welcome to express other opinions.
>
> Cheers ..
>
> Taher Alkhateeb
> On Jul 10, 2016 4:49 PM, "Pierre Smits" <[hidden email]> wrote:
>
> > Do I need to remind all that we only had 1 build script before gradle? It
> > was ./ant build.
> >
> > Any other script was intended for either implementers, or administrators,
> > or developers or OFBiz contributors with privileges.
> >
> > None of those were intended for the OFBiz server. The only scripts to be
> > regarded as an intended (primarily, not as a dependent or inherited)
> > service were/are rc scripts in the tools folder.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sun, Jul 10, 2016 at 3:46 PM, Pierre Smits <[hidden email]>
> > wrote:
> >
> > > Michael raises a good point when he mentioned: 'If one wants
> interactive
> > > wizards, he could provide some for the project'.
> > >
> > > Does that mean that he will commit those patches when they are
> provided?
> > >
> > > A simple thing for an contributor could be to e.g. bring back ant
> scripts
> > > that will facilitate such functions as ./ant create-component and ./ant
> > > create-tenant.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Sun, Jul 10, 2016 at 3:42 PM, Pierre Smits <[hidden email]>
> > > wrote:
> > >
> > >> Taher raises a good point when he mentioned an adopter being
> > >> sophisticated enough, as it leads back to one of the most basic
> > questions:
> > >> for whom is OFBiz intended?
> > >>
> > >> Is the message to our adopters: 'Don't use our product if you're not
> > >> sophisticated (or qualified) enough, as we don't want to provide you
> > with
> > >> some basic scripts that facilitate you'?
> > >>
> > >> I guess that was never the intent. But I welcome a shared agreement on
> > >> that matter, as this clears up the confusion who it is this projects
> > wants
> > >> to have as adopters of the product or as contributors.
> > >>
> > >> When we have a clear answer to that aspect, we can clear this
> discussion
> > >> very easy.
> > >>
> > >> When it is 'we only want those who meet the onboarding criteria (and I
> > do
> > >> trust you will then define explicitly what they are)', then we don't
> > need
> > >> to have these kind of discussions and any issue that doesn't make the
> > cut
> > >> can be closed.
> > >>
> > >> When it is 'we welcome all kinds of adopters and contributors', it is
> my
> > >> believe that we should build in hurdles down the line (in code, or
> what
> > >> qualifies as an issue or a discussion), but we should adhere more to
> > that
> > >> intent.
> > >>
> > >> So basically, the scripts to create tenants or components the gradle
> way
> > >> is a degradation in service. Something that worked and was testable in
> > ant.
> > >> And now we are told: we shouldn't because it is difficult to test. Or,
> > >> because it another 'feature' obscures something.
> > >>
> > >> Perhaps those who are implementing the gradle scripts are having a
> > >> problem with looking beyond the obvious, and the only thing they see
> is:
> > >> gradle, gradle and gradle. And anything else is wrong.
> > >>
> > >> Best regards,
> > >>
> > >> Pierre Smits
> > >>
> > >> ORRTIZ.COM <http://www.orrtiz.com>
> > >> OFBiz based solutions & services
> > >>
> > >> OFBiz Extensions Marketplace
> > >> http://oem.ofbizci.net/oci-2/
> > >>
> > >> On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <
> > >> [hidden email]> wrote:
> > >>
> > >>> Hi Jacques and all,
> > >>>
> > >>> Michael makes a good point. It is not a very good practice to have
> user
> > >>> input in build scripts.
> > >>>
> > >>> Now, it is easy to create such tasks, and you can even make the input
> > >>> from
> > >>> a full GUI application if you want to using swing. But the time and
> > >>> effort
> > >>> to put into these tasks is not worth it for multiple reasons:
> > >>>
> > >>> 1- You cannot automate it
> > >>> 2- The command prompt would have some issues because the gradle
> status
> > >>> bar
> > >>> (at the bottom with progress %) might obscure it
> > >>> 3- It is harder to test
> > >>> 4- It blocks! now remember Gradle is a multi-process system. It can
> > >>> execute
> > >>> tasks in parallel increasing efficiency and throughput. What happens
> if
> > >>> you
> > >>> mix commands together? This complicates matters
> > >>> 5- Many other tasks require flags which did not have user input. Take
> > for
> > >>> example the data loading tasks and the integration testing tasks.
> > >>>
> > >>> If someone is sophisticated enough to create a new component or a new
> > >>> tenant in the system I doubt they would need THAT much hand-holding.
> > >>> Furthermore, everything is thoroughly documented in README.md that it
> > >>> would
> > >>> take less than a few seconds to copy paste the command and change the
> > >>> flags
> > >>> to your liking.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Taher Alkhateeb
> > >>>
> > >>> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <
> > [hidden email]
> > >>> >
> > >>> wrote:
> > >>>
> > >>> > Hi Jacques,
> > >>> >
> > >>> > I think builds should work without interaction on the command line,
> > >>> which
> > >>> > makes automation difficult and is less error prone.
> > >>> >
> > >>> > I think it is sufficient to provide the functionality with task
> > >>> > parameters. If one wants interactive wizards, he could provide some
> > >>> for the
> > >>> > project.
> > >>> >
> > >>> > Regards,
> > >>> >
> > >>> > Michael Brohl
> > >>> > ecomify GmbH
> > >>> > www.ecomify.de
> > >>> >
> > >>> >
> > >>> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
> > >>> >
> > >>> > Hi,
> > >>> >>
> > >>> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
> > >>> >> https://issues.apache.org/jira/browse/OFBIZ-7772
> > >>> >>
> > >>> >> Opinions (about the question in title: "Should we?")
> > >>> >>
> > >>> >> Thanks
> > >>> >>
> > >>> >> Jacques
> > >>> >>
> > >>> >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

[taher]

Hi Pierre,

If you read my input in this thread you will notice that I said it is not
difficult to implement interactive tasks. What was difficult is actually
implementing the full logic for the task itself which was long and
difficult both in Ant and Gradle.

Also thank you for your efforts, but I believe the script created is not
the best solution and unfortunately adds to the entropy in this project
because:
1- it was created in bash making it platform dependent
2- the logic is too simple and hence not very useful. You just enter values
one by one instead of flags
3- now we have a script that might break at any moment when we update the
build script.

It is much better to centralize everything in the build script. Our
intention was actually to delete everything in /tools and replace it with
one nice clean script that is platform independent and easy to maintain and
review.

Taher Alkhateeb

On Wednesday, 13 July 2016, Pierre Smits <[hidden email]> wrote:

> Hi Taher,
>
> As far as I can tell from the issue
> https://issues.apache.org/jira/browse/OFBIZ-3971 the create-tenant
> enhancement wasn't perceived as difficult to implement. Nor did I find it
> difficult to develop it, before I submitted the patch.
>
> Best regards,
>
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sun, Jul 10, 2016 at 5:23 PM, Taher Alkhateeb <
> [hidden email] <javascript:;>
> > wrote:
>
> > Hi Pierre and everyone,
> >
> > If other people want to add interactive tasks I will happily volunteer to
> > implement them.
> >
> > With that being said I recommend that we do not Implement them not for
> > difficulty but for correctness. The createComponent and createTenant
> tasks
> > were very difficult to implement and the most complex to both understand
> > the old ant logic and implement on Gradle. So it's not like we took any
> > shortcuts. If you look at the build script you'll see how complex these
> two
> > tasks are.
> >
> > Just because something used to exist does not mean it was right. And for
> > correctness we need to be consistent. Either every task has a
> corresponding
> > interactive task or no interactive tasks exists. This of course is my own
> > opinion and everyone is welcome to express other opinions.
> >
> > Cheers ..
> >
> > Taher Alkhateeb
> > On Jul 10, 2016 4:49 PM, "Pierre Smits" <[hidden email]
> <javascript:;>> wrote:
> >
> > > Do I need to remind all that we only had 1 build script before gradle?
> It
> > > was ./ant build.
> > >
> > > Any other script was intended for either implementers, or
> administrators,
> > > or developers or OFBiz contributors with privileges.
> > >
> > > None of those were intended for the OFBiz server. The only scripts to
> be
> > > regarded as an intended (primarily, not as a dependent or inherited)
> > > service were/are rc scripts in the tools folder.
> > >
> > > Best regards,
> > >
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Sun, Jul 10, 2016 at 3:46 PM, Pierre Smits <[hidden email]
> <javascript:;>>
> > > wrote:
> > >
> > > > Michael raises a good point when he mentioned: 'If one wants
> > interactive
> > > > wizards, he could provide some for the project'.
> > > >
> > > > Does that mean that he will commit those patches when they are
> > provided?
> > > >
> > > > A simple thing for an contributor could be to e.g. bring back ant
> > scripts
> > > > that will facilitate such functions as ./ant create-component and
> ./ant
> > > > create-tenant.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Sun, Jul 10, 2016 at 3:42 PM, Pierre Smits <
> [hidden email] <javascript:;>>
> > > > wrote:
> > > >
> > > >> Taher raises a good point when he mentioned an adopter being
> > > >> sophisticated enough, as it leads back to one of the most basic
> > > questions:
> > > >> for whom is OFBiz intended?
> > > >>
> > > >> Is the message to our adopters: 'Don't use our product if you're not
> > > >> sophisticated (or qualified) enough, as we don't want to provide you
> > > with
> > > >> some basic scripts that facilitate you'?
> > > >>
> > > >> I guess that was never the intent. But I welcome a shared agreement
> on
> > > >> that matter, as this clears up the confusion who it is this projects
> > > wants
> > > >> to have as adopters of the product or as contributors.
> > > >>
> > > >> When we have a clear answer to that aspect, we can clear this
> > discussion
> > > >> very easy.
> > > >>
> > > >> When it is 'we only want those who meet the onboarding criteria
> (and I
> > > do
> > > >> trust you will then define explicitly what they are)', then we don't
> > > need
> > > >> to have these kind of discussions and any issue that doesn't make
> the
> > > cut
> > > >> can be closed.
> > > >>
> > > >> When it is 'we welcome all kinds of adopters and contributors', it
> is
> > my
> > > >> believe that we should build in hurdles down the line (in code, or
> > what
> > > >> qualifies as an issue or a discussion), but we should adhere more to
> > > that
> > > >> intent.
> > > >>
> > > >> So basically, the scripts to create tenants or components the gradle
> > way
> > > >> is a degradation in service. Something that worked and was testable
> in
> > > ant.
> > > >> And now we are told: we shouldn't because it is difficult to test.
> Or,
> > > >> because it another 'feature' obscures something.
> > > >>
> > > >> Perhaps those who are implementing the gradle scripts are having a
> > > >> problem with looking beyond the obvious, and the only thing they see
> > is:
> > > >> gradle, gradle and gradle. And anything else is wrong.
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Pierre Smits
> > > >>
> > > >> ORRTIZ.COM <http://www.orrtiz.com>
> > > >> OFBiz based solutions & services
> > > >>
> > > >> OFBiz Extensions Marketplace
> > > >> http://oem.ofbizci.net/oci-2/
> > > >>
> > > >> On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <
> > > >> [hidden email] <javascript:;>> wrote:
> > > >>
> > > >>> Hi Jacques and all,
> > > >>>
> > > >>> Michael makes a good point. It is not a very good practice to have
> > user
> > > >>> input in build scripts.
> > > >>>
> > > >>> Now, it is easy to create such tasks, and you can even make the
> input
> > > >>> from
> > > >>> a full GUI application if you want to using swing. But the time and
> > > >>> effort
> > > >>> to put into these tasks is not worth it for multiple reasons:
> > > >>>
> > > >>> 1- You cannot automate it
> > > >>> 2- The command prompt would have some issues because the gradle
> > status
> > > >>> bar
> > > >>> (at the bottom with progress %) might obscure it
> > > >>> 3- It is harder to test
> > > >>> 4- It blocks! now remember Gradle is a multi-process system. It can
> > > >>> execute
> > > >>> tasks in parallel increasing efficiency and throughput. What
> happens
> > if
> > > >>> you
> > > >>> mix commands together? This complicates matters
> > > >>> 5- Many other tasks require flags which did not have user input.
> Take
> > > for
> > > >>> example the data loading tasks and the integration testing tasks.
> > > >>>
> > > >>> If someone is sophisticated enough to create a new component or a
> new
> > > >>> tenant in the system I doubt they would need THAT much
> hand-holding.
> > > >>> Furthermore, everything is thoroughly documented in README.md that
> it
> > > >>> would
> > > >>> take less than a few seconds to copy paste the command and change
> the
> > > >>> flags
> > > >>> to your liking.
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Taher Alkhateeb
> > > >>>
> > > >>> On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <
> > > [hidden email] <javascript:;>
> > > >>> >
> > > >>> wrote:
> > > >>>
> > > >>> > Hi Jacques,
> > > >>> >
> > > >>> > I think builds should work without interaction on the command
> line,
> > > >>> which
> > > >>> > makes automation difficult and is less error prone.
> > > >>> >
> > > >>> > I think it is sufficient to provide the functionality with task
> > > >>> > parameters. If one wants interactive wizards, he could provide
> some
> > > >>> for the
> > > >>> > project.
> > > >>> >
> > > >>> > Regards,
> > > >>> >
> > > >>> > Michael Brohl
> > > >>> > ecomify GmbH
> > > >>> > www.ecomify.de
> > > >>> >
> > > >>> >
> > > >>> > Am 10.07.16 um 12:48 schrieb Jacques Le Roux:
> > > >>> >
> > > >>> > Hi,
> > > >>> >>
> > > >>> >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
> > > >>> >> https://issues.apache.org/jira/browse/OFBIZ-7772
> > > >>> >>
> > > >>> >> Opinions (about the question in title: "Should we?")
> > > >>> >>
> > > >>> >> Thanks
> > > >>> >>
> > > >>> >> Jacques
> > > >>> >>
> > > >>> >>
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

[Gavin Mabie-2]

Not using interactive tasks would be going against the very philosophy
behind Gradle. "Unlike the  build  file  formats  of  Ant  and  Maven,
Gradle’s  Groovy-based  build  files  allow  you to  do  general-purpose
programming  tasks  in  your  build  file.  This  relieves  much  of  the
frustration  developers  have  faced  in  lacking  control  flow  in  Ant
or  being  forced  into plug-in development in Maven to accomplish
nonstandard tasks."

Lower level build tasks may require little user interaction typically those
tasks linked to  building the system and it's components. Higher level
tasks will definitely involve user-interaction which is where Groovy comes
into the equation. In  fact,  it  makes  Gradle’s  use  of  Ant simpler
than  directly  using  Ant,  partly  by  leveraging  Groovy’s  AntBuilder
functionality. I have used Ant builder before for tasks such as:
1. Creating a charts of accounts;
2. Building a catalogue;
3. Building a webstore;
4. Building a theme.

These are some examples of build tasks that are on a higher level with less
generic application.

My 2 cents.

Gavin
On 10 Jul 2016 1:02 PM, "Jacques Le Roux" <[hidden email]>
wrote:

> Le 10/07/2016 à 12:48, Jacques Le Roux a écrit :
>
>> Hi,
>>
>> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>> https://issues.apache.org/jira/browse/OFBIZ-7772
>>
>> Opinions (about the question in title: "Should we?")
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
> This could help
> https://mrhaki.blogspot.fr/2010/09/gradle-goodness-get-user-input-values.html
>
> Jacques
>
>

[Jacques Le Roux]

Thanks Gavin,

I made some research since and came with a conclusion we should try to use https://github.com/tkruse/gradle-groovysh-plugin as recommended by Apache
Groovy team <http://www.groovy-lang.org/groovysh.html#GroovyShell-GradleGroovyshPlugin>

I'll investigate this in the context of OFBIZ-7773 and possibly OFBIZ-7793

Jacques

Le 14/07/2016 à 20:08, Gavin Mabie a écrit :

> Not using interactive tasks would be going against the very philosophy
> behind Gradle. "Unlike the  build  file  formats  of  Ant  and  Maven,
> Gradle’s  Groovy-based  build  files  allow  you to  do  general-purpose
> programming  tasks  in  your  build  file.  This  relieves  much  of  the
> frustration  developers  have  faced  in  lacking  control  flow  in  Ant
> or  being  forced  into plug-in development in Maven to accomplish
> nonstandard tasks."
>
> Lower level build tasks may require little user interaction typically those
> tasks linked to  building the system and it's components. Higher level
> tasks will definitely involve user-interaction which is where Groovy comes
> into the equation. In  fact,  it  makes  Gradle’s  use  of  Ant simpler
> than  directly  using  Ant,  partly  by  leveraging  Groovy’s  AntBuilder
> functionality. I have used Ant builder before for tasks such as:
> 1. Creating a charts of accounts;
> 2. Building a catalogue;
> 3. Building a webstore;
> 4. Building a theme.
>
> These are some examples of build tasks that are on a higher level with less
> generic application.
>
> My 2 cents.
>
> Gavin
> On 10 Jul 2016 1:02 PM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> Le 10/07/2016 à 12:48, Jacques Le Roux a écrit :
>>
>>> Hi,
>>>
>>> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>>> https://issues.apache.org/jira/browse/OFBIZ-7772
>>>
>>> Opinions (about the question in title: "Should we?")
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>> This could help
>> https://mrhaki.blogspot.fr/2010/09/gradle-goodness-get-user-input-values.html
>>
>> Jacques
>>
>>

[Gavin Mabie-2]

Will have a look at it too!

On Thu, Jul 14, 2016 at 11:07 PM, Jacques Le Roux <
[hidden email]> wrote:

> Thanks Gavin,
>
> I made some research since and came with a conclusion we should try to use
> https://github.com/tkruse/gradle-groovysh-plugin as recommended by Apache
> Groovy team <
> http://www.groovy-lang.org/groovysh.html#GroovyShell-GradleGroovyshPlugin>
>
> I'll investigate this in the context of OFBIZ-7773 and possibly OFBIZ-7793
>
> Jacques
>
>
> Le 14/07/2016 à 20:08, Gavin Mabie a écrit :
>
>> Not using interactive tasks would be going against the very philosophy
>> behind Gradle. "Unlike the  build  file  formats  of  Ant  and  Maven,
>> Gradle’s  Groovy-based  build  files  allow  you to  do  general-purpose
>> programming  tasks  in  your  build  file.  This  relieves  much  of  the
>> frustration  developers  have  faced  in  lacking  control  flow  in  Ant
>> or  being  forced  into plug-in development in Maven to accomplish
>> nonstandard tasks."
>>
>> Lower level build tasks may require little user interaction typically
>> those
>> tasks linked to  building the system and it's components. Higher level
>> tasks will definitely involve user-interaction which is where Groovy comes
>> into the equation. In  fact,  it  makes  Gradle’s  use  of  Ant simpler
>> than  directly  using  Ant,  partly  by  leveraging  Groovy’s  AntBuilder
>> functionality. I have used Ant builder before for tasks such as:
>> 1. Creating a charts of accounts;
>> 2. Building a catalogue;
>> 3. Building a webstore;
>> 4. Building a theme.
>>
>> These are some examples of build tasks that are on a higher level with
>> less
>> generic application.
>>
>> My 2 cents.
>>
>> Gavin
>> On 10 Jul 2016 1:02 PM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>> Le 10/07/2016 à 12:48, Jacques Le Roux a écrit :
>>>
>>> Hi,
>>>>
>>>> See https://issues.apache.org/jira/browse/OFBIZ-7773 and
>>>> https://issues.apache.org/jira/browse/OFBIZ-7772
>>>>
>>>> Opinions (about the question in title: "Should we?")
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> This could help
>>>
>>> https://mrhaki.blogspot.fr/2010/09/gradle-goodness-get-user-input-values.html
>>>
>>> Jacques
>>>
>>>
>>>
>