Maven2 doprowadza mnie do szału podczas fazy eksperymentowania / szybkiej i brudnej makiety.

Mam pom.xmlplik, który definiuje zależności dla frameworka aplikacji sieci web, którego chcę używać, i mogę szybko wygenerować projekty początkowe z tego pliku. Czasami jednak chcę połączyć się z biblioteką innej firmy, która nie ma jeszcze pom.xmlzdefiniowanego pliku, więc zamiast pom.xmlręcznie utworzyć plik dla biblioteki innej firmy i zainstalować go i dodać zależność do mojej pom.xml, chciałbym tylko powiedzieć Mavenowi: „Oprócz moich zdefiniowanych zależności, uwzględnij również wszystkie słoiki, które są w /libśrodku”.

Wydaje się, że to powinno być proste, ale jeśli tak, coś mi brakuje.

Wszelkie wskazówki dotyczące tego, jak to zrobić, są bardzo mile widziane. Krótko mówiąc, jeśli istnieje prosty sposób, aby wskazać maven na /libkatalog i łatwo utworzyć pom.xmlz wszystkimi dołączonymi słojami zamapowanymi na jedną zależność, którą mógłbym następnie nazwać / zainstalować i połączyć za jednym zamachem.

Problemy popularnych podejść

Większość odpowiedzi, które znajdziesz w Internecie, sugeruje zainstalowanie zależności w lokalnym repozytorium lub określenie zakresu „systemowego” w pom i dystrybucję zależności ze źródłem projektu. Ale oba te rozwiązania są w rzeczywistości wadliwe.

Dlaczego nie powinieneś stosować podejścia „Zainstaluj w lokalnym repozytorium”

Po zainstalowaniu zależności w lokalnym repozytorium pozostaje ona tam. Twój artefakt dystrybucji będzie działał dobrze, o ile będzie miał dostęp do tego repozytorium. Problem polega na tym, że w większości przypadków to repozytorium będzie znajdować się na twoim komputerze lokalnym, więc nie będzie sposobu na rozwiązanie tej zależności na żadnym innym komputerze. Wyraźne uzależnienie artefaktu od konkretnej maszyny nie jest sposobem na radzenie sobie z różnymi rzeczami. W przeciwnym razie ta zależność będzie musiała zostać zainstalowana lokalnie na każdej maszynie pracującej z tym projektem, co nie jest lepsze.

Dlaczego nie powinieneś stosować podejścia „Zakres systemu”

Słoje, na których polegasz przy zastosowaniu podejścia „Zakres systemu”, nie są instalowane w żadnym repozytorium ani dołączane do pakietów docelowych. Dlatego twój pakiet dystrybucyjny nie będzie w stanie rozwiązać tej zależności, gdy zostanie użyty. Wierzę, że był to powód, dla którego użycie zakresu systemowego nawet się przestało. W każdym razie nie chcesz polegać na przestarzałej funkcji.

Statyczne rozwiązanie repozytorium w projekcie

Po umieszczeniu tego w pom:

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

dla każdego artefaktu o identyfikatorze grupy x.y.zMaven w poszukiwaniu artefaktów uwzględni następującą lokalizację w katalogu projektu:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

Aby rozwinąć więcej na ten temat, możesz przeczytać ten post na blogu .

Użyj Maven, aby zainstalować repozytorium projektu

Zamiast ręcznie tworzyć tę strukturę, zalecamy użycie wtyczki Maven do zainstalowania słoików jako artefaktów. Aby zainstalować artefakt w repozytorium w projekcie w repofolderze wykonaj:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

Jeśli wybierzesz to podejście, będziesz mógł uprościć deklarację repozytorium w pom:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

Skrypt pomocnika

Ponieważ wykonywanie komend instalacyjnych dla każdej biblioteki jest trochę denerwujące i zdecydowanie podatne na błędy, stworzyłem skrypt narzędziowy, który automatycznie instaluje wszystkie słoiki z libfolderu do repozytorium projektu, jednocześnie automatycznie tłumacząc wszystkie metadane (groupId, artefactId itp.) Z nazwy plików. Skrypt wypisuje również xml zależności, które możesz skopiować i wkleić w swoim pliku pom.

