The layout is something I am definitely on board with changing. It
just kind of sprawled over time after getting opinions on layout from
others. There the bulk of everything is the seam mail "core" and then
there is an impl for each of the template engines supported.
It is probably possible to just have a api and impl as the specific
template impls (FreeMarkerTemplate, VelocityTemplate, RenderTemplate)
should only throw a NoClassDefFoundError if someone tries to use them
and doesn't include the engine in their pom...which could be
documented in the ref docs.
Thoughts?
On Sun, Aug 14, 2011 at 5:06 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Hi Cody,
I've just spent some time going over Seam Mail and preparing it for the
release, however I've discovered a number of items that I think still need
some work before it can go out:
1) Seam mail core - I think that the core module should be removed and this
should just become seam-mail-api, and (possibly, I'll get back to this
shortly) seam-mail (the implementation). This would bring the module into
conformity with other modules that follow a similar structure of one api,
multiple implementations.
2) Evaluate whether the sub-module currently called seam-module-core-impl is
necessary. It seems to me that this contains classes that the user might
use directly, in which case they should go into the API module. If they are
classes that don't actually belong in the API, then maybe a submodule called
seam-mail-common might make more sense if they are implementation classes
common to both the Velocity and Freemarker implementations.
3) The implementations need a minor restructure - the impl directory in both
the Freemarker and Velocity implementations is redundant, these submodules
can go directly in their respective sub-dirs. Also, the artifacts should be
renamed to seam-mail-freemarker and seam-mail-velocity.
4) The seam-render sub-module. What is this for exactly? It only contains
one class, RenderTemplate - can this go into the impl or seam-mail-common
perhaps?
5) The distribution is broken. Running mvn clean install -Drelease produces
a distribution archive that seems to be missing a whole bunch of stuff,
including the actual project artifacts.
If anyone is able to help Cody out with these items it would be greatly
appreciated, as I know he little spare time to spend on the mail module at
the moment. Likewise, I have my hands tied up with the release right now so
if we're going to get the mail module into the 3.1.0.Beta1 release then
we'll need a kind volunteer to help out with it.
Thanks,
Shane