Roman Valina
9.7.2014

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-libraries

Po 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/

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další
  • 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.

  • Robert Novotny

    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.