Uwzględnij zależności w pakiecie docelowym

Po utworzeniu repozytorium wewnątrz projektu rozwiązałeś problem dystrybucji zależności projektu z jego źródłem, ale od tego czasu artefakt docelowy projektu będzie zależał od niepublikowanych słoików, więc kiedy będziesz instalował to do repozytorium będzie miało nierozwiązywalne zależności.

Aby rozwiązać ten problem, sugeruję włączenie tych zależności do pakietu docelowego. Można to zrobić za pomocą wtyczki asemblera lub lepiej za pomocą wtyczki OneJar . Oficjalna dokumentacja OneJar jest łatwa do zrozumienia.

Tylko do wyrzucenia kodu

ustaw zakres == system i po prostu utwórz identyfikator grupy, identyfikator artefaktu i wersję

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

Uwaga: zależności systemowe nie są kopiowane do wynikowego pliku jar / war
(zobacz Jak uwzględnić zależności systemowe w wojnie zbudowanej przy użyciu maven )

Możesz utworzyć lokalne repozytorium w swoim projekcie

Na przykład, jeśli masz libsfolder w strukturze projektu

• W libsfolderze należy utworzyć strukturę katalogów, taką jak:/groupId/artifactId/version/artifactId-version.jar

• W swoim pom.xml powinieneś zarejestrować repozytorium

  <repository>
      <id>ProjectRepo</id>
      <name>ProjectRepo</name>
      <url>file://${project.basedir}/libs</url>
  </repository>

• i dodaj zależność jak zwykle

  <dependency>
      <groupId>groupId</groupId>
      <artifactId>artifactId</artifactId>
      <version>version</version>
  </dependency>

To wszystko.

Aby uzyskać szczegółowe informacje: Jak dodać biblioteki zewnętrzne w Maven

Uwaga: Podczas korzystania z zakresu Systemu ( jak wspomniano na tej stronie ), Maven potrzebuje ścieżek bezwzględnych.

Jeśli słoiki znajdują się w katalogu głównym projektu, warto poprzedzić wartości systemPath wartością $ {basedir}.

To właśnie zrobiłem, działa również w przypadku problemu z pakietem i działa z wypisanym kodem.

Utworzyłem nowy folder w projekcie w moim przypadku, którego użyłem repo, ale możesz go używaćsrc/repo

W mojej POM miałem zależność, której nie ma w publicznych repozytoriach maven

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

Następnie utworzyłem następujące katalogi repo/com/dovetail/zoslog4j/1.0.1 i skopiowałem plik JAR do tego folderu.

Utworzyłem następujący plik POM, który reprezentuje pobrany plik (ten krok jest opcjonalny, ale usuwa OSTRZEŻENIE) i pomaga następnemu facetowi dowiedzieć się, skąd mam ten plik na początek.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Dwa opcjonalne pliki, które tworzę, to sumy kontrolne SHA1 dla POM i JAR, aby usunąć brakujące ostrzeżenia o sumach kontrolnych.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Na koniec dodaję następujący fragment do mojego pom.xml, który pozwala mi odwoływać się do lokalnego repozytorium

<repositories>
    <repository>
        <id>project</id>
        <url>file:///${basedir}/repo</url>
    </repository>
</repositories>

Naprawdę powinieneś wdrożyć platformę poprzez repozytorium i z góry zidentyfikować swoje zależności. Korzystanie z zakresu systemowego jest częstym błędem, z którego korzystają ludzie, ponieważ „nie dbają o zarządzanie zależnościami”. Problem polega na tym, że robiąc to, otrzymujesz zboczoną kompozycję maven, która nie pokaże maven w normalnych warunkach. Użytkownik będzie lepiej następujące podejście jak ten .

W ten sposób dodajemy lub instalujemy lokalny słoik

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

Dałem trochę domyślnego groupId i artefactId, ponieważ są one obowiązkowe :)

Wtyczka instalacyjna Maven ma użycie wiersza polecenia do zainstalowania słoika w lokalnym repozytorium, POM jest opcjonalny, ale będziesz musiał określić GroupId, ArtifactId, Version i Packaging (wszystkie rzeczy POM).

