2012-07-10 16 views
6

Mamy rozwiązanie, w którym nasze projekty interfejsu użytkownika obejmują sporo usług biznesowych przy użyciu zależności klienta EJB. Problem z tym na Mavenie polega na tym, że chociaż klient .jar zwykle zawiera około 1-2 klas, przynosi ze sobą cały stos zależności od całej aplikacji usługowej. To może stać się nieco brzydkie, gdy pliki .ear zaczynają rosnąć do 50-100Mb, pop i od czasu do czasu pojawiają się brzydkie błędy dzięki nieistotnym zależnościom wkradającym się do aplikacji UI.Wykluczenie zależności od generowania klientów maven ejb

Oczywiście zawsze możemy wykluczyć zależności na końcu klienta, ale musimy napisać tę samą wiązkę linii do każdego projektu klienta, korzystając z tych usług i to jest dużo niepotrzebnych powtórzeń. Dodatkowo ludzie wymyślają najdziwniejsze komunikaty o błędach i poświęcają im dużo czasu na śledzenie, zanim wspomną, że wspomnieli, że zawierają słoik klienta i nie sprawdzili, jakie dodatkowe zależności wprowadził do równania.

Przykład:

 <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-common</artifactId> 
      <version>2.6</version> 
     </dependency> 
     <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-service</artifactId> 
      <classifier>client</classifier> 
      <exclusions> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#1</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>org.codehaus.castor</groupId> 
        <artifactId>castor</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#2</artifactId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#3</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#4</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#5</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-codegen</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml-schema</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#6</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
      </exclusions> 
      <version>2.6</version> 
     </dependency> 

To jest tylko jeden klient usługi są włączone, wyobraź sobie kilka z nich w kilku różnych aplikacji i pojawi się obraz, pisanie wszystkie wyklucza każdym razem jest dość irytujące, a projekt POMs zaczynają dostawać dość długi wiatr.

Oznaczę zależność zgodnie z opisem, ale istnieje kilka zależności, które powodują awarię w środowisku wykonawczym, jeśli nie istnieją. Powiedzmy, że zawierają one inne wywołanie usługi do innej aplikacji z zewnętrzną klasą wyjątków, która nie jest z tego czy innego powodu zapakowana w projekt usługi i spowoduje wyjątek ClassNotFoundException w środowisku wykonawczym, jeśli nie jest obecny.

W związku z tym wiem, że można wykluczyć/dołączyć klasy z klienta ejb podczas jego generowania za pomocą specyfikacji pom.xml na wtyczce maven-ejb, ale czy istnieje również sposób na wykluczenie zależności?

Odpowiedz

1

Wygląda na to, że Maven nie obsługuje bardzo dobrze budowania wielu słoików z jednego modułu.

W ten sposób jedyną sensowną opcją, jaką znaleźliśmy, jest utworzenie kolejnego modułu (przerwa xxx-service na xxx-service i xxx-service-client) i skonfigurowanie modułu xxx-service-client tak, aby zawierał tylko Klient EJB/delegat klasy & minimalne zależności. W ten sposób projekt można zbudować za pomocą jednego wykonania.

0

Mam ten sam problem tutaj. myślę jedno rozwiązanie może być przy użyciu profili, ponieważ w każdym profilu można określić zależności (patrz http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)

w moim przypadku to nie działa, bo trzeba generować zarówno JAR (EJB i ejb- klient) w pojedynczej realizacji Mavena. :)

+0

Wobec podobnego problemu, rozpoczęcie zmiany sposobu budowania projektów za pomocą rozwiązania CI będzie najprawdopodobniej bardzo kłopotliwe i stanie się problemem przy konserwacji, gdy będą one działać inaczej niż wszystkie inne aplikacje w firmie. – t0mppa

Powiązane problemy