ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: cvs commit:....
Date Tue, 27 Jun 2000 16:44:15 GMT

isn't it possible and most likely preferred that when there are implementation
choices (choices are good) to "shield" the actual mail message implementation
behind an adaptor or what not that is in turn intimately aware of ant? that way,
if javax.mail is available, as determined by the adapter at run time, an argueably

rich and solid extension is available but if that javax.mail is not available then
alternative package is used.

hope this helps,

- james

Jason Hunter wrote:

> > I think optional packages are just as important as core packages, but one
> > thing I'd like to just insert in this discussion is that emailing a message
> > does not seem to me to be something that should be included as a core
> > taskdef.  It makes more sense to include this as an optional taskdef because
> > it does not increase the runtime requirements ( See Duncan's spec doc at
> >
> > 1&content-type=text/vnd.viewcvs-markup ).
> So the question is, "Is it better to keep Ant's dependencies on external
> JAR files to a minimum, or is it better to provide a set of core tasks
> that can be relied upon to work the same across all build machines?"  I
> choose the latter.  If there's a small freely redistributable JAR that
> enables a task worthy of being core, I'd like to see it included.  If
> it's large JAR or not freely redist, but the task is still important,
> then as a last resort we make it an optional task.
> > Further down that road, I don't think that the Ant project should contain
> > any code that deals specfically with sending email when there is an
> > established and widely embraced standard in JavaMail. We could reimplement
> > this under APL in the future,
> How annoying.  This increases my belief that an open source project
> (such as Perl) has more right to be called an "open standard" than a JCP
> standard where there isn't a freely redistributable implementation (as
> appears to be the case with JavaMail) and where bugs can't be fixed
> without legal implications.
> -jh-

View raw message