To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-jaxme has an issue affecting its community
integration.
This
I have performed some of the changes proposed by Michael. Here is a summary of
the svn log messages:
- AbstractEstimator:
improved SOC between AbstractEstimator and its derived classes
(changed fields from protected to private, changed methods to final,
added counter incrementation final method)
The changes I commited 5 days ago for r620289 introduced lots of javadocs
errors. They add a link to the addValue(double[]) method which is defined in the
implementing class, not in the interface.
What would be the best fix: change all the javadoc comments or push the method
up in the interface ?
In 15/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: ebourg
> Date: Fri Feb 15 03:31:07 2008
> New Revision: 628021
>
> URL: http://svn.apache.org/viewvc?rev=628021&view=rev
> Log:
> The calendar objects are now formatted with their own time zone
> Removed the Java 1.3 workar
sebb a écrit :
BTW, SimpleDateFormat is not synchronized, so having package-protected
instances (whether static or not) may cause problems if the class is
intended for multithreaded use.
I made so the usage of the static DateFormat is synchronized. The
instance DateFormat isn't synchronized b
On 15/02/2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> sebb a écrit :
>
>
> > BTW, SimpleDateFormat is not synchronized, so having package-protected
> > instances (whether static or not) may cause problems if the class is
> > intended for multithreaded use.
>
>
> I made so the usage of the s
sebb a écrit :
The static DateFormat is not private, so the synchronization is not guaranteed.
I'll make it private. I added a comment mentioning that it must be
synchronized.
Likewise the instance DateFormat.
Indeed that is worse, since the format is temporarily changed by the
private m
On 15/02/2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> sebb a écrit :
>
>
> > The static DateFormat is not private, so the synchronization is not
> guaranteed.
>
>
> I'll make it private. I added a comment mentioning that it must be
> synchronized.
>
>
>
> > Likewise the instance DateFormat
Perhaps you could refactor your class a bit to make it more
unit-testable. I've found rare occasions in the past where I had to
expose a member variable to test cases, but for the most part, I could
work around it by redesigning my class a bit. Is that possible in
this case?
On 2/15/08, sebb <[E
James Carman a écrit :
Perhaps you could refactor your class a bit to make it more
unit-testable. I've found rare occasions in the past where I had to
expose a member variable to test cases, but for the most part, I could
work around it by redesigning my class a bit. Is that possible in
this ca
On 2/15/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The changes I commited 5 days ago for r620289 introduced lots of javadocs
> errors. They add a link to the addValue(double[]) method which is defined in
> the
> implementing class, not in the interface.
>
> What would be the best fix: chan
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=51246&projectId=362
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Fri 15 Feb 2008 17:05:04 -0800
Finished at: Fri 15 Feb 2008 17:07:31 -0800
Total time: 2m 27s
Build Trigger: For
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=51246&projectId=362
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Fri 15 Feb 2008 17:05:04 -0800
Finished at: Fri 15 Feb 2008 17:07:31 -0800
Total time: 2m 27s
Build Trigger: For
13 matches
Mail list logo
