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 <[email protected]
> 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" <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> > > 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 <
> > >> [email protected]> 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 <
> > [email protected]
> > >>> >
> > >>> 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
> > >>> >>
> > >>> >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Reply via email to