2016-05-11 11 views
0

Ich habe ein ziemlich großes Legacy-Modul, das sowohl EJB 3.0 als auch einige Business-Logik-Klassen enthält. Ich versuche, den Bauprozess zu konvertieren, um maven zu verwenden, und habe Schwierigkeiten, den maven-ejb-plugin zu konfigurieren.Wie maven-ejb-plugin anweisen, nur die benötigten Klassen in das Client-EJB-Paket aufzunehmen?

Ich versuche, das Client-EJB-Paket mit dem maven-ejb-plugin zu erzeugen, aber beachte, dass das Client-Paket auch alle Business-Logik-Klassen enthält - auch wenn sie nicht von den EJBs referenziert werden.

Meine aktuelle Konfiguration ist: org.apache.maven.plugins Maven-ejb-Plugin default-ejb $ {} project.build.outputDirectory ejb 3.0 wahr

Leider gibt es keine sehr klare Trennung von Paketen für b Usiness-Klassen/-Modelle/DTOs, so ist es nicht einfach genau zu bestimmen, welche EJBs von welchen Klassen abhängig sind.

Gibt es in der maven-ejb-plugin einen Mechanismus, der maven anweist, nur die erforderlichen EJB-Schnittstellen/Implementierungen & abhängige Klassen im Client-Paket einzuschließen und alles andere zu ignorieren/zu überspringen? Oder muss ich manuell herausfinden, welche abhängigen Klassen von den einzelnen Schnittstellen benötigt werden und das Plugin so konfigurieren, dass nur diese Dateien enthalten sind?

Antwort

1

Wie ich verstehe, haben Sie einige Pakete einschließlich zum Beispiel die Schnittstellen Ihrer entfernten oder lokalen EJB, und Sie haben die Definition (statesless statefull, mdb, was auch immer) im selben Paket Ihrer Schnittstellen, und Sie möchten nur importieren Die Klassen (oder Schnittstellen), die Ihr Client benötigt, benötigt die Implementierung aus logischen Gründen nicht.

Nun, wir haben zwei Punkte hier, als Empfehlung sollten Sie mindestens Ihre Fernbedienungen oder lokale Schnittstellen in einem separaten Projekt haben, um diese zu entkoppeln (als Maven-Projekt) und alle, die sie verwenden wollen, müssen es nur als Abhängigkeit importieren , ohne über ihre Implementierung zu wissen.

Der andere Punkt ist, wenn Sie einige Namenskonventionen folgen, können Sie vielleicht acomplish who Sie wollen, indem Sie .java Klasse mit ein wenig Patter einschließen (oder ausschließen).

Sie können den Link überprüfen:

http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html

Wenn Sie einige Konventionen wie diese verwenden: http://www.oracle.com/technetwork/java/namingconventions-139351.html

Sie würden zum Beispiel an, in der Lage sein:

<plugins> 
     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-surefire-plugin</artifactId> 
     <version>2.19.1</version> 
     <configuration> 
      <excludes> 
      <include>**/Local*.java</include> 
      </excludes> 
     </configuration> 
     </plugin> 
    </plugins> 
+0

I stimme deinen Punkten vollkommen zu. Aber im Moment versuche ich zu vermeiden, dieses große Modul als ersten Schritt umzubauen, selbst wenn ich technisch die Maven-Konventionen sprenge. Also versuche ich in der Zwischenzeit einen Workaround zu finden, und sobald ich sicher bin, dass meine Maven Builds richtig funktionieren und die richtigen Artefakte erzeugen, kann ich die Projekte entsprechend refaktorisieren. Wenn ich jedoch nur meine Aufnahme als meine Schnittstelle definiere, scheint sie die abhängigen Klassen nicht zu enthalten (da sie nicht in meinem Einschlussfilter angegeben sind). –