V tom případě to lepší než pip nebude pokud bych měl dependencies rešit ručně. Dobře, takže za použítí Mavenu/Gradlu nebo nějakého Java IDE musím zkompilovat zdrojáky AWS-SDK-JAVA a vytvořit jarko a to naimportuju do mého projektu. To chápu.
Nikoli. Máte váš Javovský projekt založený na Gradle (nebo Mavenu,když se chcete trápit :-). Do otoh projektu si přidáte závislost na AWS SDK – jak na to máte popsané na té odkazované stránce
https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/setup-install.html#include-sdk Zajímá vás jen ten krátký odstavec s výběrem mezi Maven a Gradle. Ta část „Compiling the SDK“ už se vás netýká, ta je pro případ, kdy byste SDK chtěl kompilovat ze zdrojáků.
Přidáním té závislosti do Gradle nebo Mavenu se stáhne příslušné JARko (přeložený Java kód)z Maven repository, stejně tak se stáhnou případné závislosti. IDE si to JARko proleze, zaindexuje a na základě toho pak napovídá. Nápověda může být zkompilovaná v samostatném JARku, pokud je k dispozici, IE si ho stáhne také a pak vám přímo v IDE může zobrazovat i tu nápovědu. To je ale nad rámec našeptávání – je to člověkem psaná dokumentace metod, parametrů apod.
Takže o našeptávání se bude starat přímo to zkompilované jarko, které si nějak poradí s těmi JSON soubory (které popisují operace, které daná AWS služba podporuje)?
V tom statickém JARku už jsou nadefinované třídy, které můžete použít – podle nich IDE napovídá. O převod z JSON souborů do těch tříd už se musel postarat autor toho JARka.
Takže mně bude našeptávání fungovat, až když pomocí mavenu vybuildím dokumentaci? Jsem zmaten
Našeptávání funguje rovnou na základě kódu (ať zdrojového nebo zkompilovaného v class souborech).
Uff, tam je potřeba programovat i ruční aktualizaci AWS SDK? Tam není nějaký jednoduchý příkaz jako v pip, např. "maven/gradl -upgrade aws-sdk-java"?
Takovýhle příkaz tam není. Rozdíl je totiž v tom, že v případě pipu si stáhnete ten balíček lokálně a dál pracujete s ním. A to
pip -upgrade vám prostě přepíše ty soubory na souborovém systému. Maven i Gradle ale fungují tak, že jenom řeknete, jaký balíček se má používat – a zbytek už je starost buildovacího systému (případně IDE). On to nakonec také stáhne někam na disk, ale to se děje na pozadí. Hlavně ale ta deklarace závislosti nemusí být tak jednoduchá – může být podmíněná, nemusí tam být uvedená verze natvrdo ale nepřímo třeba pomocí proměnné. Takže příkaz pro aktualizaci závislosti by často nevěděl, co má kde upravit, aby se ve výsledku změnila ta verze závislosti.
On to ale většinou nebývá problém, vydávání nové verze každý den je specialita Amazonu…
Maven i Gradle jsou v tomhle flexibilnější, nemožnost udělat takhle jednoduše upgrade je daň za tu flexibilitu. Třeba můžete mít firemní bezpečnostní tým, který bude nové verze knihoven auditovat. Tím pádem nebude chtít brát nové verze z internetu, ale z toho auditu. Maven i Gradle vám to umožní. V Gradle napíšete skript na pár řádek, v Mavenu vytáhnete čísla verzí do nějakého externího souboru, který budete aktualizovat něčím jiným, než Mavenem (nebo do Mavenu napíšete plugin).
Je to example pro sqs, ale co kdybych chtěl používat jinou službu (sns, s3, ...). To musím pokaždé ručně upravovat <dependencies> v souboru pom.xml?
Ano. Ale IntelliJ Idea k tomu zase hezky napovídá, případně když chcete použít třídu z balíčku, který nemáte v závislostech, sama nabídne to přidání do závislostí. Je to stejné, jako kdybyste upravoval
packages.json pro NPM. Osobně mi ta editace souboru připadá lepší, než přidávat závislosti přes příkazovou řádku – v tom souboru rovnou vidím, jaké další závislosti tam mám, takže třeba rovnou vidím, že už tam mám jinou knihovnu ze stejného projektu, tak se postarám o to, abych je měl ve stejných verzích.