Mit Maven2 kopieren Sie die Ressourcen, um das build-Verzeichnis, aber NICHT bündeln in der JAR

Habe ich begonnen, ein neues Maven-Projekt in NetBeans, akzeptieren Sie alle Standardeinstellungen. Die POM, mit der alle JAR-Abhängigkeiten entfernt, ist cut-n-eingefügt am unteren Rand dieser Frage.

Die Anwendung liest in den verschiedenen properties-Dateien (z.B. Protokollierung und config). Es liest auch in externe Ressourcen wie Schriften, Bilder und sounds. Ich will NICHT all diese Ressourcen gebündelt werden, die bis in die JAR-Datei. Stattdessen Plane ich, stellen Sie Sie in Unterverzeichnisse unter dem Verzeichnis, wo die JAR bereitgestellt wird.

Ist eine vereinfachte Darstellung der Projekt-Verzeichnis-Struktur sieht wie folgt aus:

-src
   |---main
           |---java
                   |---com.mypackage, etc
           |---resources
                        |---conf
                        |---fonts
                        |---images
                        |---sounds
+target

Was würde ich wie zu haben, nach einem clean-build würde so Aussehen:

+src
-target
       |---myproject-1.0.0.jar (compiled contents of "src/main/java" ONLY)
       |---conf
       |---fonts
       |---images
       |---sounds

Jedoch, wenn ich eine "clean-and-build" oder ein "exec" durch NetBeans (oder der Befehl-Linie für diese Angelegenheit)... was bin ich eigentlich erste sieht wie folgt aus:

