Simple Java Mail should include CLI support

[asarkar]

I'd like to download the jar, put a properties file on the classpath, and run java -jar simple-java-mail.jar. If you made the API so simple, why do I need to go through the exercise of setting up a project for a single line of code?

[bbottema]

If you made the API so simple, why do I need to go through the exercise of setting up a project for a single line of code?

I don't owe you anything, so I'm not sure why I deserve this flippant comment? I'm just doing my best here and I depend on user feedback for improving this library all the time.

I'd like to download the jar, put a properties file on the classpath, and run java -jar simple-java-mail.jar.

I don't know of a use case that would need this. The point of the library is to add an abstract layer on top of the RFC related classes in the underlying Java Mail framework. Without Simple Java Mail, you deal with RFC's, with Simple Java Mail you get a simple API. That's what make Simple Java Mail 'so simple' as you put it.

---

Now I'm willing to look beyond the obvious use cases for a library like this, but you will have to come up with a little bit than half of a one-liner. Why do you want this, just java -jar simple-java-mail.jar isn't going to do anything since you don't define an email body, text or HTML.

[asarkar]

My comment was not intended to be flippant. The use case is so simple, it doesn't warrant writing an essay. As far as you owing me, I never brought it up, so I'll chalk it up to you having a bad day, or fragile ego.
The use case is follows; I'm looking for a simple client to send emails from multiple servers. Yes, I could create my own jar, but you've provided almost everything I need, except a main class. If I do create a project, why'd I bring in an additional dependency then, because I can do everything using the JavaMail API.

If the above makes sense, I'll be happy to send a PR.

[amanteaux]

@asarkar Please calm down, your tone does sound offensive.

Even with your response, your use case is not clear to me.

[bbottema]

If the above makes sense, I'll be happy to send a PR.

Not yet, but I feel a PR is going to make more sense to me at this point. I'm not averse to having CLI capabilities in Simple Java Mail, though. I'll give it serious consideration.

[asarkar]

As always, the devil is in the details, so let me ask a couple of clarifying questions. What I was initially thinking is a way for a user to specify a properties file that the code would use to send emails. However, if they want to specify only a few properties, creating a file is overkill, and they should be able to do that using command line options. Which brings me to the next question. Spring Boot property binder already has this feature, but Boot isn’t used in this project, just Spring. So, what is really the Spring support then? Surely, I can create a few beans myself without any support from the library.

It seems to me that there are 3 logical modules here.

1. A core module that accepts properties in the form of a POJO and sends emails. The instantiation of the POJO is outside the scope of the core module.
2. A CLI module that is capable of accepting properties from various sources and converting to the aforementioned POJO. It is also responsible for invoking whatever public API the core module exposes.
3. Same as 2 but done using Spring.

If Spring Boot binder were packaged and distributed separately, 2 and 3 could be the same. But that’s not the case.

[bbottema]

That is starting to look like an essay @asarkar ;)

The properties part is simpler than that, actually. The way the included Spring support class translates properties to the configuration module can be reused to populate properties coming from CLI. I'm looking into some small but clean CLI libraries currently (args4j, JSAP, Jcommander) for this.

The interesting part is specifying body of the email and referring to files for embedding / attaching. Until now this was deferred to the library user.

Ideally I would like the CLI api to mirror the builder api. In fact, perhaps it would be better to translate all the CLI properties to builder calls so that the same validation and configuration is triggered. I need to sit on this for a bit.

[asarkar]

As the first step, I propose the following:

1. A search of ConfigLoader.Property currently shows that various properties are initialized to default values in multiple places. Create a POJO with hierarchical structure, and use a configuration management library like Lightbend Config to populate it. Once instantiated, never call setter methods on it again.

public class SJMProperties {
    public static class Default {
        private String subject = "wow";
    }
}

2. All properties are defaulted in the POJO as shown above and not scattered around the codebase.

Config conf = ConfigFactory.load();
SJMProperties boom = ConfigBeanFactory.create(config.getConfig("sjm"), SJMProperties.class);

4. Delete ConfigLoader, and reduce Spring support to a few lines (or simply delete, since Spring Boot comes with property binding for free).

With the above simple change, and addition of a class with main method, a client can immediately do java -jar -D sjm.default.subject=wow-again sjm.jar. In phase 2, with the introduction of a command line parser, they will be able to do -jar --default-subject=wow-again sjm.jar.