You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Magesh Umasankar <um...@apache.org> on 2002/02/03 23:38:15 UTC
Re: [SUBMIT] Refactor & combination of mail tasks
Erik/Steve:
Will one of you please take care of this?
http://marc.theaimsgroup.com/?t=100802277000004&r=1&w=2
Cheers,
Magesh
----- Original Message -----
From: "Rob Oxspring" <ro...@yahoo.com>
To: <an...@jakarta.apache.org>
Sent: Monday, December 10, 2001 5:18 PM
Subject: [SUBMIT] Refactor & combination of mail tasks
> Hi all,
>
> A while back (possibly when MimeMail was submitted) it was suggested that
> the mail tasks should be integrated into one, using some reflection to
> attempt to use JavaMail. Recently I had a desire to send some binary
> attachments but didn't want to have to install JavaMail on every developer
> workstation and so UU encoding was hit upon.
>
> The upshot of all this was that I've integrated the three encoding formats
> into a single task using JavaMail if available or uu encoding (via
> sun.misc.UUEncoder - presumably available to any sun based JDK?).
>
> It should be possible to drop in the new task where the old one was used
and
> not notice the difference.
>
> <project name="emailtest" default="main">
> <target name="main">
> <mail message="My message"
> subject="Ant Submission Test">
>
> <from name="From Rob" address="abc@xyz.com"/>
> <to name="To Rob" address="xyz@abc.com"/>
> <fileset dir=".">
> <include name="*.xml"/>
> </fileset>
> </mail>
> </target>
> </project>
>
> Magesh: your includefilenames patch caught me mid flow so I've tried to
> patch it in but would appreciate it if you would have a quick check that
> things are coming out OK. Only the PlainMailer is affected by this
> attribute since I didn't know how best to add it into the other formats.
>
> Todo: Probably could find / implement uu encoding but Sun's solution was
> handy and did the trick for now.
>
> Now if things run true to form I'll be back in touch in five minutes as I
> spot some daft mistake but in the meantime if others could eyeball it too
it
> would be appreciated.
>
> Hope its deemed good enough...
>
> Rob
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Stephane Bailliez" <sb...@apache.org>
****************************************************
* Doctor: A person who kills your ills by pills, *
* and then kills you with his bills. *
****************************************************
> There is no point in exagerating patch support.
> It's not like a mission critical app., and we
> don't have to accept everything to make a kitchen
> sink just to please everybody. If someone sent a
> patch and that's a blocker, than she is using a
> workaround or a patched version. If someone sent
> a task then she is using that task already. That's
> not because we make it in build v 02/02/2002 rather
> than v1.5 final that it will change anything.
> However it must be in 'final'.
Clearly, we are coming from two different schools
of thought here. IMHO, the earlier we commit the
patches (the good ones only, of course), the more time
we have it to be tested out. Patching things just
before a release is too risky, I feel. Ideal time to be
patching, is, as Pete once mentioned, right after a
release.
>
> Stephane
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
[...]
> Agreed... but most of the folks that have submitted the patches are
already
> running fine with their own custom built version of Ant and aren't in a
> hurry for it to be rolled into a nightly build. As long as we address the
> patches prior to a release by either applying them or postponing them for
> good reason then we're still doing ok, aren't we?
> I agree its nice to keep up with them regularly if at all possible. Its
just
> not possible for me currently to devote that large of a block of time for
> practically anything - I'm able to do quick patches and address e-mail
> support which is important to our collective committer mission too.
+1 Erik, just continue the way you are with the time you have. Diane and you
are doing great with support which is important. There is more value added
to Ant by providing excellent support than a patch.
When you read the comment from bug 5307 which was mainly an explanation of
the issue (it's not critical and there is an easy workaround so patched now
or in a month does not change anything), that really illustrate your point,
user is happy to learn and be listened and ant-dev is happy to have these
nice comments.
------- Additional Comments From christophe.aubry@temis-group.com
2002-02-03 15:33 -------
Thanks for this correction and for your good explanation of the issue...
I'll use your tips in the future (debug and verbose options).
I enjoy working with Apache tools. You really help us having a better
(development) world :)
----------------------
There is no point in exagerating patch support. It's not like a mission
critical app., and we don't have to accept everything to make a kitchen sink
just to please everybody. If someone sent a patch and that's a blocker, than
she is using a workaround or a patched version. If someone sent a task then
she is using that task already. That's not because we make it in build v
02/02/2002 rather than v1.5 final that it will change anything. However it
must be in 'final'.
FWIW I'm running v1.4.1 in my company and did not even patch it to fix the
SQL task problem we were having, even if it was critical at this time for
our deployment we use a workaround, and now it's not needed anymore.
Stephane
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Stefan Bodewig" <bo...@apache.org>
> >> It is easier to add things to Ant than to remove it.
> >
> > +1, with the caveat that it is true only after a release.
>
> So we could go and drop the file attribute of <jar>?
>
>
<http://jakarta.apache.org/builds/gump/2002-02-04/jakarta-avalon-clutil.html
>
>
> ;-)
Yes, we haven't committed to supporting it yet.
That is what alpha code is all about.
It is unfortunate, I accept, but it is just one
of those things.
>
> Stefan
>
Cheers,
Magesh
******************************************
* Father: A banker provided by nature. *
******************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 4 Feb 2002, Magesh Umasankar <um...@apache.org> wrote:
> From: "Stephane Bailliez" <sb...@apache.org>
>> It is easier to add things to Ant than to remove it.
>
> +1, with the caveat that it is true only after a release.
So we could go and drop the file attribute of <jar>?
<http://jakarta.apache.org/builds/gump/2002-02-04/jakarta-avalon-clutil.html>
;-)
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
So what I'm hearing is that we're waiting until after 1.5 is released to
start adding stuff?! :))
(just kidding)
----- Original Message -----
From: "Magesh Umasankar" <um...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Monday, February 04, 2002 10:03 AM
Subject: Re: [SUBMIT] Refactor & combination of mail tasks
> From: "Stephane Bailliez" <sb...@apache.org>
>
> >
> > The sooner the better but we should not confuse
> > speed and hurry. Often several feedback from users
> > really help in finding a more global solution rather
> > than a specific one.
>
> Do the simplest thing that works. If users
> find that itchy, they will scratch it.
>
> > It is easier to add things to Ant than to remove it.
>
> +1, with the caveat that it is true only
> after a release.
>
> >
> > Stephane.
> >
>
> Cheers,
> Magesh
>
> ******************************************************
> * Compromise: The art of dividing a cake in such a *
> * way that everybody believes others too got the *
> * same small size pieces. *
> ******************************************************
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Stephane Bailliez" <sb...@apache.org>
>
> The sooner the better but we should not confuse
> speed and hurry. Often several feedback from users
> really help in finding a more global solution rather
> than a specific one.
Do the simplest thing that works. If users
find that itchy, they will scratch it.
> It is easier to add things to Ant than to remove it.
+1, with the caveat that it is true only
after a release.
>
> Stephane.
>
Cheers,
Magesh
******************************************************
* Compromise: The art of dividing a cake in such a *
* way that everybody believes others too got the *
* same small size pieces. *
******************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Rob Oxspring" <ro...@yahoo.com>
[...]
> Also, applying so many patches close to release dates is surely prone to
> bugs creeping in as patches get only a very short testing period. I know
we
> all get snowed under and the backlog builds up but even if we assume that
a
> 1.5 release isn't going to happen for another month or two, it might be
good
> to purge the backlog now so that the patches get some user testing by the
> ant-dev communiity.
The sooner the better but we should not confuse speed and hurry.
Often several feedback from users really help in finding a more global
solution rather than a specific one.
It is easier to add things to Ant than to remove it.
Stephane.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SUBMIT] Refactor & combination of mail tasks
Posted by Rob Oxspring <ro...@yahoo.com>.
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Monday, February 04, 2002 2:25 AM
> To: Ant Developers List
> Subject: Re: [SUBMIT] Refactor & combination of mail tasks
>
>
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
>
> > Agreed... but most of the folks that have
> > submitted the patches are already running
> > fine with their own custom built version of
> > Ant and aren't in a hurry for it to be rolled
> > into a nightly build.
>
> I have seen quite a few e-mails from the
> contributors in the not-so-distant-past
> which clearly told that they were not
> satisifed with our turn around time. Why
> would they even contribute when their systems
> were already running with their custom
> versions?
Also, applying so many patches close to release dates is surely prone to
bugs creeping in as patches get only a very short testing period. I know we
all get snowed under and the backlog builds up but even if we assume that a
1.5 release isn't going to happen for another month or two, it might be good
to purge the backlog now so that the patches get some user testing by the
ant-dev communiity.
Not a complaint - just a thought,
Rob
> Anyway, I am not arguing here - I understand
> we can get to the patches only upon our own
> timeframes...
>
> > As long as we address the patches prior to a
> > release by either applying them or postponing
> > them for good reason then we're still doing
> > ok, aren't we?
>
> Cause-Effect:
> Fixing a release date and then looking at the
> available patches to meet that date is not better
> than applying existing patches which push for a
> new release.
>
> > I agree its nice to keep up with them regularly
> > if at all possible. Its just not possible for me
> > currently to devote that large of a block of time
> > for practically anything - I'm able to do quick
> > patches and address e-mail support which is important
> > to our collective committer mission too.
>
> Don't get me wrong. I am not imposing on you
> in any way. Forgive me, if I gave that impression.
> I just made a request because you had been involved
> with the code; that is all... And I really really
> know the huge amount of time you spend on ant-dev,
> ant-user, and jguru, which, frankly, I think you
> shouldn't be, lest you burn out :-)
>
> >
> > Erik
> >
>
> Cheers,
> Magesh
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> Agreed... but most of the folks that have
> submitted the patches are already running
> fine with their own custom built version of
> Ant and aren't in a hurry for it to be rolled
> into a nightly build.
I have seen quite a few e-mails from the
contributors in the not-so-distant-past
which clearly told that they were not
satisifed with our turn around time. Why
would they even contribute when their systems
were already running with their custom
versions?
Anyway, I am not arguing here - I understand
we can get to the patches only upon our own
timeframes...
> As long as we address the patches prior to a
> release by either applying them or postponing
> them for good reason then we're still doing
> ok, aren't we?
Cause-Effect:
Fixing a release date and then looking at the
available patches to meet that date is not better
than applying existing patches which push for a
new release.
> I agree its nice to keep up with them regularly
> if at all possible. Its just not possible for me
> currently to devote that large of a block of time
> for practically anything - I'm able to do quick
> patches and address e-mail support which is important
> to our collective committer mission too.
Don't get me wrong. I am not imposing on you
in any way. Forgive me, if I gave that impression.
I just made a request because you had been involved
with the code; that is all... And I really really
know the huge amount of time you spend on ant-dev,
ant-user, and jguru, which, frankly, I think you
shouldn't be, lest you burn out :-)
>
> Erik
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
From: "Magesh Umasankar" <um...@apache.org>
> IMHO, if we apply the good patches, that come
> our way, regularly, it will keep the contributors
> motivated.
Agreed... but most of the folks that have submitted the patches are already
running fine with their own custom built version of Ant and aren't in a
hurry for it to be rolled into a nightly build. As long as we address the
patches prior to a release by either applying them or postponing them for
good reason then we're still doing ok, aren't we?
I agree its nice to keep up with them regularly if at all possible. Its just
not possible for me currently to devote that large of a block of time for
practically anything - I'm able to do quick patches and address e-mail
support which is important to our collective committer mission too.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 4 Feb 2002, Adam Murdoch <ad...@yahoo.com> wrote:
> * What do we do with the <mimemail> task? Deprecate it?
+1
> * The refactored task is in a new package (taskdefs.email). Do we
> need to keep the old task classes hanging around?
Probably yes. There could be people that extend from it.
> * The current <mail> task ignores the message attribute if one or
> more files are specified. Is this a bug?
If we call it a bug, we can change the behavior without breaking
backwards compatibility ;-)
Honestly, I don't know.
> * Any problems with making the default mime, uuencode, plain in that
> order?
+1 for doing it that way (we could throw in an option for preferred
encoding).
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Adam Murdoch" <ad...@yahoo.com>
> Some backward-compatibility questions:
>
> * What do we do with the <mimemail> task? Deprecate it?
+1
> * The refactored task is in a new package (taskdefs.email). Do we need to
> keep the old task classes hanging around?
+0, but someone already said we should for backwards compatibility.
> * The current <mail> task ignores the message attribute if one or more
files
> are specified. Is this a bug? The refactored task always includes the
> message if one is present. Any problems with going with the new
behaviour?
No problems going to the new behavior from me. Then again, I don't use
<mail> :)
> * By default, the refactored task will use mime or uuencode encoding, in
> favour of plain encoding. To be strictly backwards-compatible it should
> default to plain, regardless of what encoders are present. Seems a bit
> pedantic, really. Any problems with making the default mime, uuencode,
> plain in that order?
Sounds good to me.
Thanks for helping out on this one. Ain't it great to do Ant 1.x
development now?! :)
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Adam Murdoch" <ad...@yahoo.com>
> Some backward-compatibility questions:
>
> * What do we do with the <mimemail> task? Deprecate it?
+1
> * The refactored task is in a new package
> (taskdefs.email). Do we need to keep the old
> task classes hanging around?
Yes. Maybe change them to invoke the new class's
code, if possible?
> * The current <mail> task ignores the message
> attribute if one or more files are specified.
> Is this a bug? The refactored task always
> includes the message if one is present. Any
> problems with going with the new behaviour?
No problems with using the new behavior. Instead
of terming the existing one a bug, I would term
the new one a feature ;-)
> * By default, the refactored task will use mime
> or uuencode encoding, in favour of plain encoding.
> To be strictly backwards-compatible it should
> default to plain, regardless of what encoders are
> present. Seems a bit pedantic, really. Any
> problems with making the default mime, uuencode,
> plain in that order?
+1
>
> Adam
>
Cheers,
Magesh
*************************************************
* Politician: One who shakes your hand before *
* elections and your confidence after. *
*************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SUBMIT] Refactor & combination of mail tasks
Posted by Adam Murdoch <ad...@yahoo.com>.
Hi,
Some backward-compatibility questions:
* What do we do with the <mimemail> task? Deprecate it?
* The refactored task is in a new package (taskdefs.email). Do we need to
keep the old task classes hanging around?
* The current <mail> task ignores the message attribute if one or more files
are specified. Is this a bug? The refactored task always includes the
message if one is present. Any problems with going with the new behaviour?
* By default, the refactored task will use mime or uuencode encoding, in
favour of plain encoding. To be strictly backwards-compatible it should
default to plain, regardless of what encoders are present. Seems a bit
pedantic, really. Any problems with making the default mime, uuencode,
plain in that order?
Adam
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Monday, 4 February 2002 12:07 PM
> To: Ant Developers List
> Subject: Re: [SUBMIT] Refactor & combination of mail tasks
>
>
> From: "Adam Murdoch" <ad...@yahoo.com>
>
> >
> > Hi,
> >
> > I can look at applying this if you like.
>
> Please... Thanks, and I appreciate you
> volunteering.
>
> >
> > Adam
> >
>
> Cheers,
> Magesh
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Adam Murdoch" <ad...@yahoo.com>
>
> Hi,
>
> I can look at applying this if you like.
Please... Thanks, and I appreciate you
volunteering.
>
> Adam
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Have at it! :)
Thanks Adam - great to have you on board.
Erik
----- Original Message -----
From: "Adam Murdoch" <ad...@yahoo.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Sunday, February 03, 2002 8:38 PM
Subject: RE: [SUBMIT] Refactor & combination of mail tasks
>
> Hi,
>
> I can look at applying this if you like.
>
>
> Adam
>
> > -----Original Message-----
> > From: Magesh Umasankar [mailto:umagesh@apache.org]
> > Sent: Monday, 4 February 2002 11:24 AM
> > To: Ant Developers List
> > Subject: Re: [SUBMIT] Refactor & combination of mail tasks
> >
> >
> > From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> >
> > > Is it in Bugzilla?
> >
> > No, it is there as a patch request on my disk ;-)
> >
> > > I don't have the bandwidth right now to do
> > > this particular refactoring justice (it would
> > > take several hours of my time at least).
> >
> > Sigh. ok, I understand. I will wait to hear
> > from Steve. Depending upon that, I may or may
> > not dive in to patch this myself.
> >
> > > Is there an urgent need for it?
> >
> > I don't want ant-dev to lose any more developers
> > who make the extra effort to contribute something
> > back. 0:-)
> >
> > IMHO, if we apply the good patches, that come
> > our way, regularly, it will keep the contributors
> > motivated.
> >
> > > If not, lets just put it in Bugzilla as an
> > > enhancement request.
> >
> >
> > >
> > > Erik
> >
> > Cheers,
> > Magesh
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SUBMIT] Refactor & combination of mail tasks
Posted by Adam Murdoch <ad...@yahoo.com>.
Hi,
I can look at applying this if you like.
Adam
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Monday, 4 February 2002 11:24 AM
> To: Ant Developers List
> Subject: Re: [SUBMIT] Refactor & combination of mail tasks
>
>
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
>
> > Is it in Bugzilla?
>
> No, it is there as a patch request on my disk ;-)
>
> > I don't have the bandwidth right now to do
> > this particular refactoring justice (it would
> > take several hours of my time at least).
>
> Sigh. ok, I understand. I will wait to hear
> from Steve. Depending upon that, I may or may
> not dive in to patch this myself.
>
> > Is there an urgent need for it?
>
> I don't want ant-dev to lose any more developers
> who make the extra effort to contribute something
> back. 0:-)
>
> IMHO, if we apply the good patches, that come
> our way, regularly, it will keep the contributors
> motivated.
>
> > If not, lets just put it in Bugzilla as an
> > enhancement request.
>
>
> >
> > Erik
>
> Cheers,
> Magesh
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> Is it in Bugzilla?
No, it is there as a patch request on my disk ;-)
> I don't have the bandwidth right now to do
> this particular refactoring justice (it would
> take several hours of my time at least).
Sigh. ok, I understand. I will wait to hear
from Steve. Depending upon that, I may or may
not dive in to patch this myself.
> Is there an urgent need for it?
I don't want ant-dev to lose any more developers
who make the extra effort to contribute something
back. 0:-)
IMHO, if we apply the good patches, that come
our way, regularly, it will keep the contributors
motivated.
> If not, lets just put it in Bugzilla as an
> enhancement request.
>
> Erik
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Is it in Bugzilla? I don't have the bandwidth right now to do this
particular refactoring justice (it would take several hours of my time at
least). Is there an urgent need for it? If not, lets just put it in
Bugzilla as an enhancement request.
Erik
----- Original Message -----
From: "Magesh Umasankar" <um...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Sunday, February 03, 2002 5:38 PM
Subject: Re: [SUBMIT] Refactor & combination of mail tasks
> Erik/Steve:
>
> Will one of you please take care of this?
>
> http://marc.theaimsgroup.com/?t=100802277000004&r=1&w=2
>
> Cheers,
> Magesh
>
> ----- Original Message -----
> From: "Rob Oxspring" <ro...@yahoo.com>
> To: <an...@jakarta.apache.org>
> Sent: Monday, December 10, 2001 5:18 PM
> Subject: [SUBMIT] Refactor & combination of mail tasks
>
>
> > Hi all,
> >
> > A while back (possibly when MimeMail was submitted) it was suggested
that
> > the mail tasks should be integrated into one, using some reflection to
> > attempt to use JavaMail. Recently I had a desire to send some binary
> > attachments but didn't want to have to install JavaMail on every
developer
> > workstation and so UU encoding was hit upon.
> >
> > The upshot of all this was that I've integrated the three encoding
formats
> > into a single task using JavaMail if available or uu encoding (via
> > sun.misc.UUEncoder - presumably available to any sun based JDK?).
> >
> > It should be possible to drop in the new task where the old one was used
> and
> > not notice the difference.
> >
> > <project name="emailtest" default="main">
> > <target name="main">
> > <mail message="My message"
> > subject="Ant Submission Test">
> >
> > <from name="From Rob" address="abc@xyz.com"/>
> > <to name="To Rob" address="xyz@abc.com"/>
> > <fileset dir=".">
> > <include name="*.xml"/>
> > </fileset>
> > </mail>
> > </target>
> > </project>
> >
> > Magesh: your includefilenames patch caught me mid flow so I've tried to
> > patch it in but would appreciate it if you would have a quick check that
> > things are coming out OK. Only the PlainMailer is affected by this
> > attribute since I didn't know how best to add it into the other formats.
> >
> > Todo: Probably could find / implement uu encoding but Sun's solution was
> > handy and did the trick for now.
> >
> > Now if things run true to form I'll be back in touch in five minutes as
I
> > spot some daft mistake but in the meantime if others could eyeball it
too
> it
> > would be appreciated.
> >
> > Hope its deemed good enough...
> >
> > Rob
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Magesh Umasankar <um...@apache.org>.
From: "Rob Oxspring" <ro...@yahoo.com>
> Sorry - I took my eye off the "backwards
> compatability" ball on this one, I think
> the change to EmailTask below should fix it.
>
> Was busy thinking about what it should do
> in the face of an absent message rather than
> what the previous version did.
>
> 444 // a valid message is required
> 445 if( message == null )
> 446 {
> 447 throw new BuildException( "A message is required" );
> 448 }
>
> Changing line 447 to the following should fix it, but I'm heading to bed
> also so I haven't tried it.
> 447 message = new Message();
>
I have committed this change. Thanks.
> Cheers
>
> Rob
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SUBMIT] Refactor & combination of mail tasks
Posted by Rob Oxspring <ro...@yahoo.com>.
Sorry - I took my eye off the "backwards compatability" ball on this one, I
think the change to EmailTask below should fix it.
Was busy thinking about what it should do in the face of an absent message
rather than what the previous version did.
444 // a valid message is required
445 if( message == null )
446 {
447 throw new BuildException( "A message is required" );
448 }
Changing line 447 to the following should fix it, but I'm heading to bed
also so I haven't tried it.
447 message = new Message();
Cheers
Rob
> -----Original Message-----
> From: Stephane Bailliez [mailto:sbailliez@apache.org]
> Sent: Wednesday, February 06, 2002 12:25 AM
> To: Ant Developers List
> Subject: Re: [SUBMIT] Refactor & combination of mail tasks
>
>
> ----- Original Message -----
> From: "Adam Murdoch" <ad...@yahoo.com>
> [...]
>
> > This has been committed. Thanks, Rob.
>
> Just a note, there is a backward incompatibility somewhere, did not go
> deeper, it's time for me to go to bed, sorry :-(
> I ran the audit/metric/coverage with an Ant snapshot and my Ant
> build failed
> because I was using mail this way:
>
> <mail from="${mail.from}" tolist="${mail.to}" mailhost="${mail.host}"
> subject="${mail.subject}" files="${mail.file}"/>
>
>
> sendmail:
> [mail] Failed to initialise MIME mail
> [mail] Failed to send email
>
> BUILD FAILED
> D:\projects\audit\build.xml:127: A message is required
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SUBMIT] Refactor & combination of mail tasks
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Adam Murdoch" <ad...@yahoo.com>
[...]
> This has been committed. Thanks, Rob.
Just a note, there is a backward incompatibility somewhere, did not go
deeper, it's time for me to go to bed, sorry :-(
I ran the audit/metric/coverage with an Ant snapshot and my Ant build failed
because I was using mail this way:
<mail from="${mail.from}" tolist="${mail.to}" mailhost="${mail.host}"
subject="${mail.subject}" files="${mail.file}"/>
sendmail:
[mail] Failed to initialise MIME mail
[mail] Failed to send email
BUILD FAILED
D:\projects\audit\build.xml:127: A message is required
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SUBMIT] Refactor & combination of mail tasks
Posted by Adam Murdoch <ad...@yahoo.com>.
Hi,
This has been committed. Thanks, Rob.
Adam
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Monday, 4 February 2002 8:38 AM
> To: Ant Developers List
> Subject: Re: [SUBMIT] Refactor & combination of mail tasks
>
>
> Erik/Steve:
>
> Will one of you please take care of this?
>
> http://marc.theaimsgroup.com/?t=100802277000004&r=1&w=2
>
> Cheers,
> Magesh
>
> ----- Original Message -----
> From: "Rob Oxspring" <ro...@yahoo.com>
> To: <an...@jakarta.apache.org>
> Sent: Monday, December 10, 2001 5:18 PM
> Subject: [SUBMIT] Refactor & combination of mail tasks
>
>
> > Hi all,
> >
> > A while back (possibly when MimeMail was submitted) it was
> suggested that
> > the mail tasks should be integrated into one, using some reflection to
> > attempt to use JavaMail. Recently I had a desire to send some binary
> > attachments but didn't want to have to install JavaMail on
> every developer
> > workstation and so UU encoding was hit upon.
> >
> > The upshot of all this was that I've integrated the three
> encoding formats
> > into a single task using JavaMail if available or uu encoding (via
> > sun.misc.UUEncoder - presumably available to any sun based JDK?).
> >
> > It should be possible to drop in the new task where the old one was used
> and
> > not notice the difference.
> >
> > <project name="emailtest" default="main">
> > <target name="main">
> > <mail message="My message"
> > subject="Ant Submission Test">
> >
> > <from name="From Rob" address="abc@xyz.com"/>
> > <to name="To Rob" address="xyz@abc.com"/>
> > <fileset dir=".">
> > <include name="*.xml"/>
> > </fileset>
> > </mail>
> > </target>
> > </project>
> >
> > Magesh: your includefilenames patch caught me mid flow so I've tried to
> > patch it in but would appreciate it if you would have a quick check that
> > things are coming out OK. Only the PlainMailer is affected by this
> > attribute since I didn't know how best to add it into the other formats.
> >
> > Todo: Probably could find / implement uu encoding but Sun's solution was
> > handy and did the trick for now.
> >
> > Now if things run true to form I'll be back in touch in five
> minutes as I
> > spot some daft mistake but in the meantime if others could
> eyeball it too
> it
> > would be appreciated.
> >
> > Hope its deemed good enough...
> >
> > Rob
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>