Maven repozitář v projektu – proč a jak

Přestože je javovská část programátorského světa plná open-sourcu občas není zbytí a je třeba použít nějaký closed-souce. Tedy knihovny buď placené a nebo knihovny objashující pomocné třídy pro API k nějakému magickému a tedy i velmi drahému produktu. Takové knihovny nelze přirozeně stahnout z žádného veřejného maven repozitáře.
Tuším, co si teď asi říkáte. Každá, i menší firma, používá pro své maven projekty nějaký Repository Manager. Ve velkých korporacích jste ale často rádi, že můžete používat maven. O nexusu a nebo artifactory si můžete nechat jen zdát. Jak tedy takovouto závislost do projektu dostat a zajistit tak, že kodokoliv bude projekt buildit bude mít k dispozici všechny knihovny? Pro tento účel jsem oběvil kouzlo “projektového repozitáře”. Tedy maven repozitáře přímo v projektu. Tak tedy konkrétně. Mám knihovnu my-expensive-library.jar, na které chci aby můj projekt závisel.
1. Vytvořím v projektu (${project.basedir}) repozitář.
Vytvořím složku ${project.basedir}/lib
2. Do pom.xml přídám nový repozitář
<repositories> <repository> <id>local-project-libraries</id> <name>Local project libraries</name> <url>file://${project.basedir}/lib</url> <layout>default</layout> </repository> </repositories>
3. Přidám závislost do pom.xml
<dependencies> <dependency> <groupId>com.magiccompany</groupId> <artifactId>old-stuff</artifactId> <version>1.0</version> </dependency> </dependencies>
4. Do projektové repozitáře nasadím my-expansive-library.jar
mvn deploy:deploy-file-DgroupId=com.magiccompany -DartifactId=my-expensive-library -Dversion=1.0′ -Dpackaging=jar -Dfile=peth/to/my-expensive-library.jar -Durl=file://${project.basedir}/lib -DrepositoryId=local-project-librariesPo těchto čtyřech jednoduchých krocích máte dependenci přímo v projektu. Nevýhodou ovšem je, že musíte mít closed-souce knihovny v SCM. To se projeví zejména, když máte více projektů, které mají na knihovnách záviset. “Projektový repozitář” pak musíte dělat v každím z nich zvlášť. http://maven.apache.org/repository-management.html http://www.jfrog.com/home/v_artifactory_opensource_overview http://www.sonatype.org/nexus/
1. Nejsem Grammar Nazi, ale některé chyby mi trhají uši / oči. Nebudu psát jejich seznam, protože jsem jich napočítal víc než deset a pak mě to přestalo bavit. 2. Takové "řešení" neberu jako řešení, naopak se v každé korporaci snažím objasňovat výhody Artifactory / Nexusu a obyčejně to tam buď nasadí, nebo zjistí že už to je nasazené, jenom o tom nevěděli.
V jednom projekte som to narychlo a nudzovo riesil takto: * zavislosti, ktore neboli v Mavene, boli v adresari libs * kazdy JAR v libs mal svoje vlastne POM * existoval shellskript, ktory na danom stroji importol JAR aj s POMom do lokalneho Maven uloziska Toto sa samozrejme dialo len pre JARka, ktore boli vytesane do kamena a uz sa nemenili (legacy kod). Projektovy POM potom nemusi obsahovat odkaz na specialny repozitar vo filesysteme. Druhou vyhodou je, ze akonahle vasa zavislost vo filesysteme ma svoje vlastne zavislosti, mvn deploy:deploy-file si uz nevystaci s parametrami z commandlinu. Ale samozrejme, Artifactory/Nexus su omnohokrat lepsie riesenie, ktore z technickeho hladiska potrebuje minimum veci.