Dependência do Maven para a API do Servlet 3.0?


229

Como posso dizer ao Maven 2 para carregar a API do Servlet 3.0?

Eu tentei:

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

Eu uso http://repository.jboss.com/maven2/ mas qual repositório estaria correto?

Termo aditivo:

Funciona com uma dependência para toda a API Java EE 6 e as seguintes configurações:

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

Prefiro adicionar apenas a API do Servlet como dependência, mas "Brabster" pode estar certo ao saber que dependências separadas foram substituídas pelo Java EE 6 Profiles. Existe uma fonte que confirme essa suposição?


84
Sem fontes, sem javadocs no repositório java.net/maven/2. Oracle, vá para o inferno!
— 31511 stepancheg

2
O uso de javaee-Api em vez de servlet-api não fornece a mesma versão do javax.servlet.ServletContext. Estou usando o framework Spring 3.1 e usando o dissipador dinâmico (anotação). A resposta de Sa'ad é a única resposta que funciona para mim. Você realmente não deve ir com Pascal, pois isso parece ser mais genérico. Heck .. gradle vence melhor na resolução de dependências.
— Mukus

OMG, eles mudaram o nome do artefato de servlet-apipara javax.servlet-api. Perdeu meia hora "depurando" ...: /
— insan-e 16/10

Respostas:


116

Prefiro adicionar apenas a API do Servlet como dependência,

Para ser sincero, não sei ao certo por que, mas não importa ...

As dependências separadas da Brabster foram substituídas pelos Java EE 6 Profiles. Existe uma fonte que confirme essa suposição?

O repositório maven do Java.net realmente oferece o seguinte artefato para o 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>

Este jar inclui 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.

Mas, pelo que sei, nada permite dizer que essas APIs não serão distribuídas separadamente (no repositório java.net ou em outro lugar). Por exemplo (ok, pode ser um caso específico), a API JSF 2.0 está disponível separadamente (no repositório java.net):

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

E, na verdade, você pode ir javax.servlet-3.0.jarde lá e instalá-lo em seu próprio repositório.


3
Uma pequena correção: javaee-web-api inclui EL 2.2 (Unified Expression Language 2.2), não EL 1.2
— Andrey

1
... e para uso gradle: compile 'javax: javaee-web-api: 6.0'
— Robert Christian

1
Observe que javaee-web-apicontém apenas stubs de método (sem código de bytes). Você não pode usar essa dependência fora do providedescopo, razão pela qual prefiro a sugestão de Sa'ad.
— Rafael Winterhalter

2
@Pascal - "Prefiro adicionar apenas a API do Servlet como dependência" - você faria isso se estiver lidando com um contêiner de servlet puro (tomcat, jetty) versus um contêiner compatível com JEE (TomEE, wildfly, etc.)
— YoYo

1
o javaee-web-api foi atualizado para<version>7.0</version>
— OJVM

461

Isso parece ter sido adicionado recentemente:

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
Você deve adicionar <scope> fornecido </ scope>
— Serkan Arıkuşu

1
Ei, isso funciona bem, mas não tenho certeza se essa é a dependência exata a ser usada (com o Tomcat 7, por exemplo); o motivo é que as fontes anexadas a essa dependência não correspondem ao que está sendo executado quando você efetua a depuração.
— 10273 Eugen

5
@TejaswiRana O escopo fornecido significa que não está empacotado para a guerra. A dependência está disponível no momento da compilação, você espera na pasta da biblioteca do servidor.
— usar o seguinte comando

5
Por que não apenas reutilizou o artefato servlet-api? Como é divertido adicionar <excludes>o artifactId antigo (para impedir a obtenção da API do servlet antigo e do novo em seu caminho de classe, se uma de suas dependências ainda depende da antiga)? :)
— Geoffrey De Smet

3
Para sua informação, a versão mais recente é javax.servlet-api-3.1.0. Apenas verifique se o contêiner do Servlet pode lidar com essa versão. Por exemplo, a versão 8 do Tomcat pode manipular 3.1 .
— Basil Bourque


25

Aqui está o que eu uso. Todos estes estão na Central e têm fontes.

