2017-02-27 16 views
7

Próbowałem zrestrukturyzować projekt java, przesuwając submodules na osobne projekty wdrożone w naszym wewnętrznym repozytorium maven (archiva).UnknownEntityTypeException w fasoli od Mavena

Klasy od submodułów są następujące:

org.example.srv.DomainUser 
org.example.srv.DomainUserBean //entity manager 
org.example.srv.UserGroup 
org.example.srv.UserGroupBean //entity manager 

To działa dobrze, gdy pliki źródłowe są kopiowane do odpowiedniego folderu pakietu wewnątrz głównego projektu serwera backend, ale kiedy usunąć pliki źródłowe z projekt serwera backend i ciągnąć ten sam kod w postaci uzależnienia maven, pojawia się następujący błąd przy próbie dostępu do bazy danych:

org.hibernate.UnknownEntityTypeException: Unable to locate persister: org.example.srv.DomainUser 

Trwałość XML dla projektu serwera backend:

<?xml version="1.0" encoding="UTF-8"?> 
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"> 
<persistence-unit name="loginserver"> 
    <properties> 
     <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/> 
    </properties> 
</persistence-unit> 
</persistence> 

Mogę sobie tylko wyobrazić, że ma to coś wspólnego z odkryciem fasoli, gdy projekty są oddzielne, ale jestem naprawdę zakłopotany i byłoby świetnie rozdzielić te projekty przy minimalnym obciążeniu konfiguracyjnym.

główna pom.xml projektu serwer:

<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>org.example.srv</groupId> 
    <artifactId>loginserver</artifactId> 
    <version>0.0.2-SNAPSHOT</version> 
    <packaging>war</packaging> 
    <dependencies> 
     <dependency> 
      <groupId>javax</groupId> 
      <artifactId>javaee-api</artifactId> 
      <version>7.0</version> 
      <scope>provided</scope> 
     </dependency> 
     <dependency> 
      <groupId>com.unboundid</groupId> 
      <artifactId>unboundid-ldapsdk</artifactId> 
      <version>3.2.0</version> 
     </dependency> 
     <dependency> 
      <groupId>org.example</groupId> 
      <artifactId>authobjects</artifactId> 
      <version>1.0.0</version> 
     </dependency> 
    </dependencies> 
    <build> 
     <finalName>loginserver</finalName> 
    </build> 
    <properties> 
     <maven.compiler.source>1.8</maven.compiler.source> 
     <maven.compiler.target>1.8</maven.compiler.target> 
     <failOnMissingWebXml>false</failOnMissingWebXml> 
    </properties> 
</project> 

Auth Przedmioty pom.xml (projekt ten zawiera również kod ORM dla klas, w tym JPQL budowniczych rachunku, itp):

