[DISCUSSION] Configuring Gradle using an external script

[Jacques Le Roux]

Hi  Michael, All,

I don't know if you remember this conversation we had in HipChat

Tuesday September 20, 2016 (only relevant parts)

[10:32 AM] Michael Brohl: maybe we could  have an include mechanism here to specify additional repositories in another gradle file without changing
the main build file? Just an idea.
[10:36 AM] Pierre Smits: @MichaelBrohl That is a excellent idea.
[10:36 AM] Pierre Smits: It requires nothing ground-breaking. :)
[10:37 AM] Pierre Smits: Just add a line to the OOTB provided build.gradle that enables adopters to add their special purpose tasks to an extension.
[10:41 AM] Jacques Le Roux: Makes sense Michael
[10:42 AM] Pierre Smits: And a similar thing can be done for being able to use special purpose ant tasks.
[10:42 AM] Pierre Smits: That way we help existing adopters in their migration paths...
[9:08 PM] Jacques Le Roux: @MichaelBrohl, @PierreSmits about disentangling new repos AND possibly have (a) hook/s from main gradle.build for external
scripts (being Gradle builds or what else) did you create Jiras or should we discuss that in dev ML? @TaherAlkhateeb what do you think about these ideas?
[9:24 PM] Pierre Smits: I have already made some suggestions in a jira.
[10:01 PM] Pierre Smits: And elsewhere.

I'd like to go further with this. I suggest we should include external scripts following
https://docs.gradle.org/current/userguide/userguide_single.html#sec%3aconfiguring_using_external_script

We could have one for additional repositories and for other reasons anyway "You can even apply other scripts from the external script.".
The idea is you don't have to patch your main custom build.gradle script to add a repository or other aspects

Having external scripts as hooks would help adopters, OOTB those external scripts would not exist or be empty (did not check if presence is necessary).

Jacques

[Jacopo Cappellato-5]

Hi Jacques,

On Fri, Sep 30, 2016 at 10:44 AM, Jacques Le Roux <
[hidden email]> wrote:

> ...
> I'd like to go further with this. I suggest we should include external
> scripts following https://docs.gradle.org/curren
> t/userguide/userguide_single.html#sec%3aconfiguring_using_external_script
>
> We could have one for additional repositories and for other reasons anyway
> "You can even apply other scripts from the external script.".
>

+1 to the proposal ("apply from:"): we could even parse all the *.gradle
files in a given folder.

Jacopo

[Pierre Smits]

It would surely help existing adopters who have invested in getting their
implementations suited to their requirements. If the project wants to
facilitate a smooth migration of their implementations based on older
releases (latest 13.07.03), then it can help with integration of:


   - the line 'ant.importBuild 'build.xml' to the build.gradle file
   - adding a skeleton build.xml file for ANT that is ignored by version
   control

Only the 'ant.importBuild 'build.xml' added to the build.gradle file is not
enough, as the build process will fail due to the missing build.xml for ANT.
Having the skeleton build.xml in the code base allows existing adopters to
keep using their ant tasks with minimal migration/upgrade effort. Also,
having it ignored by version control will ensure that changes made to that
build.xml (e.g. copy/past of tasks from the old release implementation)
won't revert back to the vcm

Similarly, adding a reference in build.gradle and a skeleton file for
adopter/implementation specific gradle tasks, eases the ability of adopters
(and trunk testers) to extend the gradle tasks controlled by the project.

Best regards

Pierre Smits

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

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

On Fri, Sep 30, 2016 at 11:00 AM, Jacopo Cappellato <
[hidden email]> wrote:

> Hi Jacques,
>
> On Fri, Sep 30, 2016 at 10:44 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > ...
> > I'd like to go further with this. I suggest we should include external
> > scripts following https://docs.gradle.org/curren
> > t/userguide/userguide_single.html#sec%3aconfiguring_using_
> external_script
> >
> > We could have one for additional repositories and for other reasons
> anyway
> > "You can even apply other scripts from the external script.".
> >
>
> +1 to the proposal ("apply from:"): we could even parse all the *.gradle
> files in a given folder.
>
> Jacopo
>

[taher]

The feature set and exact details of how to extend Gradle are not clear to
me in this Thread. The quoted text from Michael indicates extending
existing repositories, Pierre on the other hand wants build.xml to be
included to run ant scripts that exist in his environment,

We need to discuss first of all the _reason_ for this extension mechanism.
In our current setup, every single component (and its parent directory) is
a gradle subproject (optional). So you can execute whatever you want in
your own component's build.gradle without patching the main build.gradle

Without a clear scenario / example of why / how exactly would this
extension mechanism help I don't think we should push anything to the code
base. In the case Pierre mentioned I think it's a bad idea, here is why:
- He has an build.xml file with certain targets. Some other users might
have targets that conflict with tasks defined in Gradle. How do you resolve
that? Well in Gradle you can rename ant targets. But then how do we rename
them? Can we agree on a naming convention? (append -ant perhaps).
- Extending gradle with a specific file name is not idea because each user
would have his/her own naming conventions. Perhaps Jacopo's suggestion is a
good step of applying a regex pattern to files that can be extended.
- Subprojects are a prime location for adding dependencies or custom logic.
So extending the main build file directly means you want to do something
specific, what is it? and is it beneficial to the community?

Hence, before attempting any changes, clear steps on the how and why should
be discussed here first, and I did not yet observe the how and why in this
thread.

On Sat, Oct 1, 2016 at 10:40 AM, Pierre Smits <[hidden email]>
wrote:

> It would surely help existing adopters who have invested in getting their
> implementations suited to their requirements. If the project wants to
> facilitate a smooth migration of their implementations based on older
> releases (latest 13.07.03), then it can help with integration of:
>
>
>    - the line 'ant.importBuild 'build.xml' to the build.gradle file
>    - adding a skeleton build.xml file for ANT that is ignored by version
>    control
>
> Only the 'ant.importBuild 'build.xml' added to the build.gradle file is not
> enough, as the build process will fail due to the missing build.xml for
> ANT.
> Having the skeleton build.xml in the code base allows existing adopters to
> keep using their ant tasks with minimal migration/upgrade effort. Also,
> having it ignored by version control will ensure that changes made to that
> build.xml (e.g. copy/past of tasks from the old release implementation)
> won't revert back to the vcm
>
> Similarly, adding a reference in build.gradle and a skeleton file for
> adopter/implementation specific gradle tasks, eases the ability of adopters
> (and trunk testers) to extend the gradle tasks controlled by the project.
>
> Best regards
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Sep 30, 2016 at 11:00 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
> > Hi Jacques,
> >
> > On Fri, Sep 30, 2016 at 10:44 AM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > ...
> > > I'd like to go further with this. I suggest we should include external
> > > scripts following https://docs.gradle.org/curren
> > > t/userguide/userguide_single.html#sec%3aconfiguring_using_
> > external_script
> > >
> > > We could have one for additional repositories and for other reasons
> > anyway
> > > "You can even apply other scripts from the external script.".
> > >
> >
> > +1 to the proposal ("apply from:"): we could even parse all the *.gradle
> > files in a given folder.
> >
> > Jacopo
> >
>