+src
-target
       |---classes
                  |---("src/main/java" and "src/main/resources" slammed together)
       |---myproject-1.0.0.jar (the "classes" subdirectory JAR'ed up)

Kann mir jemand zeigen in die richtige Richtung für das erste Ergebnis eher als die zweite? Ich entschuldige mich, wenn dies ist eine blöde Frage (ich bin ein Maven-rookie), oder wenn ich übersah eine zuvor gestellte doppelte. Allerdings, aus der Suche habe ich auf Stack Overflow... es sieht aus wie die doppelten Fragen versuchen zu gehen, die anderen Weg! (D. H. Ressourcen in eine JAR anstatt halten Sie aus)

pom.xml:

<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>steveperkins</groupId>
    <artifactId>myproject</artifactId>
    <packaging>jar</packaging>
    <version>1.0.0</version>
    <name>My Project</name>
    <url>http://maven.apache.org</url>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.0.2</version>
                <configuration>
                    <source>1.4</source>
                    <target>1.4</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <dependencies>
    ...

InformationsquelleAutor Steve Perkins | 2010-10-25

11

Obwohl die vorgeschlagenen Lösungen funktionieren würden, Sie funktionieren im Grunde rund um die maven Konventionen. Eine bessere alternative wäre es, heraus zu filtern, die Ressourcen, so dass Sie nicht in der jar aber weiterhin als Ressourcen bei der Arbeit in der IDE. In der pom sollte es so Aussehen:
```
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <excludes>
                            <exclude>/conf/**</exclude>
                            <exclude>/fonts/**</exclude>
                            <exclude>/images/**</exclude>
                            <exclude>/sounds/**</exclude>
                        </excludes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
   </plugins>
</build>
```
Dies würde effektiv Ausschluss aus der jar-ohne workarounds.

Hier ist die doc-Seite für Sie die jar-plugin.

Obwohl die obigen Beantwortung Ihrer Frage darf ich vorschlagen, einige weitere Möglichkeit, die helfen könnten Sie in Ihrem bemühen. Als zweiten Schritt immer noch machen, diese Ressourcen zur Verfügung, die Sie könnten, packen Sie Ihr Projekt mithilfe der Montage plugin. dies würde ermöglichen es Ihnen, eine zip-Datei erstellen und platzieren Sie alle Dateien, Ressourcen und Glas, an einem geeigneten Ort, so dass, wenn die zip entpackt einfach alles fällt in Platz.

Wenn dieses Projekt ist Teil einer größeren Arbeit, die Sie immer noch mit dem assembly-plugin für jeden, wo würden Sie diese situation haben, und in der Haupt-Projekt könnte man extrahieren und wieder zusammenbauen, Sie in einen größeren zip-einschließlich aller notwendigen Artefakte.

Schließlich schlage ich vor, Sie lassen die Verzeichnis-Struktur unter " Ziel-ist. Wenn Sie es anpassen wäre es besser, es zu tun durch das Maven-Variablen so, dass die Veränderungen des schadstoffeintrags auf die anderen plugins. Wenn Sie manuell entfernen und umbenennen Zeug einmal Maven durchgemacht hat, können Sie später Probleme. Normalerweise wird das Maven-jar-plugin sollte in der Lage sein zu erhalten es gerade Recht, wenn Sie es so konfigurieren, dass Sie haben keine Bedürfnisse zu kümmern, was kommt, im Ziel. Ich persönlich verwende Eclipse und das pusign ist ziemlich gut darin, die IDE und Maven config sync. Für NetBeans würde ich vermuten, dies würde auch der Fall sein. Wenn nicht der beste Ansatz wäre die Konfiguration Ihres Projekts in NetBeans zu nutzen Ziel/Klassen als Ziel-Ordner für die gebauten Artefakte und target/test-classes für Sachen gebaut aus src/test/java.
- Dies würde nicht geben, was der OP verlangt (z.B. conf, schriftart, etc, in den root des Ziel-directory), zumindest nicht ohne weitere Anstrengungen.
- Das ist mein Punkt, er doe Rotz ändern müssen seinem root-Ordner auf, alle. Mucking rund um die angenommene maven-Konventionen ist der Weg in die Dunkelheit. Maven ist großartig, so lange, wie Sie spielen schön mit Ihr. Wenn Sie versuchen, und ändern Sie die Welt um ihn herum wird es brechen in vielen unerwarteten Orten
- Das ist, warum ich vorgeschlagen, mit andere Standort als src/main/resources zu erreichen, was die OP gefragt, ohne zu brechen nichts.
- Mir gefällt dieser Ansatz am besten, weil es spielt schön mit der "exec" Ziel, verwendet von NetBeans ausführen der Anwendung innerhalb der IDE. Ich weiß nicht wirklich, wenn alles, aber der Küchenspüle, kopiert wird "target/classes" während des build-Prozesses... nur so lange, wie ich wind-up mit nicht-Java-Ressourcen außerhalb der JAR-Datei als final deliverable. Ich kann eine assembler-Paket alles, was Sie auf einmal das GLAS ist richtig gebaut.
- Ich muss jedoch beachten, dass diese pom Beispiel oben hat bei mir nicht funktioniert wie geschrieben. Ich endete die Förderung, <configuration> - element zwei Ebenen, ein direktes Kind von <plugin - > - element... und dann eliminiert das <Ausführungen> - element insgesamt. Fein gearbeitet dann.
- Was genau hat mein Vorschlag etwas zu brechen, auf dass Ihr nicht an??? In der Tat, die Filterung, die später im Prozess können alle anderen Teile des Systems zu finden, die Dinge, wie Sie es erwarten. Hatte die Dateien fehlen der Ziel-Ordner das Programm nicht finden würden die Ressourcen in der gleichen Weise wäre es, wenn es bereitgestellt wird, es sei denn, eine zusätzliche Konfiguration gebracht wird, um den build-Prozess. Wie ich es sehe verwenden einen anderen Speicherort für Ressourcen ist weitaus riskanter in Bezug zu etwas zu beschädigen, als einfach nur zu filtern, die aus der Eingabe das Glas zur rechten Zeit.
- danke für den Kommentar, ich habe Korrekturen an der Antwort zu reflektieren Ihre Erfahrungen.
- If you try and change the world around it it will break in many unexpected places => ich habe nur geantwortet, dass eine zusätzliche Ressource, die Lage nicht etwas zu brechen. Aber ob wir dem Zustimmen oder nicht, ist nicht wirklich wichtig.
- vereinbart, die Vereinbarung ist nicht zwingend :-). Mein Punkt war, zu sagen, was Sie hier zitiert -, dass die überführung von Ressourcen in einem anderen Ort, so dass Sie nicht abgeholt maven, und als ein Ergebnis, platziert im Ziel-Ordner würde verhindern, dass die Anwendung von zu finden, diese Ressourcen bei der Ausführung aus der IDE. Ich Neige dazu, zu wollen, dass der IDE-Umgebung und dem finalen deployment-Umgebung so nah wie möglich an einander. Hier das, was ich verstanden von der Frage war, dass diese Mittel wurden erwartet werden an diesem Standort nur, dass Sie im inneren des jar, war unerwünscht....
- dieser sagte, da Java-Griffe alle, aber die meisten grundlegenden Operationen anders wenn die Mittel innerhalb einer jar nicht als einzelne Dateien gerendert, die meisten dieses argument irrelevant sowieso. Für mein Wunsch für Gegenargumente es war weit mehr aus Neugier erkunden Sie jemand anderes erleben und zu sehen, die Motivationen hinter Ihrer Lösung in der Hoffnung, etwas neues zu lernen. Zu Spalten, zwischen Recht und Unrecht ist eine Falle, leicht zu fallen, bleibt aber eine Falle, dennoch versuche ich, zu bleiben Weg von. In diesem Sinne, sehr vielen Dank für Eure Kommentare und Antworten.
InformationsquelleAutor Newtopian