<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> 
    <properties> 
     <pj.gid>org.example</pj.gid> 
     <pj.aid>authobjects</pj.aid> 
     <pj.ver>1.0.2-SNAPSHOT</pj.ver> 
     <maven.compiler.source>1.8</maven.compiler.source> 
     <maven.compiler.target>1.8</maven.compiler.target> 
    </properties> 

    <groupId>${pj.gid}</groupId> 
    <artifactId>${pj.aid}</artifactId> 
    <version>${pj.ver}</version> 

    <dependencies> 
     <dependency> 
      <groupId>javax</groupId> 
      <artifactId>javaee-api</artifactId> 
      <version>7.0</version> 
      <scope>provided</scope> 
     </dependency> 
     <dependency> 
      <groupId>ent.tnp.utils</groupId> 
      <artifactId>genericentityejb</artifactId> 
      <version>1.0.0</version> 
     </dependency> 
    </dependencies> 

    <build> 
     <extensions> 
      <extension> 
       <groupId>org.apache.maven.wagon</groupId> 
       <artifactId>wagon-webdav</artifactId> 
       <version>1.0-beta-2</version> 
      </extension> 
     </extensions> 
    </build> 

    <distributionManagement> 
     <repository> 
      <id>internal</id> 
      <url>http://archiva.tnp.in/repository/internal/</url> 
     </repository> 
     <snapshotRepository> 
      <id>snapshots</id> 
      <url>http://archiva.tnp.in/repository/snapshots/</url> 
     </snapshotRepository> 
    </distributionManagement> 

    <repositories> 
     <repository> 
      <id>internal</id> 
      <name>Archiva Managed Internal Repository</name> 
      <url>http://archiva.tnp.in/repository/internal/</url> 
      <releases> 
       <enabled>true</enabled> 
      </releases> 
      <snapshots> 
       <enabled>false</enabled> 
      </snapshots> 
     </repository> 
     <repository> 
      <id>snapshots</id> 
      <name>Archiva Managed Snapshot Repository</name> 
      <url>http://archiva.tnp.in/repository/snapshots/</url> 
      <releases> 
       <enabled>false</enabled> 
      </releases> 
      <snapshots> 
       <enabled>true</enabled> 
      </snapshots> 
     </repository> 
    </repositories> 
    <pluginRepositories> 
     <pluginRepository> 
      <id>internal</id> 
      <name>Archiva Managed Internal Repository</name> 
      <url>http://archiva.tnp.in/repository/internal/</url> 
      <releases> 
       <enabled>true</enabled> 
      </releases> 
      <snapshots> 
       <enabled>false</enabled> 
      </snapshots> 
     </pluginRepository> 
     <pluginRepository> 
      <id>snapshots</id> 
      <name>Archiva Managed Snapshot Repository</name> 
      <url>http://archiva.tnp.in/repository/snapshots/</url> 
      <releases> 
       <enabled>false</enabled> 
      </releases> 
      <snapshots> 
       <enabled>true</enabled> 
      </snapshots> 
     </pluginRepository> 
    </pluginRepositories> 

</project> 

Wyjaśnienie: genericentityejb jest klasą abstrakcyjną zaprojektowaną do komponowania zapytań JPQL i zarządzania zapytaniami do bazy danych dla jednostki JPA. Projekt authobjects rozszerza go raz dla każdej z encji, które zawiera, aby zapewnić trwałość każdej z tych jednostek.

+0

W jaki sposób? dodać trwałe klasy do konfiguracji Hibernacji? –

+0

Skonfigurowałem je do automatycznego wykrywania przez okno ustawień JPA w JBoss Developer Studio (w oparciu o eclipse). Wciąż jestem nowy w JPA/Hibernte. Dodanie ' false' do persistence.xml projektu z materiałem JPA również nie pomaga. – KG6ZVP

+0

To wydaje się bardziej problem z maven/archiva. Czy twoja zależność 'SNAPSHOT'?Czy ** najnowsza ** kompilacja została poprawnie wdrożona w archiwum? Czy są jakieś ostrzeżenia MD5? Czy sprawdziłeś, czy jest ono poprawnie pobrane i spakowane? Czy główny moduł to WAR/EAR? Pokazanie obu POM powinno pomóc. –

Odpowiedz

1

Możesz dodać <jar-file> elementu, zawierający ścieżkę do jar z clases podmiotu, do persistence.xml lub opisywać wszystkich klas podmiot korzystający <class> element.

Ponadto można dodawać klasy jednostek programowo, stosując metodę skanowania pakietów.Zebrałem przydatne linki i bibliotek dla takiego podejścia tutaj:

https://github.com/v-ladynev/hibernate-scanners-test

+0

Dodanie wydaje się być bardzo złym pomysłem z Mavenem i używanie go w bardzo niepożądany sposób. Co dokładnie dzieje się z klasami jednostek w osobnym artefakcie Maven kontra wewnątrz projektu? Podczas uruchamiania kontener wydaje się skanować poprawnie. – KG6ZVP

+0

@ KG6ZVP Naprawdę nie wiem, co się tam dzieje. Skanowanie na zajęcia nie jest prostym zadaniem w Javie. Słoiki są przetwarzane osobno jako archiwa zip. Zaktualizowałem swoją odpowiedź. –

+0

