[aguizar]

Tom, please review what we already have. Here are some drawbacks to what you propose.

1. commons-email already offers a complete email abstraction, no need to come up with another one.
2. your design merges template and producer. to implement it in jbpm 3 you parsed the configuration into a properties and copied field by field to the Mail class. I think it is more natural to have an explicit MailTemplate class and aggregate it.
3. creating an email requires no "session" because the email is an entity object. on the other hand you do require a session to send it. the responsibility to send the message should be transferred to the session.

[kukeltje]

I tend to agree with Alex (even for his taste of beer since I by luck I got my hands on a Negra Leon over here http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4162620)

[tom.baeyens]

1) we shouldn't create a dependency on commons stuff. our users will use it as well and that way we get library version conflicts. using standards directly we don't have that problem.

commons email is intended as a convenient api abstraction on top of JavaMail. we don't need that convenience. we should be good enough to figure out JavaMail on our own.

our users will see neither. not our mail session, not commons mail abstraction. so it is an internal only implementation detail.

2) the api i proposed is based on the functionality that we build: use named templates to prepopulate fields in an email. i don't see the arguments why you think a separate email class is better.

3) true. the name session is only inspired by the rest. but a mail mnager would be just as good.

i'll have a look at the branch this evening

[tom.baeyens]

i've looked at the branch and it looks like i thought.

the library dependency is a showstopper for me. we need to depend only on JavaMail

the other two points (2 and 3) are basically taste and hence less important to me.

the configuration of the templates and the jpdl language are important. that needs to be discussed as we build out the examples.

in the test with the mail template configurations, all looks good except for the actors attribute. that should now be changed into attributes users or groups specifically.

i'm surprised to see so much code without a single end-to-end example that we can discuss in detail. we should go in smaller iterations and discuss sooner. otherwise the risk throwing away a lot of work in case the discussions lead to different outcome

[bradsdavis]

Many JBoss projects use Apache Commons projects; all commons projects are just simplified interfaces or utility classes.

Some of those include:
Commons-collections
Commons-logging
Commons-lang
Commons-codec
Commons-io
etc.

And these were pulled from successful projects: Seam, Messaging, Cache.

Users are going to use our mail stuff; they are going to extend on it. Might as well make it easier on them rather than having to use some module we wrote from scratch that provides the same functionality as Commons.

[camunda]

Sine commons-mail is only required if you want to use email functionality in jbpm, I wouldn't have problems with introducing that dependency, if it makes lice easier on our side (say: saves development time for other stuff)...

Just my two cents...