¿Dependencia de Maven para la API Servlet 3.0?


229

¿Cómo puedo decirle a Maven 2 que cargue la API Servlet 3.0?

Lo intenté:

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

Uso http://repository.jboss.com/maven2/ pero ¿qué repositorio sería correcto?

Apéndice:

Funciona con una dependencia para toda la API Java EE 6 y la siguiente configuración:

<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>

Preferiría agregar solo la API de Servlet como dependencia, pero "Brabster" puede tener razón en que las dependencias separadas han sido reemplazadas por Java EE 6 Profiles. ¿Hay alguna fuente que confirme esta suposición?


84
Sin fuentes, sin javadocs en el repositorio java.net/maven/2. Oráculo, vete al infierno!
stepancheg

2
Usar javaee-Api en lugar de servlet-api no le ofrece la misma versión de javax.servlet.ServletContext. Estoy usando Spring Framework 3.1 y estoy usando Dynamic Disthcer (anotación). La respuesta de Sa'ad es la única respuesta que funciona para mí. Realmente no deberías ir con Pascal, ya que parece ser más genérico. Diablos ... Gradle supera a Maven en la resolución de dependencias.
Mukus

Dios mío, cambiaron el nombre del artefacto de servlet-apia javax.servlet-api. Perdió media hora "depuración" ...: /
insan-e

Respuestas:


116

Prefiero agregar solo la API de Servlet como dependencia,

Para ser honesto, no estoy seguro de entender por qué, pero no importa ...

Las dependencias separadas de Brabster han sido reemplazadas por Java EE 6 Profiles. ¿Hay alguna fuente que confirme esta suposición?

El repositorio maven de Java.net ofrece el siguiente artefacto para el Perfil Web:

<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>

Este frasco incluye 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.

Pero que yo sepa, nada permite decir que estas API no se distribuirán por separado (en el repositorio java.net o en otro lugar). Por ejemplo (ok, puede ser un caso particular), la API JSF 2.0 está disponible por separado (en el repositorio java.net):

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

Y en realidad, podría obtenerlo javax.servlet-3.0.jardesde allí e instalarlo en su propio repositorio.


3
Una pequeña corrección: javaee-web-api incluye EL 2.2 (Lenguaje Unificado de Expresión 2.2), no EL 1.2
Andrey

1
... y para uso de gradle: compile 'javax: javaee-web-api: 6.0'
Robert Christian el

1
Tenga en cuenta que javaee-web-apisolo contiene stubs de método (sin código de byte). No puede usar esta dependencia fuera del providedalcance, por eso prefiero la sugerencia de Sa'ad.
Rafael Winterhalter

2
@Pascal - "Prefiero agregar solo la API de Servlet como dependencia" - lo haría si se trata de un contenedor de servlet puro (tomcat, jetty) frente a un contenedor compatible con JEE (TomEE, wildfly, etc.)
YoYo

1
el javaee-web-api ha sido actualizado a<version>7.0</version>
OJVM

461

Esto parece ser agregado recientemente:

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>

29
Debe agregar <scope> proporcionado </scope>
Serkan Arıkuşu

1
Hola, esto funciona bien, pero no estoy seguro de que esta sea la dependencia exacta que se utilizará (con Tomcat 7, por ejemplo); la razón es que las fuentes asociadas a esta dependencia no coinciden con lo que realmente se está ejecutando cuando realmente se realiza la depuración.
Eugen

55
@TejaswiRana El alcance proporcionado significa que no está empaquetado para la guerra. La dependencia está disponible en tiempo de compilación, lo espera en la carpeta de la biblioteca del servidor.
banterCZ

55
¿Por qué no solo reutilizó el artifactId servlet-api? ¿Porque es divertido agregar <excludes>el viejo artifactId (para evitar que tanto la API de servlet antigua como la nueva aparezcan en su classpath si una de sus dependencias todavía depende de la antigua)? :)
Geoffrey De Smet

3
FYI, la versión más reciente es javax.servlet-api-3.1.0. Solo asegúrese de que su contenedor de Servlet pueda manejar esa versión. Por ejemplo, la Versión 8 de Tomcat puede manejar 3.1 .
Basil Bourque


25

Aquí está lo que uso. Todos estos están en la Central y tienen fuentes.

Para Tomcat 7 (Java 7, Servlet 3.0)

