You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2012/12/10 23:28:46 UTC
[VOTE] Release of commons-email-1.3 based on RC4
Hi,
I would like to call a vote from commons-email-1.3 based on RC4.
The files:
The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-135/
The tag:
http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
The site:
http://people.apache.org/builds/commons/email/1.3/RC4/
Additional Notes:
o the RC is binary compatible to commons-email-1.2 whereas the
remaining Clirr warnings stem from moving constants to an interface
and have already been verified to not break BC.
o source / binary compatibility has been upgraded to JDK 1.5
Please take a look at the commons-email-1.3 artifacts and vote!
------------------------------------------------
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
------------------------------------------------
Vote will remain open for at least 72 hours.
Thanks in advance,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 10 December 2012 22:28, Thomas Neidhart <th...@gmail.com> wrote:
> Hi,
>
> I would like to call a vote from commons-email-1.3 based on RC4.
>
> The files:
>
> The artifacts are deployed to Nexus:
> https://repository.apache.org/content/repositories/orgapachecommons-135/
>
> The tag:
> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
3 files have $Date$ SVN keywords in them, so the SVN tag will be
different from the source archive when downloaded in a different
timezone from the RM.
Not a blocker, but should be fixed before any further release vote.
The release notes don't mention the Clirr errors and why they are
false positives.
I think the fact that the release now requires Java 1.5 should be made
more prominent.
> The site:
> http://people.apache.org/builds/commons/email/1.3/RC4/
>
> Additional Notes:
>
> o the RC is binary compatible to commons-email-1.2 whereas the
> remaining Clirr warnings stem from moving constants to an interface
> and have already been verified to not break BC.
> o source / binary compatibility has been upgraded to JDK 1.5
>
> Please take a look at the commons-email-1.3 artifacts and vote!
>
> ------------------------------------------------
> [ ] +1 release it
> [X] +0 go ahead I don't care
> [ ] -1 no, do not release it because
> ------------------------------------------------
>
> Vote will remain open for at least 72 hours.
>
> Thanks in advance,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
On the same page under "Development", is all this info up to date?
Gary
On Mon, Dec 10, 2012 at 9:53 PM, Gary Gregory <ga...@gmail.com>wrote:
> This page is wrong:
>
> https://people.apache.org/builds/commons/email/1.3/RC4/building.html
>
> "You must be using JDK 1.4 or higher to successfully complete this target."
>
> The text should read "JDK 5".
>
> Gary
>
>
> On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart <
> thomas.neidhart@gmail.com> wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC4.
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>> https://repository.apache.org/content/repositories/orgapachecommons-135/
>>
>> The tag:
>> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>>
>> The site:
>> http://people.apache.org/builds/commons/email/1.3/RC4/
>>
>> Additional Notes:
>>
>> o the RC is binary compatible to commons-email-1.2 whereas the
>> remaining Clirr warnings stem from moving constants to an interface
>> and have already been verified to not break BC.
>> o source / binary compatibility has been upgraded to JDK 1.5
>>
>> Please take a look at the commons-email-1.3 artifacts and vote!
>>
>> ------------------------------------------------
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>> ------------------------------------------------
>>
>> Vote will remain open for at least 72 hours.
>>
>> Thanks in advance,
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
This page is wrong:
https://people.apache.org/builds/commons/email/1.3/RC4/building.html
"You must be using JDK 1.4 or higher to successfully complete this target."
The text should read "JDK 5".
Gary
On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
<th...@gmail.com>wrote:
> Hi,
>
> I would like to call a vote from commons-email-1.3 based on RC4.
>
> The files:
>
> The artifacts are deployed to Nexus:
> https://repository.apache.org/content/repositories/orgapachecommons-135/
>
> The tag:
> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>
> The site:
> http://people.apache.org/builds/commons/email/1.3/RC4/
>
> Additional Notes:
>
> o the RC is binary compatible to commons-email-1.2 whereas the
> remaining Clirr warnings stem from moving constants to an interface
> and have already been verified to not break BC.
> o source / binary compatibility has been upgraded to JDK 1.5
>
> Please take a look at the commons-email-1.3 artifacts and vote!
>
> ------------------------------------------------
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
> ------------------------------------------------
>
> Vote will remain open for at least 72 hours.
>
> Thanks in advance,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Siegfried Goeschl <sg...@gmx.at>.
Unfortunately I do remember ... :-(
Siegfried Goeschl
On 11.12.12 22:08, Mark Struberg wrote:
> we had this over here at UPC as well. This did cost Sigi a release as well if you remember ;)
>
> Most times this can be disabled by your provider. Just phone them and explain that they are breaking your computer and this creates costs by them not acting standard conform ;)
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: sebb <se...@gmail.com>
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc:
>> Sent: Tuesday, December 11, 2012 9:18 PM
>> Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
>>
>> On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 11 December 2012 08:58, Thomas Neidhart
>> <th...@gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > thanks for looking into it.
>>>> >
>>>> > I will fix the issues wrt build page, release notes and findbugs
>>>> warnings.
>>>> >
>>>> > Regarding the unit test failure:
>>>> >
>>>> > I have not seen the problem before, and just validated it. The
>> unit test
>>>> > tries to open a connection to an invalid url:
>> http://example.invalid
>>>> > For some reason this seems to succeed in your environment. Could
>> it be
>>>> that
>>>> > you have a custom hosts entry for this domain?
>>>>
>>>> Or it could be a faulty DNS server.
>>>>
>>>> I used to have this exact problem with the OpenDNS server.
>>>> They resolve unknown hosts to their home page (extra advertising).
>>>> They used to do this for *.invalid as well, but after years of
>>>> complaints that this behaviour was contrary to the RFC they fixed the
>>>> issue.
>>>>
>>>> Try pinging example.invalid and then do an nslookup on the IP address.
>>>>
>>>
>>> That is what Cox must be doing indeed:
>>>
>>> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
>>> Request timed out.
>>> Request timed out.
>>> Request timed out.
>>> My browser redirects this IP to http://finder.cox.net/dnserror.html
>>
>> So Cox are violating the RFC.
>>
>> Perhaps you could direct them to the relevant RFC:
>>
>> There are several TLD names which are reserved by RFC 2606, section 2.
>> Amongst them is the TLD "invalid".
>>
>> <quote>
>> ".invalid" is intended for use in online construction of domain
>> names that are sure to be invalid and which it is obvious at a
>> glance are invalid.
>> </quote>
>>
>> Note the phrase "that are sure to be invalid".
>> An invalid domain name cannot have an IP address.
>> No DNS server should ever resolve addresses in the TLD "invalid".
>>
>>> Gary
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Mark Struberg <st...@yahoo.de>.
we had this over here at UPC as well. This did cost Sigi a release as well if you remember ;)
Most times this can be disabled by your provider. Just phone them and explain that they are breaking your computer and this creates costs by them not acting standard conform ;)
LieGrue,
strub
----- Original Message -----
> From: sebb <se...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Tuesday, December 11, 2012 9:18 PM
> Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
>
> On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 11 December 2012 08:58, Thomas Neidhart
> <th...@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > thanks for looking into it.
>>> >
>>> > I will fix the issues wrt build page, release notes and findbugs
>>> warnings.
>>> >
>>> > Regarding the unit test failure:
>>> >
>>> > I have not seen the problem before, and just validated it. The
> unit test
>>> > tries to open a connection to an invalid url:
> http://example.invalid
>>> > For some reason this seems to succeed in your environment. Could
> it be
>>> that
>>> > you have a custom hosts entry for this domain?
>>>
>>> Or it could be a faulty DNS server.
>>>
>>> I used to have this exact problem with the OpenDNS server.
>>> They resolve unknown hosts to their home page (extra advertising).
>>> They used to do this for *.invalid as well, but after years of
>>> complaints that this behaviour was contrary to the RFC they fixed the
>>> issue.
>>>
>>> Try pinging example.invalid and then do an nslookup on the IP address.
>>>
>>
>> That is what Cox must be doing indeed:
>>
>> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
>> Request timed out.
>> Request timed out.
>> Request timed out.
>> My browser redirects this IP to http://finder.cox.net/dnserror.html
>
> So Cox are violating the RFC.
>
> Perhaps you could direct them to the relevant RFC:
>
> There are several TLD names which are reserved by RFC 2606, section 2.
> Amongst them is the TLD "invalid".
>
> <quote>
> ".invalid" is intended for use in online construction of domain
> names that are sure to be invalid and which it is obvious at a
> glance are invalid.
> </quote>
>
> Note the phrase "that are sure to be invalid".
> An invalid domain name cannot have an IP address.
> No DNS server should ever resolve addresses in the TLD "invalid".
>
>> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>
>> On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > thanks for looking into it.
>> >
>> > I will fix the issues wrt build page, release notes and findbugs
>> warnings.
>> >
>> > Regarding the unit test failure:
>> >
>> > I have not seen the problem before, and just validated it. The unit test
>> > tries to open a connection to an invalid url: http://example.invalid
>> > For some reason this seems to succeed in your environment. Could it be
>> that
>> > you have a custom hosts entry for this domain?
>>
>> Or it could be a faulty DNS server.
>>
>> I used to have this exact problem with the OpenDNS server.
>> They resolve unknown hosts to their home page (extra advertising).
>> They used to do this for *.invalid as well, but after years of
>> complaints that this behaviour was contrary to the RFC they fixed the
>> issue.
>>
>> Try pinging example.invalid and then do an nslookup on the IP address.
>>
>
> That is what Cox must be doing indeed:
>
> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
> Request timed out.
> Request timed out.
> Request timed out.
> My browser redirects this IP to http://finder.cox.net/dnserror.html
So Cox are violating the RFC.
Perhaps you could direct them to the relevant RFC:
There are several TLD names which are reserved by RFC 2606, section 2.
Amongst them is the TLD "invalid".
<quote>
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
</quote>
Note the phrase "that are sure to be invalid".
An invalid domain name cannot have an IP address.
No DNS server should ever resolve addresses in the TLD "invalid".
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
> On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com>
> wrote:
> > Hi,
> >
> > thanks for looking into it.
> >
> > I will fix the issues wrt build page, release notes and findbugs
> warnings.
> >
> > Regarding the unit test failure:
> >
> > I have not seen the problem before, and just validated it. The unit test
> > tries to open a connection to an invalid url: http://example.invalid
> > For some reason this seems to succeed in your environment. Could it be
> that
> > you have a custom hosts entry for this domain?
>
> Or it could be a faulty DNS server.
>
> I used to have this exact problem with the OpenDNS server.
> They resolve unknown hosts to their home page (extra advertising).
> They used to do this for *.invalid as well, but after years of
> complaints that this behaviour was contrary to the RFC they fixed the
> issue.
>
> Try pinging example.invalid and then do an nslookup on the IP address.
>
That is what Cox must be doing indeed:
Pinging example.invalid [72.215.225.9] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
My browser redirects this IP to http://finder.cox.net/dnserror.html
Gary
>
> > Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com> wrote:
> Hi,
>
> thanks for looking into it.
>
> I will fix the issues wrt build page, release notes and findbugs warnings.
>
> Regarding the unit test failure:
>
> I have not seen the problem before, and just validated it. The unit test
> tries to open a connection to an invalid url: http://example.invalid
> For some reason this seems to succeed in your environment. Could it be that
> you have a custom hosts entry for this domain?
Or it could be a faulty DNS server.
I used to have this exact problem with the OpenDNS server.
They resolve unknown hosts to their home page (extra advertising).
They used to do this for *.invalid as well, but after years of
complaints that this behaviour was contrary to the RFC they fixed the
issue.
Try pinging example.invalid and then do an nslookup on the IP address.
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Thomas Neidhart <th...@gmail.com>.
Hi,
thanks for looking into it.
I will fix the issues wrt build page, release notes and findbugs warnings.
Regarding the unit test failure:
I have not seen the problem before, and just validated it. The unit test
tries to open a connection to an invalid url: http://example.invalid
For some reason this seems to succeed in your environment. Could it be that
you have a custom hosts entry for this domain?
Thomas
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
I downloaded the tag and ran "mvn clean site" and got 4 test failures:
Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.902 sec
<<< FAILURE!
testEmbedUrl(org.apache.commons.mail.HtmlEmailTest) Time elapsed: 4505
sec <<< FAILURE!
junit.framework.AssertionFailedError: Should have thrown an exception
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.commons.mail.HtmlEmailTest.testEmbedUrl(HtmlEmailTest.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Running org.apache.commons.mail.ImageHtmlEmailTest
Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.008 sec
<<< FAILURE!
testEmbedUrl(org.apache.commons.mail.ImageHtmlEmailTest) Time elapsed: 66
sec <<< FAILURE!
junit.framework.AssertionFailedError: Should have thrown an exception
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.commons.mail.HtmlEmailTest.testEmbedUrl(HtmlEmailTest.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Running org.apache.commons.mail.InvalidAddressTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.mail.InvalidInternetAddressTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.commons.mail.MultiPartEmailTest
Tests run: 11, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.16 sec
<<< FAILURE!
testAttach3(org.apache.commons.mail.MultiPartEmailTest) Time elapsed: 70
sec <<< FAILURE!
junit.framework.AssertionFailedError: Should have thrown an exception
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.commons.mail.MultiPartEmailTest.testAttach3(MultiPartEmailTest.java:322)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
testAttach(org.apache.commons.mail.MultiPartEmailTest) Time elapsed: 55
sec <<< FAILURE!
junit.framework.AssertionFailedError: Should have thrown an exception
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.commons.mail.MultiPartEmailTest.testAttach(MultiPartEmailTest.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
My set up:
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_35\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Gary
On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
<th...@gmail.com>wrote:
> Hi,
>
> I would like to call a vote from commons-email-1.3 based on RC4.
>
> The files:
>
> The artifacts are deployed to Nexus:
> https://repository.apache.org/content/repositories/orgapachecommons-135/
>
> The tag:
> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>
> The site:
> http://people.apache.org/builds/commons/email/1.3/RC4/
>
> Additional Notes:
>
> o the RC is binary compatible to commons-email-1.2 whereas the
> remaining Clirr warnings stem from moving constants to an interface
> and have already been verified to not break BC.
> o source / binary compatibility has been upgraded to JDK 1.5
>
> Please take a look at the commons-email-1.3 artifacts and vote!
>
> ------------------------------------------------
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
> ------------------------------------------------
>
> Vote will remain open for at least 72 hours.
>
> Thanks in advance,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Thomas Neidhart <th...@gmail.com>.
On 12/11/2012 02:07 AM, Gary Gregory wrote:
> On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
> <th...@gmail.com>wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC4.
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>> https://repository.apache.org/content/repositories/orgapachecommons-135/
>>
>> The tag:
>> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>>
>> The site:
>> http://people.apache.org/builds/commons/email/1.3/RC4/
>>
>
> This statement is misleading IMO: "The latest version v1.3, is JDK 1.5
> compatible"
>
> It should be: "The latest version, 1.3, requires Java 5"
>
> I agree with Sebb on the other points.
>
> Fixing the PMD issues seems easy while you are in there. The "Avoid empty
> catch blocks" are clearly false positives.
>
> Any reason why javax.mail/mail 1.4.4 is used instead of 1.4.5?
I guess it is safe to update, but I was unsure before so I left it at
1.4.4. So I do not have a reason not to update ;-).
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 10, 2012 at 9:10 PM, sebb <se...@gmail.com> wrote:
> On 11 December 2012 01:07, Gary Gregory <ga...@gmail.com> wrote:
> > On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
> > <th...@gmail.com>wrote:
> >
> >> Hi,
> >>
> >> I would like to call a vote from commons-email-1.3 based on RC4.
> >>
> >> The files:
> >>
> >> The artifacts are deployed to Nexus:
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-135/
> >>
> >> The tag:
> >> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>
This is not the tag, it's a ViewVc URL.
Gary
> >>
> >> The site:
> >> http://people.apache.org/builds/commons/email/1.3/RC4/
> >>
> >
> > This statement is misleading IMO: "The latest version v1.3, is JDK 1.5
> > compatible"
> >
> > It should be: "The latest version, 1.3, requires Java 5"
> >
> > I agree with Sebb on the other points.
> >
> > Fixing the PMD issues seems easy while you are in there. The "Avoid empty
> > catch blocks" are clearly false positives.
> >
> > Any reason why javax.mail/mail 1.4.4 is used instead of 1.4.5?
> >
> > WRT FindBugs, this one looks like it needs fixing or documenting:
> >
> https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/util/MimeMessageUtils.html#130
>
> The Javadoc already says it uses the default encoding, and there is an
> alternate method that takes an InputStream.
>
> So I think it would be sufficient to suppress the Findbugs warning.
>
> > WRT the 1st FindBugs issue
> >
> https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/EmailException.html#105I
> > do not know, it seems like that code is pretty generic. Would passing
> > in
> > a Charset or charset name be appropriate?
> >
> > +0
> >
> > Gary
> >
> > Additional Notes:
> >>
> >> o the RC is binary compatible to commons-email-1.2 whereas the
> >> remaining Clirr warnings stem from moving constants to an interface
> >> and have already been verified to not break BC.
> >> o source / binary compatibility has been upgraded to JDK 1.5
> >>
> >> Please take a look at the commons-email-1.3 artifacts and vote!
> >>
> >> ------------------------------------------------
> >> [ ] +1 release it
> >> [ ] +0 go ahead I don't care
> >> [ ] -1 no, do not release it because
> >> ------------------------------------------------
> >>
> >> Vote will remain open for at least 72 hours.
> >>
> >> Thanks in advance,
> >>
> >> Thomas
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 11 December 2012 01:07, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
> <th...@gmail.com>wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC4.
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>> https://repository.apache.org/content/repositories/orgapachecommons-135/
>>
>> The tag:
>> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>>
>> The site:
>> http://people.apache.org/builds/commons/email/1.3/RC4/
>>
>
> This statement is misleading IMO: "The latest version v1.3, is JDK 1.5
> compatible"
>
> It should be: "The latest version, 1.3, requires Java 5"
>
> I agree with Sebb on the other points.
>
> Fixing the PMD issues seems easy while you are in there. The "Avoid empty
> catch blocks" are clearly false positives.
>
> Any reason why javax.mail/mail 1.4.4 is used instead of 1.4.5?
>
> WRT FindBugs, this one looks like it needs fixing or documenting:
> https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/util/MimeMessageUtils.html#130
The Javadoc already says it uses the default encoding, and there is an
alternate method that takes an InputStream.
So I think it would be sufficient to suppress the Findbugs warning.
> WRT the 1st FindBugs issue
> https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/EmailException.html#105I
> do not know, it seems like that code is pretty generic. Would passing
> in
> a Charset or charset name be appropriate?
>
> +0
>
> Gary
>
> Additional Notes:
>>
>> o the RC is binary compatible to commons-email-1.2 whereas the
>> remaining Clirr warnings stem from moving constants to an interface
>> and have already been verified to not break BC.
>> o source / binary compatibility has been upgraded to JDK 1.5
>>
>> Please take a look at the commons-email-1.3 artifacts and vote!
>>
>> ------------------------------------------------
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>> ------------------------------------------------
>>
>> Vote will remain open for at least 72 hours.
>>
>> Thanks in advance,
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 10, 2012 at 5:28 PM, Thomas Neidhart
<th...@gmail.com>wrote:
> Hi,
>
> I would like to call a vote from commons-email-1.3 based on RC4.
>
> The files:
>
> The artifacts are deployed to Nexus:
> https://repository.apache.org/content/repositories/orgapachecommons-135/
>
> The tag:
> http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC4/
>
> The site:
> http://people.apache.org/builds/commons/email/1.3/RC4/
>
This statement is misleading IMO: "The latest version v1.3, is JDK 1.5
compatible"
It should be: "The latest version, 1.3, requires Java 5"
I agree with Sebb on the other points.
Fixing the PMD issues seems easy while you are in there. The "Avoid empty
catch blocks" are clearly false positives.
Any reason why javax.mail/mail 1.4.4 is used instead of 1.4.5?
WRT FindBugs, this one looks like it needs fixing or documenting:
https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/util/MimeMessageUtils.html#130
WRT the 1st FindBugs issue
https://people.apache.org/builds/commons/email/1.3/RC4/xref/org/apache/commons/mail/EmailException.html#105I
do not know, it seems like that code is pretty generic. Would passing
in
a Charset or charset name be appropriate?
+0
Gary
Additional Notes:
>
> o the RC is binary compatible to commons-email-1.2 whereas the
> remaining Clirr warnings stem from moving constants to an interface
> and have already been verified to not break BC.
> o source / binary compatibility has been upgraded to JDK 1.5
>
> Please take a look at the commons-email-1.3 artifacts and vote!
>
> ------------------------------------------------
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
> ------------------------------------------------
>
> Vote will remain open for at least 72 hours.
>
> Thanks in advance,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory