Přejít k navigační liště

Zdroják » Různé » Gradle tutorial: tasky

Gradle tutorial: tasky

Články Různé

Vítejte u druhého dílu tutorialu o automatizačním nástroji Gradle. Filozoficko-marketingovou masáž jsme si odbyli v minulém článku, takže je čas si vyhrnout rukávy: let’s get our hands dirty!

Tři informace na úvod

Asi nejdůležitější informací je: co by mělo být přínosem tohoto tutorialu? Gradle má velmi pěknou dokumentaci (User GuideDSL ReferenceJavadoc/Groovydoc), tak proč psát ještě tutorial? Důvody jsou dva. Jednak dokumentace ne vždy pomůže při řešení praktických věcí – dotazů je plný Stack Overflow, a jednak některé věci nejsou úplně ve stavu, v jakém bych je chtěl používat. Jako příklad můžu uvést Jetty: Gradle obsahuje out-of-the-box Jetty plugin, který ale používá Jetty ve verzi 6. Což je verze, která je deprecated. Pokud tedy chci používat nějakou stable verzi (7-9), musím to udělat jinak. Tutorial by tedy měl řešit praktické věci v aktuálních verzích použitých nástrojů.

Druhou informací je scope tutorialu. Ten by měl odpovídat mojí přednášce na SlideShare, plus něco navíc. Základní zaměření odpovídá mým potřebám, tedy na co Gradle používám já. Pokud byste si rádi přečetli o nějakých dalších tématech, dejte mi vědět v komentářích – rád tutorial přizpůsobím vašim potřebám. Tutorial by měl zahrnovat hlavně Java vývoj: tj. Java, unit testy, web, metriky kódu, multi projekty, kontinuální integraci, integraci s Antem. Finále by obstaral jednoduchý, ale reálný projekt – webová služba postavená na JAX-WS.

Bitbucket logo bluePoslední informace je praktická. Ke každému dílu budou k dispozici zdrojové kódy build skriptů, které budu postupně publikovat na Bitbucketu. Zdrojové kódy v repozitáři budou obohacené o komentáře, takže budou (doufám) použitelné i samostatně.

Bitbucket je Mercurial (a Git) hosting, který funguje obdobně jako známější GitHub. Že jsem zvolil Mercurial a ne třeba populárnější Git je, dejme tomu, srdcová záležitost. (A pak, toho Gitu už je všude trochu moc ;-)

Instalace a verze Gradlu

Instalace Gradlu je jednoduchá ve stylu stáhnout-rozbalit-přidat bin do PATH-spustit. Prerekvizitou je JDK 1.5+. Pro přesný postup vás odkážu na stránky dokumentace: Installing Gradle. Funkčnost instalace ověříme příkazem gradle -v.

Gradle version

Verze Gradlu

V rámci tutorialu budu používat verzi 1.7 z nočního buildu. Předpokládám, že tutorial bude zdrojem informací i v budoucnu, ne jenom v čase publikování, tak si chci podržet iluzi, že takto vydrží být aktuální alespoň o něco déle. Může se sice stát, že některé funkčnosti, které popisuji, se mohou ve stabilních releasech chovat trochu jinak (např. výstupy na konzoli), nicméně většina příkladů byla původně vyvinuta pro (stable) verzi 1.5 a ve verzi z nočního buildu funguje bez úprav, takže nepředpokládám problémy :-)

Pokud byste u příkladů narazili na nekompatibilitu mezi verzemi, dejte mi, prosím, vědět v komentářích.

Projekty a tasky

Dva základní koncepty, na kterých jsou Gradle build skripty postaveny, jsou projekt a task. Koncept projektu by nám měl být familiární, např. z IDE. Zjednodušeně, projekt představuje nějaký komponent, který potřebujeme sestavit: JAR/WAR/EAR/ZIP archiv apod. Projekt je prezentován souborem build.gradle v root adresáři projektu.

Gradle project

Definice Gradle projektu (projekt 00_HelloWorld)

Projekt definuje související množinu taskůTask je atomická jednotka práce, kterou můžeme spustit v rámci buildu. Každý task může obsahovat množinu akcí. Akce už je nějaká konrétní věc, kterou chceme provést: výpis na konzoli, přesun souboru, kompilace, spuštění jiného tasku atd.

Hello, world!

Nevím, jak vy, ale já když se učím něco nového (jazyk, framework, nástroj), tak si vždycky rád napíšu Hello world. Jak vypadá Hello world v Gradlu?

task hello << {
    println 'Hello, Gradle!'
}

Příklad spustíme příkazem

gradle hello

Výstup by měl vypadat nějak takhle:

Gradle Hello world

Výstup tasku hello

Výstup je možná trochu ukecaný – kromě výpisu našeho textu je tam label daného tasku (:hello) a informace o úspěšnosti vykonání tasku. Pokud chceme kompaktnější výstup, můžeme spustit task s přepínačem -q. Gradle pak vypisuje (ve skutečnosti loguje) pouze to, co jsme poslali na standardní výstup (println) a zprávy se severitou error.