Nota: Servlet, JSP y EL API se proporcionan en Tomcat. Solo JSTL (si se usa) debe incluirse con la aplicación web.

<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>

Para 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>

Esto funciona, pero las dependencias prescritas terminan en la sección de Maven pero nunca se incluyen en el archivo WAR, ya que están marcadas como "proporcionadas". PERO ... Nunca puedo hacer que el proyecto use los JAR en el directorio lib de Tomcat, aunque he incluido este directorio lib de Tomcat en la ruta de compilación de Eclipse, y se pueden ver claramente allí. Mi pom.xml nunca puede resolver estos JAR de Tomcat y siempre requiere la versión 3.0.1 del JAR de servlet-api del repositorio local de Maven, en lugar de los suministros de Tomcat de la versión 3.0. No tengo idea de por qué esto es ... ¿alguien puede explicar?
Geeb

¿Puede darme qué versión de <groupId> javax.servlet </groupId> <artifactId> javax.servlet-api </artifactId> puedo usar para tomcat 8.5?
Gog1nA

24

Desafortunadamente, agregar javaee- (web) -api como una dependencia no le da el Javadoc o la Fuente a la API de Servlet para explorarlos desde el IDE. Este también es el caso para todas las demás dependencias (JPA, EJB, ...) Si necesita las fuentes de API de Servlet / javadoc, puede agregar lo siguiente a su pom.xml (funciona al menos para JBoss y Glassfish):

Repositorio:

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

Dependencia:

<!-- 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>

Eliminé por completo el javaee-api de mis dependencias y lo reemplacé con las partes discretas (javax.ejb, javax.faces, ...) para obtener las fuentes y Javadocs para todas las partes de Java EE 6.

EDITAR:

Aquí está la dependencia equivalente de Glassfish (aunque ambas dependencias deberían funcionar, sin importar el servidor de aplicaciones que use).

<dependency>
  <groupId>org.glassfish</groupId>
  <artifactId>javax.servlet</artifactId>
  <version>3.0</version>
  <scope>provided</scope>
</dependency>

1
¿Por qué necesitamos especificar la versión 1.0.0.Beta2, si es la versión 3.0que necesitamos? Esto lo hace complejo.
Geoffrey De Smet

9

El proyecto Apache Geronimo proporciona una dependencia de API Servlet 3.0 en el repositorio de Maven Central:

<dependency>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-servlet_3.0_spec</artifactId>
    <version>1.0</version>
</dependency>

2
Esto funciona, y parece la forma más simple, ¡gracias! Por cierto, Apache Geronimo tiene mucho más que ofrecer: mvnrepository.com/artifact/org.apache.geronimo.specs
stivlo

5

Solo para los recién llegados.

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

4

Encontré un POM de ejemplo para la API Servlet 3.0 en DZone desde septiembre.

Sugiero que use el repositorio java.net, en http://download.java.net/maven/2/

Hay API de Java EE allí, por ejemplo http://download.java.net/maven/2/javax/javaee-web-api/6.0/ con POM que parecen ser lo que buscas, por ejemplo :

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

Supongo que las convenciones de versión para las API se han cambiado para que coincidan con la versión de la especificación EE general (es decir, Java EE 6 vs. Servlets 3.0) como parte de los nuevos 'perfiles'. Mirando en el JAR, parece que todas las cosas del servlet 3.0 están ahí. ¡Disfrutar!


Gracias, funciona! La única pregunta que queda es si Java EE 6 Profiles reemplazó las bibliotecas separadas. (ver anexo en mi pregunta)
deamon

Si depende de esto, no puede hacer una guerra portátil (una que funcione en JBoss, Tomcat, Jetty, ...), porque para Tomcat / Jetty, necesitará poner parte de esa dependencia provista (servlet) y parte de ella no proporcionada (cdi), lo cual es imposible.
Geoffrey De Smet

3

A continuación se muestra una forma conveniente (se recomienda JBoss) para incluir dependencias Java EE 6. Como resultado, las dependencias se colocan por separado (no todas en un solo jar como en javaee-web-api), los archivos fuente y los javadocs de las bibliotecas están disponibles para descargar desde el repositorio 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>

Para incluir solo dependencias individuales, se pueden usar la dependencyManagementsección y el alcance 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>

-3

Prueba este código ...

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>3.0-alpha-1</version>
    </dependency>

Las dependencias en la etapa alfa no siempre son adecuadas para la aplicación de producción.
Stephan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.