commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Neidhart (JIRA)" <>
Subject [jira] [Commented] (EMAIL-152) Make javamail implementation dependency optional
Date Thu, 19 Mar 2015 22:45:38 GMT


Thomas Neidhart commented on EMAIL-152:

It would have more or less the same effect, but I do not think that this is correct in this

Scope provided means, the dependency is expected to be present at runtime, but in the case
of commons-email you can chose different javamail implementations. Which one would you define
as provided?

The same for the api dependency. I need to include an api jar so that commons-email can be
compiled, but which one will be used at runtime (e.g. the geronimo-javamail-1.4_spec or the
javax.mail-api) is up to the user (or the container).

Btw. commons-email is also used outside of containers, in which case provided is clearly wrong

> Make javamail implementation dependency optional
> ------------------------------------------------
>                 Key: EMAIL-152
>                 URL:
>             Project: Commons Email
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Thomas Neidhart
>             Fix For: 1.4
> Currently, commons-email has a transitive dependency to the reference implementation
of javamail.
> This can lead to problems when trying to use another implementation (e.g. geronimo or
gnu) at runtime, as one has to exclude dependencies.
> So I propose to change the dependencies as follows:
>  * use an optional compile time dependency to the latest javamail api:
> {noformat}
>         <dependency>
>             <groupId>javax.mail</groupId>
>             <artifactId>javax.mail-api</artifactId>
>             <version>1.4.5</version>
>             <scope>compile</scope>
>             <optional>true</optional>
>         </dependency>
> {noformat}
>  * add an optional runtime dependency to the javamail reference impl
> {noformat}
>         <dependency>
>             <groupId>com.sun.mail</groupId>
>             <artifactId>javax.mail</artifactId>
>             <version>1.5.2</version>
>             <scope>runtime</scope>
>             <optional>true</optional>
>         </dependency>
> {noformat}
> that way both dependencies are not transitive, thus project including commons-email have
the opportunity to chose their javamail implementation.
> geronimo implementation:
> {noformat}
>         <dependency>
>             <groupId>org.apache.geronimo.javamail</groupId>
>             <artifactId>geronimo-javamail_1.4_mail</artifactId>
>             <version>1.8.3</version>
>         </dependency>
> {noformat}
> or the oracle reference impl, as outlined above.

This message was sent by Atlassian JIRA

View raw message