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