Implement and configure Gradle Build

I read on Gradle and am very interested in this, especially because (it seems) that it allows you to introduce inheritance into the build process. For example, if I have a Java web application that can be packaged and deployed on instances of Google App Engine, as well as instances of Amazon EC2, I need a complex assembly that can accept the same files and package Java, XML, PROPERTIES, CSS and images / deploy them in 2 files with WAR tight packaging in different ways.

GAE applications are very specific about how they are packaged; EC2 (to a large extent) just requires that you meet servlet specifications. GAE applications are "deployed" by running the update command from the appcfg.sh script that comes with your SDK; EC2 has its own way to deploy applications. The fact is that they are very different packaging / deployment processes for both PaaS providers:

 public abstract class PackageTask { // ... } // Package my Eclipse project for deployment to GAE. public class AppEnginePackageTask extends PackageTask { // ... } // Package my Eclipse project for deployment to EC2 instances. public class AmazonPackageTask extends PackageTask { // ... } public abstract class DeployTask { // ... } // Deployment to GAE. public class AppEngineDeployTask extends DeployTask { // ... } // Deployment to EC2. public class AmazonDeployTask extends DeployTask { // ... } 

Then I can have the myapp.gradle assembly myapp.gradle , which forms the assembly order of tasks:

 clean() compile() package() deploy() 

... and somehow I can configure / insert AppEnginePackageTask / AppEngineDeployTask instead of package() / deploy() for a GAE-based build, or I can configure / insert AmazonPackageTask / AmazoneDeployTask in those template tasks. Again, I'm not sure how to do this (or even if Gradle can do this), but this is what I need.

I realized that Gradle can do this. Ants may also be forced to have highly modular, elegant assemblies that work this way, but based on XML, this requires some refinement, while an OOP-based language like Groovy makes it cleaner and simpler.

However, all the examples that I see in Gradle tasks are as follows:

 task package(dependsOn: 'compile') { // ... } task deploy(dependsOn: 'package') { // ... } 

So, I ask: these views look like definitions other than OOP. Is my understanding of Gradle (and its nature of OOP) fundamentally wrong? What am I missing here? How can I fulfill these concepts of β€œcustom / injectable assembly templates” and inheritance tasks? Thanks in advance!

Change I re-tagged this question with " groovy " because Gradle buildscripts are written in Groovy DSL, and whoever turned out to be Groovy -guru (say 5 times faster) may also be able to call back even if they know little About Gradle.

+6
source share
1 answer

As described here , there are simple tasks and advanced tasks. The latter are much more flexible and powerful.

The following example is not exactly what you are describing, re: injection, but it illustrates OOP.

Here is an example build.gradle file. He avoids the β€œpackage” as it is a keyword in Java / Groovy. The purpose of the "build" depends on the "compilation" and some smell of "doPack", depending on the "pkgTarget" property.

 task compile << { println "compiling..." } task build() << { } build.dependsOn { compile } build.dependsOn { if (pkgTarget == "Amazon") { task doPack(type: AmazonPackageTask) } else if (pkgTarget == "Google") { task doPack(type: GooglePackageTask) } else { task doPack(type: MyPackageTask) } } 

where tasks are defined later in the same file. (Per doc, this code may go into the "build src" directory):

 // ----- class MyPackageTask extends DefaultTask { def init() { println 'common stuff' } @TaskAction def doPackage() { println 'hello from MyPackageTask' } } class AmazonPackageTask extends MyPackageTask { @TaskAction def doPackage() { init() println 'hello from AmazonPackageTask' } } class GooglePackageTask extends MyPackageTask { @TaskAction def doPackage() { init() println 'hello from GooglePackageTask' } } 

and here is the gradle.properties file:

 pkgTarget=Amazon 
+3
source

Source: https://habr.com/ru/post/924885/


All Articles