gradle hello -q

Zrojový kód na Bitbucketu: 00_HelloWorld/build.gradle

Jaké tasky jsou k dispozici?

Nejčastějším uživatelem Gradlu bude vývojář. Ale může se taky stát, že ho bude spouštět tester, nebo analytik, nebo… (nedejbože ;-) projekťák či slečna asistentka. Pamatujete? Automatizace.

Tyto ostatní role se asi nebudou chtít vrtat v kódu build skriptu, aby zjistily, co že to má dělat apod. Jako dělaný speciálně pro ně je příkaz gradle tasks, který vypíše seznam tasků, které jsou k dispozici.

Gradle tasks

Výpis tasků

V závislosti na verzi Gradlu se výpis může lišit. Pokud nevidíte nějaký task, který byste vidět měli, zkuste příkaz spustit s přepínačem --all:

gradle tasks --all

Gradle GUI

Graficky orientovaní jedinci možná ocení práci s grafickou verzí Gradlu, která se spouští příkazem gradle --gui. Zde je také vidět přehled tasků. Ty se navíc dají rovnou spouštět, je vidět jejich výpis na konzoli atd.

Gradle gui

Gradle GUI

Syntaxe tasku

Nejčastěji se budeme setkávat s definicí tasku, která byla uvedena v příkladu Hello world, čili:

task myList << {
    println 'middle point'
}

Na této syntaxi je nejzajímavější operátor <<, který je aliasem pro metodu doLast. Stejný výsledek dostaneme zápisem:

task myList {
    doLast {
        println 'middle point'
    }
}

Když máme metodu doLast, tak nepřekvapí, že máme i obdobnou doFirst. K čemu tyto metody slouží? Umožňují nám „dekorovat“ již definovaný task – metoda doFirst přidává nové akce na začátek seznamu akcí a metoda doLast dělá totéž na konci seznamu akcí daného tasku. Každý task tedy můžeme postupně rozvíjet a obohacovat jeho chování. V jednoduchém build skriptu to asi nebude potřeba, ale v hierarchii skriptů (multi project) už to může být zajímavé.

task myList << {
    println 'middle point'
}

myList {
    doLast {
        println 'last point'
    }
}

myList {
    doFirst {
        println 'first point'
    }
}
Výstup "dekorovaného" tasku myList

Výstup „dekorovaného“ tasku myList

Zdrojový kód na Bitbucketu: 01_Tasks/build.gradle

Zdrojové kódy

Zdrojové kódy k dnešnímu dílu jsou k dispozici na Bitbucketu. Můžete si je tam buď probrouzdat, stáhnout jako ZIP archiv, anebo – pokud jste cool hakeři jako já :-) – naklonovat Mercurialem:

hg clone ssh://hg@bitbucket.org/sw-samuraj/gradle-tutorial

Co nás čeká příště?

Protože tasky jsou pro Gradle stěžejním konceptem, budu se jim věnovat i v příštím díle. Tři hlavní okruhy by měly být:

  • závislosti mezi tasky,
  • dynamické generování tasků – task rules
  • a „běžné“ problémy, se kterými se můžeme při definici tasků setkat.

Související

Jak zabezpečit WordPress: Praktický průvodce

WordPress pohání přes 40 % všech webů na světě. To z něj dělá nejrozšířenější CMS a zároveň nejčastější terč automatizovaných útoků. Boti nepotřebují cílit přímo na vás: systematicky procházejí miliony domén a hledají otevřené dveře. Stačí zapomenutý plugin bez aktualizace, výchozí prefix databáze nebo heslo z uniklé databáze. Tento článek není seznam pluginů. Je to průvodce od základů přes hardening konfigurace až po serverové zabezpečení s konkrétními kroky, které můžete udělat ještě dnes.

Product Engineer: supermani, nebo falešná efektivita?

Stále více firem propouští produktové týmy a sází na jednu roli, která to zvládne celé sama. Product Engineer je člověk, který vymyslí produkt, implementuje ho a vyhodnotí výsledky. S ekosystémem AI agentů místo kolegů. Efektivita? Na první pohled určitě. Ale je rozdíl mezi tím dodávat víc a rychleji a skutečně být efektivní. Tenhle rozdíl firmy zatím moc neřeší.

EU AI Act: co musí vývojářské týmy vědět do 2. srpna 2026

Druhého srpna začnou v EU platit povinnosti pro poskytovatele i provozovatele high-risk AI systémů: posouzení shody, technická dokumentace a quality management na straně providerů, uchovávání logů a dohled nad provozem na straně deployerů. Samostatně vstupují v platnost transparentní pravidla pro chatboty, generativní AI a deepfaky, a ta se týkají všech, nejen high-risk systémů. Kdo nasazuje AI v recruitmentu, credit scoringu nebo HR hodnocení, je v zóně. Čekání na odklad přes Digital Omnibus je sázka na legislativní proces, který ještě neskončil. A kdo si myslí, že se ho to netýká, protože „jen používá ChatGPT" v use casu z Annexu III, pravděpodobně špatně přečetl nařízení.