title: What's the best choice between tasks or methods to organize your Gradle build logic?
body: <p>I'm currently <strong>migrating some old huge Maven 1 script to Gradle</strong>.
  As a consequence, I need to adapt the old Maven 1 / Ant &amp; its goals logic to Gradle.</p>
  
  <p>After having read the Gradle User Guide, and some articles on Gradle tasks and methods, <strong>I am quite confused about the way to write my script</strong>.</p>
  
  <p>In the official <a href="https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#N101A9" rel="nofollow noreferrer">Gradle User Guide, §6.1</a>, it is explained that a <strong>Gradle task</strong>:</p>
  
  <blockquote>
    <p>represents some <strong>atomic piece of work</strong> which a build performs</p>
  </blockquote>
  
  <p>In <a href="https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#N1034A" rel="nofollow noreferrer">§6.11</a>, it is also explained that we can use <strong>methods to organize our build logic</strong>.</p>
  
  <p>So, my question is: <strong>what's the correct way to use each of them?</strong></p>
  
  <p>I am creating a build script so, <strong>in my opinion</strong>:</p>
  
  <ul>
  <li><strong>tasks should only be what the user is allowed to see</strong>, and so, to call through the command line.<br>
  By example <code>gradle doSomeInternalTechnicalWork</code> is not correct for me, as the user should even not know that <code>doSomeInternalTechnicalWork</code> exists.<br>
  Always in my opinion, it should <strong>NOT</strong> be a task.</li>
  <li><strong>method should be used to organize the build logic, and should NOT be visible by the user</strong></li>
  </ul>
  
  <p>With the former logic, <strong>I encounter problems when my methods need to call Gradle tasks</strong> (like the JAR creation of the Java plugin).</p>
  
  <p>I know that <a href="https://stackoverflow.com/questions/18204077/can-i-call-a-gradle-task-from-a-groovy-method-in-a-gradle-file">I should not call task from task</a> (and so the same for task from method), but, have a look to this example:</p>
  
  <pre><code>task independentTask &lt;&lt; {
  
     // initialization stuff 
     println "doing a lot of initialization" 
  
     // using methods to organize build logic, good or not?
     doComplexThingsThatTheUserShouldNeverDoHimself()
     }
  
  task dependentTask(dependsOn: 'independentTask') &lt;&lt; { 
     println "now that 'independentTask' is done, I can continue to do complex things..." 
     }
  
  void doComplexThingsThatTheUserShouldNeverDoHimself() {
     println "doing really complex things"
  
     // I really need to create my JAR here and not somewhere else
     // And I know it's not a good thing to directly call the Action.execute
     jar.execute()
  
     println "doing other really complex things"
  }
  </code></pre>
  
  <p>In this case, <strong>what would be a correct build logic?</strong> </p>
  
  <p>Should <code>doComplexThingsThatTheUserShouldNeverDoHimself</code> be converted in 1 or more tasks, so as to be able to <code>dependsOn</code> the JAR task?<br>
  But that would mean to have really a lot of tasks, callable by the user, when, indeed, that should not be the case.</p>