Odwołując się do identyfikatora artefaktu słoika zależności użytkownika od persistence.xml

Question

Pracujemy z JPA i próbujemy trzymać się standardowej specyfikacji (i omijać funkcje specyficzne dla Hibernacji).

Używamy jednego projektu (nazwijmy go X) wewnątrz innego projektu (A) jako zależności Mavena.

Musimy JPA skanować projektu X dla podmiotów, jak również projektu skanowania A.

W tym celu dodaliśmy linię

<jar-file>lib/X-v5-4.0.jar</jar-file> 

wewnątrz

<persistence-unit> 

w persistence.xml. To działa dobrze.

Problem, który wciąż mamy, polega na tym, że musimy teraz określić wersję projektu X w nie tylko pom.xml, ale także w pliku persistence.xml. Jest to przepis na problemy z wdrożeniami w przyszłości.

Musimy wymyślić systemu filtrowania przy użyciu zasobów Maven:

<jar-file>lib/X-v5-${x-version}.jar</jar-file> 

w persistence.xml i

<properties> 
    <x-version>4.0</x-version> 
</properties> 

i $ {x-version} w pom.xml.

Działa to, ale nadal nie jest doskonały, ponieważ będziemy musieli pamiętać o aktualizacji numeru wersji w niestandardowej lokalizacji za każdym razem, gdy projekt X otrzyma nową wersję.

Idealnie chcielibyśmy mieć sytuację, w której możemy dostosować informacje o wersji w części pom.xml dotyczącej zależności, a zmiany zostaną automatycznie propagowane do pliku persistence.xml. Zredukowalibyśmy w ten sposób wiele możliwych błędów w przyszłości.

Czy to możliwe?

EDIT (Nasze rozwiązanie):

dodaliśmy plik o nazwie jpa.xml. Definiujemy entityManagerFactory, persistenceAnnotationBeanPostProcessor i transactionManager w nim. Ważną częścią jest fasola entityManagerFactory. Posiada właściwość "packagesToScan", która pozwala wskazać określone pakiety do skanowania pod kątem encji, aby umieścić w kontekście utrwalania.

Kod urywek:

<bean id="entityManagerFactory" 
    class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> 
    <property name="dataSource" ref="jpaDataSource" /> 
    <property name="loadTimeWeaver"> 
     <bean 
      class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver" /> 
    </property> 
    <property name="packagesToScan"> 
     <list> 
      <value>org.com.our.external.library.package1</value> 
      <value>org.com.our.external.library.package2</value> 
      <value>org.com.our.external.library.package3</value> 
     </list> 
    </property> 
</bean> 

Jestem pewien, widać zaletę: jak odnosimy się do tych bibliotek przez podpisanie pakietu, nie musimy już martwić się o numery wersji słoiku.

Answer 1

Czy mogę zaproponować, aby dodać test jednostkowy, aby sprawdzić, czy jar-file zgodnie z oczekiwaniami przez persistence.xml jest rzeczywiście na miejscu?

Nie będzie działać w celu uzyskania numeru wersji w persistence.xml z dependency.

Będzie działać na odwrót, w ten sposób ustaw dependency.version z właściwości w POM.Spełnia to wymóg zdefiniowania wersji tylko w jednym miejscu, a programiści, którzy chcą zaktualizować dependency, mogą napotkać właściwość, sprawdzić ją i zaktualizować właściwość, zamiast nadpisywać ją zaktualizowanym numerem wersji.

Może to być dodatkowo obsługiwane przez Versions Maven Plugin.

Answer 2

Rozwiązałem to w ten sposób:

w persistence.xml substytut cały <jar-file> tag, czyli

<persistence-unit name="PersistenceUnit"> 
    ... 
    <!-- here is where the jar file is supposed to go --> 
    ${importjarfile} 
    ... 
</persistence-unit> 

Wreszcie ustawić właściwości tak:

<properties> 
    <x-version>4.0</x-version> 
    <importjarfile><![CDATA[<jar-file>lib/X-v5-${x-version}.jar</jar-file>]]></importjarfile> 
</properties> 

W ten sposób Eclipse nie zobaczy tagu jar-file i nie będzie narzekać.

Moje rozwiązanie było w rzeczywistości trochę czystsze, ponieważ korzystałem z pliku .properties, więc nie musiałem używać CDATA, mam nadzieję, że nadal działa.

Moje rozwiązanie:

importjarfile = <jar-file>lib/X-v5-${x-version}.jar</jar-file>