Próbuję uniknąć dodawania czegokolwiek dla klas poza zależnością maven i jakimkolwiek "normalnym" kodem, który mógłby z nich korzystać. Ponieważ istnieją sposoby na uniknięcie tego w innych projektach, staram się dowiedzieć, jak to zrobić, jednocześnie miksując w Maven. – KG6ZVP

3

Z tego co widzę, istnieją co najmniej moduły zaangażowane:

  • org.example.srv:loginserver:0.0.2-SNAPSHOT

    • org.example:authobjects:1.0.0
  • org.example:authobjects:1.0.2-SNAPSHOT

    • ent.tnp.utils:genericentityejb:1.0.0

i Zauważam pewną możliwą krytyczności:

  1. loginserver nie zależy od authobjects, ale na genericentityejb (są dwa niespokrewniony np duże projekty?).
  2. loginserver nie zależy od authobjects:1.0.2-SNAPSHOT, ale na authobjects:1.0.0
  3. loginserver nie deklaruje żadnego repozytorium (ani POM dominująca), więc genericentityejb jest zawsze rozwiązany z lokalnej maszynie repozytorium, chyba ty oświadczył repozytoriów w globalny settings.xml (w porządku).
  4. Nie jestem pewien, czy warto używać właściwości dla authobjects project groupId, artifactId i version. Może nie jest to powiązane, ale uniknęłoby takiej deklaracji.

Mówiąc to, używam podobnej struktury do moich projektów, wdrażając do Wildfly 10.1, a Hibernate poprawnie odkrywa wszystkie jednostki we wszystkich zależnościach.

Więc spróbuję czystej rundy. będę ignorować authobjects ponieważ nie jest określany i przypuszczam wymaganych klas podmiotu są w genericentityejb:

  1. modyfikować wersję genericentityejb POM 1.0.1-SNAPSHOT
  2. z genericentityejb folderu: mvn clean install
  3. modyfikować authobjects wersji POM 1.0.3-SNAPSHOT i zależność genericentityejb na 1.0.1-SNAPSHOT
  4. z authobjects folderu: mvn clean install
  5. modyfikować loginserver zależność authobjects do 0.0.3-SNAPSHOT i zależności authobjects do 1.0.3-SNAPSHOT
  6. z loginserver folderu: mvn dependency:analyze celu sprawdzenia używanych dużą liczbą wykazywanych zależności niezadeklarowanych
  7. z loginserver folderu (może genericentityejb): mvn clean package
  8. sprawdzić, czy loginserver/target/loginserver-0.0.3-SNAPSHOT.war!/WEB-INF/lib/genericentityejb-1.0.3-SNAPSHOT.jar i loginserver/target/loginserver-0.0.3-SNAPSHOT.war!/WEB-INF/lib/authobjects-0.0.3-SNAPSHOT.jar są obecne i zawierają wszystkie klasy jednostek.

Również może to być przydatne, aby spojrzeć na loginservereffective POM


deklarujących repozytoriów w pom.xml lub settings.xml jest osobistym wyborem. Oba podejścia mają zalety i wady:

  • copy'n'paste repozytoriów

    • pom: Dla każdego nowego projektu
    • ustawienia: dla każdej nowej maszynie (deweloper, CI env ...)
  • edycja URL repo

    • pom: dla każdego projektu
    • ustawienia: dla każdej maszyny
  • po zwolnieniu artefakt:

    • pom: refes repo są wyryte w kamieniu dla tej wersji
    • ustawienia: repo refesy użyte w tej wersji nie są zapisywane
+0

Zawarłem niepoprawną wersję pliku pom.xml. Zaktualizowałem moje pytanie poprawnym pom.xml. Ten, który wcześniej zamieściłem, to ten, który używa modułu submodule git, aby uwzględnić zależność, do której próbujemy użyć programu maven. – KG6ZVP

+0

Czy poleciłbyś zadeklarować repozytoria w pliku pom.xml? Jest obecnie skonfigurowany w pliku settings.xml. – KG6ZVP

+0

@ KG6ZVP patrz aktualizacja. –