Persönlich würde ich nicht verwenden den standardmäßigen Speicherort von Ressourcen, sondern eine "extra" - Standort und die Konfiguration der Ressourcen-plugin, um Sie zu kopieren, wo Sie wollen, gibt es unter:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.4.3</version>
        <executions>
          <execution>
            <id>copy-resources</id>
            <!-- here the phase you need -->
            <phase>validate</phase>
            <goals>
              <goal>copy-resources</goal>
            </goals>
            <configuration>
              <outputDirectory>${basedir}/target</outputDirectory>
              <resources>          
                <resource>
                  <directory>src/non-packaged-resources</directory>
                  <filtering>true</filtering>
                </resource>
              </resources>              
            </configuration>            
          </execution>
        </executions>
      </plugin>
    </plugins>
    ...
  </build>
  ...
</project>

Wenn Sie darauf bestehen mit der Verwendung der Standard-Speicherort (src/main/resources), ich denke, Sie konfigurieren werden einige Ausnahmen (siehe unten) zu vermeiden, Ressourcen zu bekommen, kopiert standardmäßig zu verwenden und dann die gleiche Vorgehensweise wie oben.

Andere Möglichkeit wäre die Verwendung der maven-AntRun-plugin und Ant-Dateien zu verschieben, aber das ist nicht wirklich das maven Weg, also werde ich nicht detail geht.

Ressourcen

InformationsquelleAutor Pascal Thivent

0

Können Sie sonfigure eine spezielle Ausführung der Ressourcen:kopieren-Ressourcen Ziel.

InformationsquelleAutor Eugene Kuleshov

Eugene ist auf der richtigen Spur, aber es gibt einen besseren Weg, um diese Arbeit zu machen.

Sollte es etwa so Aussehen:

<build>
  <outputDirectory>target/${artifactId}-${version}</outputDirectory>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <version>2.3.1</version>
      <configuration>
        <classesDirectory>${project.build.outputDirectory}</classesDirectory>
        <outputDirector>target</outputDirectory>
      </configuration>
    </plugin>
  </plugins>
  <resources>
    <resource>
      <directory>src/main/resources/conf</directory>
      <targetPath>../conf</targetPath>
    </resource>
    <resource>
      <directory>src/main/resources/ANOTHER_PATH</directory>
      <targetPath>../ANOTHER_PATH</targetPath>
    </resource>
  </resources>
</build>

Werden Sie nicht in der Lage, um loszuwerden, der 'classes' - Verzeichnis, aber Sie werden in der Lage sein, um Ihr einen anderen Namen, sollten nicht mit NetBeans.

Finden Sie mehr über die <outputDirectory> element hier.

Finden Sie mehr über die jar-plugin hier.

Finden Sie mehr über die <resource> element hier.

Als seitliche Anmerkung, möchten Sie vielleicht zu prüfen, ausführen von Maven unter einem 1.6 JDK und Gabel das maven-compiler-plugin nutzen, deine 1.4 JDK zum kompilieren. Sie können herausfinden, mehr über diese hier. Das sollte Ihnen Auftrieb für Ihre compile-Zeit. Man kann auch sagen, surefire beim ausführen von test-Fällen, die Verwendung des JDK 1.4 für die Ausführung als gut.

InformationsquelleAutor jgifford25

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.