Maven (EJB) Projekt mit client-und server-Artefakte

Hier ist meine variation auf die "mehrere Artefakte aus Maven-build" - Frage:

Ich bin Portierung von Ant auf Maven. Meine Anwendung ist ein EJB-server, die verpackt ist wie ein OHR, aber es macht auch eine client-JAR-Datei für die Verwendung durch anderen client-apps. Diese jar-Datei enthält die EJB-Schnittstellen, Fassaden-Klasse und einige Helfer.

Ich weiß, dass die Maven Weg ist, um ein Artefakt pro Projekt (POM); aber beide Artefakte (server-EAR-und client-JAR-Datei) erstellt werden müssen aus der gleichen Quelle-Baum - server-und client-Anteil, zum Beispiel der EJB und der "home" - Schnittstellen.

Wie mache ich das in Maven?

Habe ich ein Projekt mit zwei POMs, sagen server-pom.xml & client-pom.xml? Ich dachte, ich könnte auch eine parent POM (pom.xml) , kann verwendet werden zum erstellen von client-und server-mit einem üblen Streich? Allerdings werden die Lebenszyklen auseinander, nachdem das 'Paket' - phase, da die server durch die Montage (tar/gzip), während der client nach 'Paket' und kann einfach installiert werden, in das repository.

Jeden Rat/Erfahrung auf dem besten Weg, dies zu nähern?

InformationsquelleAutor Cornel Masson | 2009-12-18

maven-2

18

Ich weiß, dass die Maven Weg ist, um ein Artefakt pro Projekt (POM); aber beide Artefakte (server-EAR-und client-JAR-Datei) erstellt werden müssen aus der gleichen Quelle-Baum - server-und client-Anteil, zum Beispiel der EJB und der "home" - Schnittstellen.

Gibt es einige Ausnahme der "ein Artefakt pro Projekt" Regel, EJB-Projekte, als einer von Ihnen. So, die maven-ejb-plugins kann so konfiguriert werden, erzeugen der EJB-jar - und ein client-JAR-Datei wie diese:
```
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ejb-plugin</artifactId>
        <configuration>
           <generateClient>true</generateClient>
        </configuration>
      </plugin>
    </plugins>
  </build>
```
Verwendung der ejb-client in einem anderen Projekt, fügen Sie es einfach als Abhängigkeit von <type>ejb-client</type>:
```
<project>
  [...]
  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>ejb-project</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>ejb-client</type>
    </dependency>
  </dependencies>
  [...]
</project>
```
Sehen Erzeugen eines EJB-client, Mithilfe der ejb-client als Abhängigkeit und die Dokumentation der ejb-mojo für weitere Informationen (einschließlich, wie Sie die Klassen im Lieferumfang enthalten/ausgeschlossen von der ejb-client).

Ausgezeichnet! Lassen Sie mich versuchen.
dies funktioniert gut, außer, wenn der EJB-client ist eine Abhängigkeit von einem anderen Modul innerhalb des gleichen multi-Modul-Projekt. Erstens, Sie kann nicht in der EJB-client als verschachteltes Modul in der Eltern-Liste der Module, da es noch nicht hat seinen eigenen Ordner - es ist nur ein Nebenprodukt des EJB-Moduls. Zweitens, der EJB-client Artefakt wird nur erstellt, in der package-phase, so dass der Reaktor nicht in der Lage sein, um Sie in die kombinierte classpath sowieso.
So es scheint, muss ich aufgeben, diese Herangehensweise und Erstellung eines expliziten Modul für den EJB-client. Dies bedeutet jedoch, dass diese neue " ejb-client-Modul müsste Freigabe des Java-Quellcodes mit dem Haupt - 'ejb' Modul (EJB-Schnittstellen sind gemeinsam). Ich nehme an, ich halte die Quelle in die Haupt - 'ejb' - Modul und konfigurieren Sie den " ejb-client-Modul, um auf dem gleichen source-Verzeichnis (z.B. ../ejb/src)?
Hmm..., was? 1. Sie sind eigentlich nicht zu erklären, dass die ejb-client-Modul 2. Ein ejb-client-Abhängigkeit berücksichtigt wird, während ein Rektor zu bauen, um die Berechnung der build-Auftrag 3. Der classpath ist gebaut mit dem lokalen repository, so dass Sie haben, um install Ihre ejb-client, wie jedes andere Artefakt. In anderen Worten, ich verstehe nicht, was du sagst 🙂
Du musst immer laufen mvn install für ein multi-Module Projekt, Abhängigkeiten zwischen den Modulen aufgelöst werden durch das lokale repository.

InformationsquelleAutor Pascal Thivent
6

Ich verwendet habe, multimodule Projekte um dieses Problem zu lösen, bevor.
```
project/
    pom.xml  <- type=pom, lists sub modules
    ejb/
        src/main/java, etc.
        pom.xml <- type=ejb, describes ejb module, has dependency on "jar" module
    jar/
        src/main/java, etc.
        pom.xml <- type=jar, simple, builds jar
    ear/
        pom.xml <- type=ear, has reference to ejb module that it should use
    ...
```
Habe ich diesen Ansatz für sehr komplexe Projekte, die möglicherweise haben ein Dutzend verschiedene Module, die gebaut werden muss, zusammen. Finden Sie die Ohr-docs für die Referenzierung der ejb.

Den Eltern pom.xml verwendet die modules tag:
```
<modules>
    <module>jar</module>
    <module>ejb</module>
    <module>ear</module>
</modules>
```
Und das Kind pom.xml's Verwendung der parent tag:
```
<parent>
    <groupid>mygroup</group>
    <artifactId>parentName</artifactId>
</parent>
```
Ich bin damit einverstanden, auf die multi-Modul-Ansatz. Ich bin mir nicht ganz sicher, ich verstehe die Nutzung der EAR-Verpackungen für client: die client jar sollte nicht im OHR, und es muss auch gebaut werden, von der gleichen Codebasis (src/main/java) als OHR-code, da beide Artefakte teilen der EJB-Schnittstelle/home Klassen.

InformationsquelleAutor John Paulett

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.