Używanie <scope>system</scope>jest okropnym pomysłem z powodów wyjaśnionych przez innych, ręczne zainstalowanie pliku w lokalnym repozytorium powoduje, że kompilacja jest niemożliwa do odtworzenia, a używanie <url>file://${project.basedir}/repo</url>nie jest dobrym pomysłem, ponieważ (1) może nie być dobrze sformułowanym fileadresem URL (np. Jeśli projekt jest wyewidencjonowany w katalogu z nietypowymi znakami), (2) wynik jest bezużyteczny, jeśli POM tego projektu jest używany jako zależność od projektu innego użytkownika.

Zakładając, że nie chcesz wgrać artefaktu do publicznego repozytorium, sugestia Simeona dotycząca modułu pomocniczego spełnia swoje zadanie. Ale jest teraz łatwiejszy sposób…

Zalecenie

Użyj wtyczki innej niż maven-jar-maven-plug-in . Robi dokładnie to, o co prosiłeś, bez żadnych wad innych podejść.

Znalazłem inny sposób, aby to zrobić, patrz tutaj z postu Heroku

Podsumowując (przepraszamy za kopiowanie i wklejanie)

• Utwórz repokatalog w folderze głównym:

Twój projekt
+ - pom.xml
+ - src
+ - repo

• Uruchom to, aby zainstalować jar w lokalnym katalogu repo

mvn deploy: deploy-file -Durl = plik: /// path / to / yourproject / repo / -Dfile = mylib-1.0.jar -DgroupId = com.example -DartifactId = mylib -Dpackaging = jar -Dversion = 1.0

• Dodaj to pom.xml:

<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>


<dependency>
    <groupId>com.example</groupId>
    <artifactId>mylib</artifactId>
    <version>1.0</version>  
</dependency>

Po bardzo długiej dyskusji z chłopakami z CloudBees na temat właściwego pakowania takich plików JAR, zaproponowali interesującą dobrą propozycję rozwiązania:

Stworzenie fałszywego projektu Maven, który dołącza istniejący plik JAR jako główny artefakt, działający w ramach należącej do niego instalacji POM: wykonanie pliku instalacyjnego. Oto przykład takiego kinfa POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Ale w celu jego wdrożenia należy zmienić istniejącą strukturę projektu. Po pierwsze, należy pamiętać, że dla każdego takiego rodzaju JAR należy utworzyć inny fałszywy projekt (moduł) Maven. I powinien zostać utworzony nadrzędny projekt Maven zawierający wszystkie podmoduły, które są: wszystkie opakowania JAR i istniejący projekt główny. Struktura może być:

projekt główny (zawiera nadrzędny plik POM zawiera wszystkie podmoduły z modułem XML) (opakowanie POM)

Opakowanie JAR 1 Projekt potomny Maven (opakowanie POM)

Owijka JAR 2 Projekt potomny Maven (opakowanie POM)

główny istniejący projekt potomny Maven (opakowanie WAR, JAR, EAR ....)

Gdy rodzic działa za pośrednictwem mvn: install lub mvn: pakowanie jest wymuszone, a podmoduły zostaną wykonane. Może to być traktowane jako minus, ponieważ struktura projektu powinna zostać zmieniona, ale na końcu oferuje rozwiązanie niestatyczne

