Maven 2.2.1 [Wanrning] JAR będzie pusta - nie oznaczono zawartość włączenia

Question

Maven 2.2.1 JDK - 1.6.0_45

[UWAGA] JAR będzie pusta - nie oznaczono zawartość włączenia ! BUILD SUCCESSFUL

Ale kompilacja tworzy słoik z pom.xml , ale nie ma plików klas.

Na kodzie źródłowym tego wyjątku jest zgłaszany tylko wtedy, gdy nie znaleziono katalogu źródłowego.

Build działa dla wszystkich innych twórców z wyjątkiem mojej stacji roboczej oraz po jednym stanowisku

próbowałem wszystkich rozwiązań przewidzianych w tej kwestii na przepełnienie stosu.

Mój katalog źródłowy to src/java. Utworzyłem także src/main/java jako źródło wciąż bez rezultatu. Dzwonię do mvn -o jar: jar & & zadzwoń mvn -o antrun: uruchom -o jest w tym momencie testuję z niektórymi starymi słoikami.

<build> 
     <sourceDirectory>src/java</sourceDirectory> 
     <resources> 
      <resource> 
       <directory>${basedir}/src/java</directory> 
       <includes> 
        <include>**/*.xml</include> 
        <include>**/*.properties</include> 
       </includes> 
      </resource> 
     </resources> 
     <testResources> 
      <testResource> 
       <directory>${basedir}/src/test/resources</directory> 
       <includes> 
        <include>**/*.properties</include> 
        <include>**/*.xml</include> 
       </includes> 
      </testResource> 
     </testResources> 
     <plugins> 
      <plugin> 
       <artifactId>maven-compiler-plugin</artifactId> 
       <configuration> 
        <debug>true</debug> 
        <optimize>false</optimize> 
        <showDeprecation>true</showDeprecation> 
        <source>1.5</source> 
        <target>1.5 </target> 
       </configuration> 
      </plugin> 
      <plugin> 
       <artifactId>maven-surefire-plugin</artifactId> 
       <configuration> 
        <excludes> 
         <exclude>test*/temp/*.java</exclude> 
         <exclude>test*/support/*.java</exclude> 
         <exclude>test*/debug/*.java</exclude> 
        </excludes> 
        <includes> 
         <include>test*/**/AllTests.java</include> 
        </includes> 
       </configuration> 
      </plugin> 
      <plugin> 
       <artifactId>maven-antrun-plugin</artifactId> 
       <version>1.7</version> 
       <executions> 
        <execution> 
         <id>default-cli</id> 
         <phase>install</phase> 
         <configuration> 
          <target> 
           <copy file="${project.build.directory}/${artifactId}-${version}.jar" 
            todir="${user.home}/.m2/repository/${groupId}/${artifactId}/${version}" /> 
          </target> 
         </configuration> 
         <goals> 
          <goal>run</goal> 
         </goals> 
        </execution> 
       </executions> 
      </plugin> 
     </plugins> 
    </build> 

Answer 1

Najpierw wykonaj conventions in Maven co oznacza Twój kod źródła produkcja powinna być w src/main/java. Powinieneś również zlokalizować swoje zasoby, takie jak pliki właściwości lub inne rodzaje plików (np. Pliki xml) w swojej skrzynce, do właściwej lokalizacji, która jest przeznaczona do produkcji src/main/resources i do testów jednostkowych src/test/resources.

Pierwszą rzeczą, którą należy zmienić, jest struktura katalogów dla projektu w procesie migracji. Pozwoli to zaoszczędzić wiele kłopotów z konfiguracjami w Maven, ponieważ naruszasz paradygmat convention over configuration.

Twoje urządzenie testuje kod w numerze src/test/java i postępuje zgodnie z naming conventions for unit tests, co oznacza, że ​​nazwa jednostki testowej jest taka sama jak *Test.java nic więcej. Nie musisz definiować pakietu, aby uruchomić wszystkie testy. Jeśli będziesz postępować zgodnie z konwencją nazewnictwa, wtyczka maven-surefire wykona całą pracę za Ciebie.

Wyjąć wtyczkę antrun od konfiguracji pom i używać

mvn install 

zamiast zainstalować produkowanego słoik w lokalnym repozytorium. Na podstawie build life cycle skompilujesz, przetestujesz urządzenie i zapiszesz swój kod w wynikowych plikach jar.

Zwykle w Maven nie ma powodu, aby dzwonić pod numer mvn jar:jar osobno.

Poza tym wszystko powinno przestać używać Maven 2.2.1 cause it has defined End Of Life. Lepiej zacznij od Maven 3.X. Ale wszystko, co napisałem wcześniej, jest ważne Maven 3.