Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Článek přináší doporučení (včetně kompletního kompilovatelného příkladu), jak navrhnout antovské skripty v případě složitějších projektů obsahujících více výsledných produktů provozovaných v různých konfiguracích, na kterých pracuje více vývojářů.
Už se vám stalo, že jste si stáhli zdrojovou verzi nějakého populárního open-source produktu v Javě a po hodině marných pokusů o kompilaci jste to nakonec vzdali? Klíčem k tomu, abyste jako autoři ušetřili svým uživatelům podobné rozčarování, je návrh robustního build systému.
Motivací k napsání tohoto článku je autorova zkušenost, že se nevyplácí šetřit čas na vytvoření kvalitního build systému. Tím spíše, pokud je součástí buildu také instalace zahrnující potenciálně nebezpečné operace, jako třeba vymazání databázových tabulek. Myslete na to, že kompilovat projekt mohou kromě vás také jiní programátoři nebo správci systému. Ušetřený čas na ledabyle odvedeném návrhu se vždy i s úroky zaplatí v pozdější fázi projektu. A to zrovna když se vám to bude nejméně hodit - když se něco stane nezvladatelným a je nutné provést refactoring (což v případě, že nejste autorem, může být krajně nevděčná práce).
Obvykle výsledný produkt projektu obsahuje různé konfigurační soubory, moduly či data, které společně tvoří uníkátní konfiguraci. Záleží to na typu projektu a zvolené architektuře, ale nejčastěji to bude databázový driver, URL databázového připojení a nastavení úrovně logování. Pokud vytváříte k serverové aplikaci síťového GUI klienta (nejlépe s využitím JNLP a Java Web Start technologie), který komunikuje s aplikačním serverem, potřebuje klient znát IP adresu a nastavení poskytovatele adresářových služeb JNDI, se kterým se připojí ke komponentám nebo frontám aplikačního serveru.
Díky dynamické povaze Javy mohou být dnešní systémy za běhu vysoce parametrizovatelné. Všechno je "pluggable" a "customizable". Pokud jste někdy procházeli konfiguračními XML soubory aplikačního serveru JBoss nebo XML soubory s deskriptory J2EE aplikace, tak víte, co to je za monstra. Nic proti tomu. Špatné však je, když je tím zbytečně zatěžován koncový uživatel, byť by to byl programátor.
Technologie Java Web Start umožňuje pouhým otevřením odkazu v HTML stránce nainstalovat a bezpečně spustit plnohodnotnou desktopovou aplikaci. (Stáhne potřebné knihovny na disk a se svolením uživatele vytvoří na ploše a v nabídce programů zástupce pro spuštění. Při dalším spouštění pak ověřuje, zda na webu není novější verze a pokud ano, tak ji automaticky aktualizuje a spustí. To vše bez zásahu uživatele.) Pokud chceme s pomocí této technologie vytvořit naprosto bezúdržbovou aplikaci, musí být veškerá nastavení přibalena k jar souborům aplikace během buildu.
Cíl je tedy jasný: pokud se rozhodnu vydat novou verzi, tak jediné, co si
přeji udělat, je na své vývojářské stanici spustit z příkazového
řádku povel ant deploy
. Nic víc. Tečka. Žádné ruční balení,
kopírování, žadná editace konfiguračních souborů, žádné opětovné
konfigurování reinstalovaných produktů před či po spuštění.
Ant přímo vybízí k vytvoření alespoň minimální dokumentace k buildu, která má pro toho, kdo si projekt stáhne a bude kompilovat, naprosto zásadní význam. Dokumentace k build skriptu se zobrazí pomocí povelu:
ant -projecthelp
|
Výsledkem může být např. tento jednoduchý výstup:
Buildfile: build.xml
|
Vytvoření výše uvedené dokumentace je velmi snadné. Prvních pár řádků
s obecnou informací o projektu se vytvoří ve skriptu pomocí XML značky
description
umístěné na počátku pod kořenovou značkou
project
:
<project name="AbcKlient" default="package" basedir=".">
|
V seznamu cílů se popis cíle vyskytne tehdy, obsahuje-li značka
target
příslušného cíle atribut description
:
<target name="deploy" |
Open source projekty používající Ant konvergovaly časem k určité formě strukturování a pojmenování cílů (targets) ve skriptech. Pokud můžete, držte se těchto osvědčených konvencí. Všichni, kdo budou váš skript spouštět, vám budou vděčni, když se bude skript chovat tak, jak jsou zvyklí.
K standardním cílům by měl patřit cíl package
, který
vytvoří hotový zabalený produkt obsahující veškeré knihovny,
spouštěcí skripty apod. Pro testování je ideální, pokud je takto
zabalený produkt bez další instalace přímo spustitelný.
Jiným často používaným cílem bude cíl deploy
, který
provádí instalaci produktu, ať již na aplikační server v případě J2EE
aplikace nebo web server v případě JNLP klienta.
Hlavní zásada zní: adresář src
obsahující zdrojové
kódy je nedotknutelný. Soubory vyžadující konkrétní nastavení
(IP adresy, URL a různé další konstanty) by měly být vytvořeny
ve formě šablon obsahujících proměnné, které se teprve v průběhu buildu
nahradí konkrétními hodnotami.
Podobně jako zdrojové kódy by měl být nedotknutelný také build skript.
Ant umožňuje nastavovat hodnoty proměnných několika způsoby.
Buď je to značkou <property name="..." value="...">
nebo textovým souborem s obsahem definovaných hodnot pomocí značky
<property file="..." />
. Přesuňte do textových
souborů právě ty hodnoty, které očekáváte, že uživatel může měnit,
a okomentujte jejich význam. Používáte-li např. jiný typ kompilátoru
než je obvyklé (třeba jikes), přesuňte typ kompilátoru jako
parametr do externího souboru. Zkrátka, ve skriptu nemají co dělat
nastavení závislá na vašem systému.
Pro konkrétní nastavení je dobré vytvořit v projektovém adresáři
podadresář conf
, který bude obsahovat konfigurační
profily s hodnotami nastavení pro jednotlivá cílová prostředí.
Jednotlivé konfigurační profily se pak přepínají pomocí jediného
řádku v souboru build.properties
v hlavním adresáři
projektu. Podrobně si tuto techniku vysvětlíme v další části
článku.
Ačkoliv lze více podprojektů organizovat pomocí jediné hierarchie adresářů zdrojových kódů tříd a jediným sdíleným adresářem společných knihoven, nelze tento postup pro komplexnější projekty doporučit. Brzy totiž ztratíte přehled, které knihovny potřebuje ten který podprojekt a údržba build skriptu se záhy stane noční můrou.
Z dlouhodobého hlediska je výhodnější, když má každý podprojekt svůj adresář knihoven, zdrojových kódů a svůj vlastní build skript. Zkrátka, je co nejvíc izolován od zbytku projektu. Jistou nevýhodou může být skutečnost, že některé společné knihovny jsou na více místech v projektovém adresáři, ale v praxi je tato nevýhoda spíše zanedbatelná.
Pokud má každý podprojekt svůj build skript, je žádoucí vytvořit hlavní build skript, který zajistí hromadné vykonání skriptů jednotlivých podprojektů.
V ideálním případě je izolace projektu dotažena až tak daleko, že projekt obsahuje vlastní kopii Antu. Jelikož se Ant neustále vyvíjí, nenastane situace, že projekt vyžaduje jinou verzi Antu, než máte v systému.
V dnešní části jsme si vysvětlili zásady, které je dobré dodržovat pro robustní návrh build systému. V další části článku se podíváme na reálný příklad build skriptů, které ilustrují, jak tyto zásady použít.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: