Zależność Maven dla API Servlet 3.0?

229

Jak mogę powiedzieć Maven 2, aby załadowała API Servlet 3.0?

Próbowałem:

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>3.0</version>
    <scope>provided</scope>
</dependency>

Używam http://repository.jboss.com/maven2/, ale jakie repozytorium byłoby poprawne?

Uzupełnienie:

Działa w zależności od całego interfejsu API Java EE 6 i następujących ustawień:

<repository>
    <id>java.net</id>
    <url>http://download.java.net/maven/2</url>
</repository>

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>6.0</version>
    <scope>provided</scope>
</dependency>

Wolę dodawać tylko interfejs API serwletów jako zależność, ale „Brabster” może mieć rację, że oddzielne zależności zostały zastąpione profilami Java EE 6. Czy istnieje źródło, które potwierdza to założenie?

java  maven-2  servlets  jakarta-ee 
— deamon
źródło
84
Brak źródeł, brak javadocs w repozytorium java.net/maven/2. Oracle, idź do piekła!
— stepancheg
2
Użycie javaee-Api zamiast servlet-api nie daje tej samej wersji javax.servlet.ServletContext. Korzystam z frameworka Spring 3.1 i dynamicznej dyspatry (adnotacji). Odpowiedź Sa'ada jest jedyną odpowiedzią, która działa dla mnie. Naprawdę nie powinieneś iść z Pascalem, ponieważ wydaje się to bardziej ogólne. Heck .. gradle pokonuje maven w rozwiązywaniu zależności.
— Mukus,
OMG, zmienili nazwę artefaktu z servlet-apina javax.servlet-api. Straciłem pół godziny „debugowania” ...: /
— insan-e

Odpowiedzi:

116

Wolę dodawać tylko interfejs API serwletu jako zależność,

Szczerze mówiąc, nie jestem pewien, dlaczego rozumiem, ale nieważne ...

Oddzielne zależności Brabster zostały zastąpione profilami Java EE 6. Czy istnieje źródło, które potwierdza to założenie?

Repozytorium maven z Java.net rzeczywiście oferuje następujący artefakt dla WebProfile:

<repositories>
  <repository>
    <id>java.net2</id>
    <name>Repository hosting the jee6 artifacts</name>
    <url>http://download.java.net/maven/2</url>
  </repository>
</repositories>        
<dependencies>
  <dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-web-api</artifactId>
    <version>6.0</version>
    <scope>provided</scope>
  </dependency>
</dependencies>

Ten słoik obejmuje Servlet 3.0, EJB Lite 3.1, JPA 2.0, JSP 2.2, EL 1.2, JSTL 1.2, JSF 2.0, JTA 1.1, JSR-45, JSR-250.

Ale o ile wiem, nic nie pozwala powiedzieć, że te interfejsy API nie będą dystrybuowane osobno (w repozytorium java.net lub gdzie indziej). Na przykład (ok, może to być konkretny przypadek), interfejs API JSF 2.0 jest dostępny osobno (w repozytorium java.net):

<dependency>
   <groupId>com.sun.faces</groupId>
   <artifactId>jsf-api</artifactId>
   <version>2.0.0-b10</version>
   <scope>provided</scope>
</dependency>

I rzeczywiście, można uzyskać javax.servlet-3.0.jarod tam i zainstalować go w swoim własnym repozytorium.

— Pascal Thivent
źródło
3
Jedna mała poprawka: javaee-web-api zawiera EL 2.2 (Unified Expression Language 2.2), a nie EL 1.2
— Andrey
1
... i do użytku stopniowego: skompiluj 'javax: javaee-web-api: 6.0'
— Robert Christian
1
Zauważ, że javaee-web-apizawiera tylko kody pośredniczące metod (bez kodu bajtowego). Nie można korzystać z tej zależności poza providedzakresem, dlatego wolę sugestię Sa'ada.
— Rafael Winterhalter
2
@Pascal - „Wolę dodawać interfejs API serwletów jako zależność” - zrobiłbyś to, jeśli masz do czynienia z kontenerem czystego serwletu (tomcat, jetty) zamiast kontenera zgodnego z JEE (TomEE, wildfly itp.)
— YoYo
1
JavaEE-web-api została zaktualizowana<version>7.0</version>
— OJVM
461

Wydaje się, że zostało to ostatnio dodane:

http://repo1.maven.org/maven2/javax/servlet/javax.servlet-api/3.0.1/

<dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>3.0.1</version>
        <scope>provided</scope>
</dependency>
— Sa'ad
źródło
29
Powinieneś dodać <scope> dostarczone </scope>
— Serkan Arıkuşu
1
Hej, to działa dobrze, ale nie jestem pewien, czy jest to dokładna zależność, którą należy zastosować (na przykład z Tomcat 7); powodem jest to, że źródła dołączone do tej zależności nie pasują do tego, co faktycznie działa podczas debugowania.
— Eugen,
5
@TejaswiRana Podany zakres oznacza, że ​​nie jest on zapakowany do wojny. Zależność jest dostępna w czasie kompilacji, można się tego spodziewać w folderze biblioteki serwera.
— banterCZ
5
Dlaczego po prostu nie użył ponownie artefaktu servlet-api? Bo fajnie jest dodawać <excludes>stary artefakt (aby uniknąć pobierania zarówno starego, jak i nowego apletu apletu na ścieżkę klasy, jeśli jedna z zależności nadal zależy od starej)? :)
— Geoffrey De Smet
3
Do Twojej wiadomości, najnowsza wersja to javax.servlet-api-3.1.0. Tylko upewnij się, że Twój kontener serwletów obsługuje tę wersję. Na przykład wersja 8 Tomcat obsługuje 3.1 .
— Basil Bourque
25

Oto czego używam. Wszystkie są w centralnej i mają źródła.

Dla Tomcat 7 (Java 7, Servlet 3.0)

Uwaga - interfejsy API serwletów, JSP i EL są dostępne w Tomcat. Tylko aplikacja JSTL (jeśli jest używana) musi być dołączona do aplikacji internetowej.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.0.1</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.servlet.jsp</groupId>
    <artifactId>jsp-api</artifactId>
    <version>2.2</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>2.2.4</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
</dependency>

Dla Tomcat 8 (Java 8, Servlet 3.1)

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.servlet.jsp</groupId>
    <artifactId>javax.servlet.jsp-api</artifactId>
    <version>2.3.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>3.0.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
</dependency>
— rustyx
źródło
Działa to, ale zalecane zależności znajdują się w sekcji Maven, ale nigdy nie są zawarte w pliku WAR, ponieważ są oznaczone jako „dostarczone”. ALE ... Nigdy nie mogę zmusić projektu do używania plików JAR w katalogu lib Tomcat, mimo że umieściłem ten katalog lib Tomcat w ścieżce kompilacji Eclipse, i można je wyraźnie zobaczyć. Mój pom.xml nigdy nie może rozwiązać tych plików JAR Tomcat i zawsze wymaga wersji 3.0.1 pliku JAR serwlet-api z lokalnego repozytorium Maven, a nie wersji 3.0 dostarczanej przez Tomcat. Nie mam pojęcia, dlaczego… czy ktoś może to wyjaśnić?
— Geeb
Czy możesz podać, której wersji <groupId> javax.servlet </groupId> <artifactId> javax.servlet-api </artifactId> mogę użyć dla tomcat 8.5?
— Gog1nA
24

Niestety dodanie javaee- (web) -api jako zależności nie daje Javadoc ani źródła do apletu Servlet do przeglądania ich z poziomu IDE. Dotyczy to również wszystkich innych zależności (JPA, EJB, ...) Jeśli potrzebujesz źródeł Servlet API / javadoc, możesz dodać następujące pliki do pliku pom.xml (działa przynajmniej dla JBoss i Glassfish):

Magazyn:

<repository>
  <id>jboss-public-repository-group</id>
  <name>JBoss Public Repository Group</name>
  <url>https://repository.jboss.org/nexus/content/groups/public/</url>
</repository>

Zależność:

<!-- Servlet 3.0 Api Specification -->
<dependency>
   <groupId>org.jboss.spec.javax.servlet</groupId>
   <artifactId>jboss-servlet-api_3.0_spec</artifactId>
   <version>1.0.0.Beta2</version>
   <scope>provided</scope>
</dependency>

Całkowicie usunąłem javaee-api z moich zależności i zastąpiłem go dyskretnymi częściami (javax.ejb, javax.faces, ...), aby uzyskać źródła i Javadocs dla wszystkich części Java EE 6.

EDYTOWAĆ:

Oto równoważna zależność Glassfish (chociaż obie zależności powinny działać, bez względu na to, jakiego serwera używasz). 

<dependency>
  <groupId>org.glassfish</groupId>
  <artifactId>javax.servlet</artifactId>
  <version>3.0</version>
  <scope>provided</scope>
</dependency>
— Ingo Fischer
źródło
1
Dlaczego musimy określić wersję 1.0.0.Beta2, jeśli jest to wersja 3.0, której potrzebujemy? To czyni to złożonym.
— Geoffrey De Smet,
9

Projekt Apache Geronimo zapewnia zależność API Servlet 3.0 od repozytorium Maven Central:

<dependency>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-servlet_3.0_spec</artifactId>
    <version>1.0</version>
</dependency>
— Patrick Crocker
źródło
2
Działa i wydaje się najprostszy sposób, dzięki! BTW Apache Geronimo ma o wiele więcej do zaoferowania: mvnrepository.com/artifact/org.apache.geronimo.specs
— stivlo
5

Tylko dla nowo przybyłych.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>
— Sergii I.
źródło
4

Znalazłem przykład POM dla API Servlet 3.0 na DZone od września.

Zaproponuj użycie repozytorium java.net, pod adresem adresem http://download.java.net/maven/2/

Są tam interfejsy API Java EE, na przykład http://download.java.net/maven/2/javax/javaee-web-api/6.0/ z POM, które wyglądają na to, że mogą być tym, czego szukasz, na przykład :

<dependency>
  <groupId>javax</groupId>
  <artifactId>javaee-web-api</artifactId>
  <version>6.0</version>
</dependency>

Zgaduję, że konwencje wersji dla interfejsów API zostały zmienione, aby pasowały do ​​wersji ogólnej specyfikacji EE (tj. Java EE 6 vs. Servlety 3.0) w ramach nowych „profili”. Patrząc na JAR, wygląda na to, że są tam wszystkie elementy serwletu 3.0. Cieszyć się!

— Brabster
źródło
Dzięki, działa! Pozostaje tylko pytanie, czy profile Java EE 6 zastąpiły osobne biblioteki lib. (patrz uzupełnienie do mojego pytania)
— deamon
Jeśli zależysz od tego, nie możesz stworzyć przenośnej wojny (takiej, która działa na JBoss, Tomcat, Jetty, ...), ponieważ w przypadku Tomcat / Jetty musisz umieścić część tej zależności (serwlet) i część tego nie podana (cdi), co jest niemożliwe.
— Geoffrey De Smet,
3

Wygodny sposób (zalecany JBoss) włączenia zależności Java EE 6 pokazano poniżej. W wyniku tego zależności są umieszczane osobno (nie wszystkie w jednym słoiku, jak w javaee-web-api), pliki źródłowe i javadocs bibliotek są dostępne do pobrania z repozytorium maven.

<properties>
    <jboss.javaee6.spec.version>2.0.0.Final</jboss.javaee6.spec.version>
</properties>
<dependencies>
    <dependency>
        <groupId>org.jboss.spec</groupId>
        <artifactId>jboss-javaee-web-6.0</artifactId>
        <version>${jboss.javaee6.spec.version}</version>
        <scope>provided</scope>
        <type>pom</type>
    </dependency>
</dependencies>

Aby uwzględnić tylko indywidualne zależności, można użyć dependencyManagementsekcji i zakresu import:

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.jboss.spec</groupId>
                <artifactId>jboss-javaee6-specs-bom</artifactId>
                <version>${jboss.javaee6.spec.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <!-- No need specifying version and scope. It is defaulted to version and scope from Bill of Materials (bom) imported pom. -->
        <dependency>
            <groupId>org.jboss.spec.javax.servlet</groupId>
            <artifactId>jboss-servlet-api_3.0_spec</artifactId>
        </dependency>
    </dependencies>
— Andrey
źródło
-3

Wypróbuj ten kod ...

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>3.0-alpha-1</version>
    </dependency>
— Josh
źródło
Zależności na etapie alfa nie zawsze są odpowiednie do zastosowania produkcyjnego.
— Stephan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.