Consider making jakarata.mail as optional and make slf4j as scope test

[agentgt]

The email validation doesn't use or need Jakarta.mail.

I know there is a convenient parser but I would either move that parser to a separate maven module or just make jakarta.mail as <optional>true</optional>.

Also slf4j is not used anywhere that I could tell in src/main/java.

I assume it was or is used in src/test/java. Regardless I wouldn't expect a validation library to use or need logging.

[bbottema]

It does actually use it, specifically the class javax.mail.internet.InternetAddress. I've tried to replace it with a POJO in the past, but it turns out we use quite a lot of functionality provided by InternetAddress so I abandoned the approach at the time.

[agentgt]

Validation aka EmailAddressValidator.isValid(email). Does not use or need javax.mail.internet.InternetAddress

Try it yourself:

    <dependency>
        <groupId>com.github.bbottema</groupId>
        <artifactId>emailaddress-rfc2822</artifactId>
        <exclusions>
          <exclusion>
            <groupId>com.sun.activation</groupId>
            <artifactId>jakarta.activation</artifactId>
          </exclusion>
          <exclusion>
            <groupId>com.sun.mail</groupId>
            <artifactId>jakarta.mail</artifactId>
          </exclusion>
        </exclusions>
    </dependency>

The only class that uses it is EmailAddressParser and per EmailAddressParser javadoc

 * A utility class to parse, clean up, and extract email addresses from messages per RFC2822 syntax. Designed to integrate with Javamail (this class will
 * require that you have a javamail mail.jar in your classpath), but you could easily change the existing methods around to not use Javamail at all

So arguably it isn't required and I think the parsing should be moved to a separate module (if you need help with multi-modules maven I can put in a PR). I'm not faulting the project for using javax.mail.internet.InternetAddress as I have used it myself as well Apache Mime4J as its the only mime parser I know that works with vast amount of inputs. However most folks I assume are just looking for validation and not parsing of email addresses (nor mime).

Secondly you didn't address the SLF4J issue. I can't see a place where you used it.

[bbottema]

Where do you see slf4j? I can't find any references to it.?

/edit: Ahh, it's in the standard project parent POM, and for compile dependency only the API is included. Are you facing issues? Excluding a dependency obtained through a parent POM is not a trivial task.

[bbottema]

I've released 2.3.0, which made Jakarta Mail an optional dependency.

[agentgt]

Ahh, it's in the standard project parent POM, and for compile dependency only the API is included. Are you facing issues? Excluding a dependency obtained through a parent POM is not a trivial task.

No I didn't realize it wasn't a trivial task. I have no problem excluding the jars.

I can understand why you closed the issue original and I'm just jaded with a lot of projects not really managing their dependencies well and or just requiring a dependency for a single class. This project is actually pretty high quality and isn't that bad.

Dependency management is a huge technical debt overtime. At least for us it is. I can't just will nilly add a dependency to our code base especially if it adds dependencies. I have to check it out.

Let me give you an example for your project (and btw I totally appreciate all the time you have put into it).

Because this project uses javax.mail aka jakarta.mail it pulls in the activation library implementation aka com.sun.activation:jakarta.activation. Meanwhile other projects like jOOQ for example that use JAXB pull the older javax.activation-api. OK so we need to exclude and replace javax.activation-api with jakarta.activation:jakarta.activation-api right? Wrong. You see com.sun.activation:jakarta.activation has overlapping classes with jakarta.activation:jakarta.activation-api so you have to exclude the API when you actually use com.sun.activation:jakarta.activation. This was an hour so. All of the above for a one POJO.

I admit the above is confusing and whiny. Such is the life of dealing with Java dependencies. The irony is I picked your library because I thought it didn't have any such dependency problems. In the past when I have been OK with javax.mail aka jakarta.mail InternetAddress[] ia = InternetAddress.parse(address, true) has been good enough.

Regardless this project is very valuable and worse case scenario I can fork it. Thank you for putting it together.

I've released 2.3.0, which made Jakarta Mail an optional dependency.

Thank you!