Add DI, remove static code and many code duplications, add DI usage e…

[yotamoron]

…xample

[lc-nyovchev]

I kind of disagree adding a Main class to the repo to show how to "wire" it all up together. I think if you want to have an example, you can better have this as a part of the README.

[yotamoron]

Sure, makes sense. I'll move it.

[billoneil]

We are not going to make this library depend on Guava, Spring core and Spring context. Not everyone uses DI and those who do not everyone uses Spring. What exactly are you trying to solve here? The only issue I see this resolving is the ability to pass in the mandrill root url which was requested once before. If you want the ability to proxy to some other server we can expose a constructor where you pass in a HttpClient which can be configured to use a proxy. Then you can use your own DI framework to construct MandrillApis that proxy to some test server or the prod server.

[lc-nyovchev]

Maybe that's correct, it shouldn't actually depend on Spring core/Context it was depending for it for the Main class to run I guess, but the abundance of static methods make it hard for people to change the internals so at least that I see as a good thing. The guava is more or less meh for me.

[yotamoron]

I fixed most of the stuff and removed the spring dep (it was a bad idea - I agree).
Current code is much more testable, can be used with a DI framework properly, and - most important for us - the user can now inject their own http implementation (most big projects will have their own means of sending and receiving http requests).

[lc-nyovchev]

I'd also remove the lutung-mandrill-all.xml in the resources folder. I think everybody knows how to wire their stuff, the important thing is removing the statics.

[stiebrs]

addContent(mergeVars, queryExecutor) will overwrite "template_contents" set by executing addContent(templateContent, queryExecutor)

[stiebrs]

This should return array

[stiebrs]

all the calls are package-private, perhaps should be public?