> > org.apache.cocoon.mail ? (this is what I'm using at present) > > org.apache.cocoon.components.mail ? > > org.apache.cocoon.components.source.impl.mail ?
Carsten wrote: > If your implementing consists only of a source then I think the third > package name is the best to use. I would discourage you from using > the first as optional components do not belong to the top-level. > If you have additional components for mail handling the second one > would be fine. Thanks. > > Also, these components require some extra jars; namely > activation.jar (the > > Java Activation Framework) and mail.jar (JavaMail). How do > I indicate this > > dependency? > > > This dependency is indicated in the build.xml ant build > script. We can't add > (AFAIK) the jars to Cocoon directly because of the Sun > licence. Check the > build script and you will find a class test if the mail.jar > is available > and see some optional compilation for some mail components. OK - I've had a look at this and I can see what I have to do. BTW, Sun says that the JavaMail api is "free" and "redistributable", but hey, I'm not a lawyer ;-) http://java.sun.com/products/javamail/FAQ.html#free > BTW what does your source do? Reading from an email account > and sending > emails (=WritableSource)? At the moment it's just a Source (not WritableSource), because I'm in a hurry to develop it for a mail-list archive, but one of the reasons I chose to implement it as a Source (rather than a Generator) was to allow for this as a later enhancement. I don't think writability is a huge omission, though, because almost all email functionality is read/send rather than read/write; emails tend to be written, sent, received, and then not changed. I'll probably be posting the patch within a few days. Cheers! Con --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