To, co wydaje mi się najprostsze, to po prostu skonfiguruj wtyczkę kompilatora maven, aby zawierała niestandardowe słoiki. W tym przykładzie załadowane zostaną wszystkie pliki jar w katalogu lib.

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <includes>
                    <include>lib/*.jar</include>
                </includes>
            </configuration>
        </plugin>

Problem systemPathpolega na tym, że słoiki zależności nie będą rozprowadzane wzdłuż twoich artefaktów jako zależności przechodnie. Spróbuj tego, co tu napisałem: czy najlepiej jest zdenerwować pliki jar projektu lub umieścić je w WEB-INF / lib?

Następnie zadeklaruj zależności jak zwykle.

I proszę przeczytać notatkę w stopce.

Dziwne rozwiązanie, które znalazłem:

za pomocą Eclipse

• stwórz prosty (nie maven) projekt Java
• dodaj klasę główną
• dodaj wszystkie słoiki do ścieżki klasy
• eksportuj JAR Runnable (jest to ważne, ponieważ nie ma innego sposobu, aby to zrobić)
• wybierz Wyodrębnij wymagane biblioteki do wygenerowanego pliku JAR
• decydować o kwestiach dotyczących licencji
• tadammm ... zainstaluj wygenerowany słoik na m2repo
• dodaj tę pojedynczą zależność do innych projektów.

na zdrowie, Balint

Jeśli chcesz szybkiego i brudnego rozwiązania, możesz wykonać następujące czynności (chociaż nie polecam tego do niczego poza projektami testowymi, maven narzeka, że ​​nie jest to właściwe).

Dodaj pozycję zależności dla każdego potrzebnego pliku jar, najlepiej za pomocą skryptu perla lub czegoś podobnego i skopiuj / wklej to do pliku pom.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";

Szybkie i zabrudzony rozwiązanie partii (na podstawie odpowiedzi Alexa):

libs.bat

@ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)

Wykonać to tak: libs.bat > libs.txt. Następnie otwórz libs.txti skopiuj jego zawartość jako zależności.

W moim przypadku potrzebowałem tylko bibliotek do skompilowania mojego kodu i to rozwiązanie było najlepsze do tego celu.

Chociaż nie pasuje to do twojego problemu, upuszczę to tutaj. Moje wymagania to:

1. Słoje, których nie można znaleźć w internetowym repozytorium maven, powinny znajdować się w SVN.
2. Jeśli jeden programista doda inną bibliotekę, innym programistom nie powinno przeszkadzać ręczne ich instalowanie.
3. IDE (w moim przypadku NetBeans) powinien być w stanie znaleźć źródła i javadocs, aby zapewnić autouzupełnianie i pomoc.

Porozmawiajmy najpierw o (3): Samo umieszczenie słoików w folderze i jakoś scalenie ich w końcowy słoik nie będzie tutaj działać, ponieważ IDE tego nie zrozumie. Oznacza to, że wszystkie biblioteki muszą być poprawnie zainstalowane. Nie chcę jednak, aby wszyscy instalowali go za pomocą „pliku instalacyjnego mvn”.

W moim projekcie potrzebowałem metawidget. No to ruszamy:

1. Utwórz nowy projekt maven (nazwij go „shared-libs” lub coś w tym stylu).
2. Pobierz metawidget i rozpakuj zip do src / main / lib.
3. Folder doc / api zawiera javadocs. Utwórz zip zawartości (doc / api / api.zip).
4. Zmodyfikuj pom w ten sposób
5. Zbuduj projekt, a biblioteka zostanie zainstalowana.
6. Dodaj bibliotekę jako zależność do swojego projektu lub (jeśli dodałeś zależność w projekcie bibliotek współdzielonych) dodaj biblioteki współdzielone jako zależność, aby uzyskać wszystkie biblioteki na raz.

Za każdym razem, gdy masz nową bibliotekę, po prostu dodaj nowe wykonanie i powiedz wszystkim, aby ponownie zbudowali projekt (możesz ulepszyć ten proces za pomocą hierarchii projektu).

Aby zainstalować słoik innej firmy, który nie znajduje się w repozytorium maven, użyj wtyczki maven-install-plugin.

Poniżej znajdują się kroki:

1. Pobierz plik jar ręcznie ze źródła (strony internetowej)
2. Utwórz folder i umieść w nim plik jar
3. Uruchom poniższe polecenie, aby zainstalować słoik innej firmy w lokalnym repozytorium maven

mvn install: plik-instalacyjny -Dplik = -DgroupId = -DartifactId = -Dversion = -Dpackaging =

Poniżej znajduje się np. Ten, którego użyłem dla simonsite log4j

mvn install: install-file -Dfile = / Users / athanka / git / MyProject / repo / log4j-rolling-appender.jar -DgroupId = uk.org.simonsite -DartifactId = log4j-rolling-appender -Dversion = 20150607-2059 - Pakowanie = słoik

4. W pliku pom.xml uwzględnij zależność jak poniżej

     <dependency> 
           <groupId>uk.org.simonsite</groupId>
           <artifactId>log4j-rolling-appender</artifactId>
           <version>20150607-2059</version> 
     </dependency>

5. Uruchom polecenie mvn clean install, aby utworzyć opakowanie

Poniżej znajduje się link referencyjny:

https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html

Dla tych, którzy nie znaleźli tutaj dobrej odpowiedzi, robimy to, aby uzyskać słoik ze wszystkimi niezbędnymi zależnościami. Ta odpowiedź ( https://stackoverflow.com/a/7623805/1084306 ) wspomina o użyciu wtyczki Maven Assembly, ale tak naprawdę nie podaje przykładu w odpowiedzi. A jeśli nie przeczytasz do końca odpowiedzi (jest dość długa), możesz ją przegapić. Dodanie poniżej do pliku pom.xml wygenerujetarget/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <!-- get all project dependencies -->
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <!-- MainClass in mainfest make a executable jar -->
                <archive>
                  <manifest>
                    <mainClass>my.package.mainclass</mainClass>
                  </manifest>
                </archive>

            </configuration>
            <executions>
              <execution>
                <id>make-assembly</id>
                <!-- bind to the packaging phase -->
                <phase>package</phase> 
                <goals>
                    <goal>single</goal>
                </goals>
              </execution>
            </executions>
        </plugin>

Nawiązałem do jakiegoś kodu python w komentarzu do odpowiedzi @alex Lehmann, więc zamieszczam go tutaj.

def AddJars(jarList):
  s1 = ''
  for elem in jarList:
   s1+= """
     <dependency>
        <groupId>local.dummy</groupId>
        <artifactId>%s</artifactId>
        <version>0.0.1</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/manual_jars/%s</systemPath>
     </dependency>\n"""%(elem, elem)
  return s1

To nie wyjaśnia, jak dodać je do POM, i może nie jest to kłopotliwe, ale po prostu doda lib katalog do twojej ścieżki klas? Wiem, że to właśnie robię, gdy potrzebuję zewnętrznego słoika, którego nie chcę dodawać do moich repozytoriów Maven.

Mam nadzieję że to pomoże.

W naszym projekcie działa Archimedes Trajano, ale w pliku .m2 / settings.xml mieliśmy coś takiego:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

i * należy zmienić na centralny. Więc jeśli jego odpowiedź nie zadziała, powinieneś sprawdzić plik settings.xml

Chciałem tylko szybkiego i brudnego obejścia ... Nie mogłem uruchomić skryptu z Nikity Volkov: błąd składni + wymaga ścisłego formatu nazw jarów.

Zrobiłem ten skrypt Perla, który działa z dowolnym formatem dla nazw plików jar, i generuje zależności w pliku xml, dzięki czemu można go skopiować wkleić bezpośrednio w pom.

Jeśli chcesz go używać, upewnij się, że rozumiesz, co skrypt robi, być może trzeba zmienić libfolder i wartość dla groupIdlub artifactId...

#!/usr/bin/perl

use strict;
use warnings;

open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
    print "$file\n";
    my $groupId = "my.mess";
    my $artifactId = "";
    my $version = "0.1-SNAPSHOT";
    if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
        $artifactId = $1;
        if (defined($3)) {
            $version = $3;
        }
        `mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
        print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
        print " => $groupId:$artifactId:$version\n";
    } else {
        print "##### BEUH...\n";
    }
}
close $fh;

Rozwiązanie dla zakresu = podejście systemowe w Javie:

public static void main(String[] args) {
        String filepath = "/Users/Downloads/lib/";
        try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {

        List<String> result = walk.filter(Files::isRegularFile)
                .map(x -> x.toString()).collect(Collectors.toList());

                String indentation = "    ";
                for (String s : result) {
                    System.out.println(indentation + indentation + "<dependency>");
                    System.out.println(indentation + indentation + indentation + "<groupId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</groupId>");
                    System.out.println(indentation + indentation + indentation + "<artifactId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</artifactId>");
                    System.out.println(indentation + indentation + indentation + "<version>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</version>");
                    System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
                    System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
                    System.out.println(indentation + indentation + "</dependency>");
                }

    } catch (IOException e) {
        e.printStackTrace();
    }
}