Para Tomcat 7 (Java 7, Servlet 3.0)

Nota - Servlet, JSP e APIs EL são fornecidas no Tomcat. Somente o JSTL (se usado) precisa ser empacotado com o aplicativo da 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>

Isso funciona, mas as dependências prescritas acabam na seção Maven, mas nunca são incluídas no arquivo WAR, pois são marcadas como "fornecidas". MAS ... Nunca consigo que o projeto use os JARs no diretório lib do Tomcat, mesmo que eu tenha incluído esse diretório lib do Tomcat no caminho de construção do Eclipse, e eles podem ser vistos claramente lá. Meu pom.xml nunca pode resolver esses JARs do Tomcat e sempre requer a versão 3.0.1 do JAR do servlet-api do repositório local do Maven, em vez dos suprimentos da versão 3.0 do Tomcat. Eu não tenho idéia do por que isso é ... alguém pode explicar?
— Geeb

Você pode fornecer qual versão do <groupId> javax.servlet </groupId> <artifactId> javax.servlet-api </artifactId> posso usar para o tomcat 8.5?
— Gog1nA

24

Infelizmente, adicionar o javaee- (web) -api como uma dependência não fornece o Javadoc ou o Source à API do Servlet para procurá-los no IDE. Esse também é o caso de todas as outras dependências (JPA, EJB, ...) Se você precisar das fontes da API do Servlet / javadoc, poderá adicionar o seguinte ao seu pom.xml (funciona pelo menos para o JBoss & Glassfish):

Repositório:

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

Dependência:

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

Removai completamente o javaee-api das minhas dependências e o substituí pelas partes discretas (javax.ejb, javax.faces, ...) para obter as fontes e os Javadocs de todas as partes do Java EE 6.

EDITAR:

Aqui está a dependência equivalente do Glassfish (embora ambas as dependências devam funcionar, independentemente do servidor de aplicativos que você usa).

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

1
Por que precisamos especificar a versão 1.0.0.Beta2, se é a versão 3.0que precisamos? Isso torna complexo.
— Geoffrey De Smet

9

O projeto Apache Geronimo fornece uma dependência da API do Servlet 3.0 no repositório Maven Central:

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

2
Isso funciona e parece a maneira mais simples, obrigado! BTW Apache Geronimo tem muito mais para oferecer: mvnrepository.com/artifact/org.apache.geronimo.specs
— stivlo

5

Apenas para iniciantes.

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

4

Encontrei um exemplo de POM para a API do Servlet 3.0 no DZone em setembro.

Sugira que você use o repositório java.net, em http://download.java.net/maven/2/

Existem APIs Java EE lá, por exemplo, http://download.java.net/maven/2/javax/javaee-web-api/6.0/ com POM que parecem ser o que você procura, por exemplo :

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

Suponho que as convenções de versão para as APIs foram alteradas para corresponder à versão da especificação geral do EE (por exemplo, Java EE 6 vs. Servlets 3.0) como parte dos novos 'perfis'. Olhando no JAR, parece que todo o material do servlet 3.0 está lá. Aproveitar!


Obrigado, funciona! A única questão restante é se o Java EE 6 Profiles substituiu libs separadas. (ver adendo na minha pergunta)
— deamon

Se você depende disso, não pode fazer guerra portátil (uma que funcione no JBoss, Tomcat, Jetty, ...), porque para o Tomcat / Jetty, você precisará colocar parte dessa dependência fornecida (servlet) e parte dele não é fornecida (cdi), o que é impossível.
— Geoffrey De Smet

3

Uma maneira conveniente (recomendada pelo JBoss) de incluir dependências do Java EE 6 é demonstrada abaixo. Como resultado, as dependências são colocadas separadamente (nem todas em um jar como em javaee-web-api), os arquivos de origem e os javadocs das bibliotecas estão disponíveis para download no repositório 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 apenas dependências individuais, dependencyManagementseção e escopo importpodem ser usados:

    <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

Experimente este código ...

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

Dependências no estágio alfa nem sempre são adequadas para aplicação em produção.
— Stephan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.