Re: [commons-parent] drop cobertura

[Luc Maisonobe]

Le 28/12/2012 18:21, Phil Steitz a écrit :
> Any objections to this?  In [math] at least we can't seem to turn it
> off and it is causing the site build to take forever.

Go for it.

Luc

> 
> Thanks!
> 
> Phil
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Luc Maisonobe]

Hi Phil,

Le 28/12/2012 21:10, Phil Steitz a écrit :
> On 12/28/12 11:44 AM, Gary Gregory wrote:
>> It seems a shame to turn off this feature for ALL projects because one
>> project can't figure out a workaround.
> 
> Can *any* project find a workaround?  Is there *any way* to turn
> this thing off?

What about every project being declared in the aggregator project
Olivier set up in our instance of Sonar
?

Luc

> 
> Phil
>>
>> Gary
>>
>> On Dec 28, 2012, at 12:21, Phil Steitz  wrote:
>>
>>> Any objections to this?  In [math] at least we can't seem to turn it
>>> off and it is causing the site build to take forever.
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Sébastien Brisard]

Hi,


2012/12/29 Gilles Sadowski 

> Hi.
>
> > [...]
>
> > > third is just bug-fix.  Does the fix for the issue that started this
> > > thread change the API?  If so, we would need to cut 3.2 in any case.
>
> The current fix does change the usage (one needs to call optimize with an
> argument of a different type). IIUC, it also silently removes the handling
> of uncorrelated observations.
>
> > Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
> > and committed the fix as of r1426616.
> >
> > Could someone please review what I have done?
>
> I don't like the fix...
>
> Handling weighted observations must take correlations into account, i.e.
> use
> a _matrix_.
> There is the _practical_ problem of memory. Solving it correctly is by
> using
> a sparse implementation (and this is actually an implementation _detail_).
> If we _need_ such an implementation to solve the practical problem, I
> strongly suggest that we focus on creating it (or fixing what CM already
> has, or accept that some inconsistency will be present), rather than
> reducing the code applicability (i.e. allowing only uncorrelated data).
> If the observations are not correlated, the matrix is a diagonal matrix,
> not
> a vector.
> CM also lacks implementations for symmetric, triangular, and diagonal
> matrix,
> which all would go some way to solving several practical problems of the
> same
> kind as the current one without sacrificing generality.
>
> Now, and several years ago, it was noticed that CM does not _have_ to
> provide the "weights" feature because users can handle this before they
> call CM code. [IIRC, no CM unit test actually use weights different from
> 1.]
> IMO, the other valid option is thus to have a simpler version of the
> algorithm, but still a correct one.
> This would also have the advantage that we won't have the urgent need to
> keep the sparse matrix implementation.
> [Then, if at some point we include helper code to handle weights
> (_including_ correlations), we should also do it in a "preprocessing" step,
> without touching the optimization algorithms.]
>
> > I also think (but did not test it), that there may be a problem with
> > missing OptimizationData. If someone call the optimizer but forget to
> > set the weight (or the target, or some other mandatory parameters), then
> > I'm not sure we fail with an appropriate error. Looking for example at
> > the private checkParameters method in the MultivariateVectorOptimizer
> > abstract class, I guess we may have a NullPointer Exception if either
> > Target or Weight/NonCorrelatedWeight has not been parsed in the
> > parseOptimizationData method. Could someone confirm this?
>
> Yes.
> And this (not checking for missing data) _could_ be considered a feature,
> as
> I stressed several times on this ML, and in the code documentation
> (eliciting zero constructive comment).
> We also _agreed_ that users not passing needed data will result in NPE.
> [I imagined that applications would check that valid and complete input is
> passed to the lower level "optimize(OptimizationData ...)" methods.]
>
> It is however straightforward to add a "checkParameters()" method that
> would
> raise more specific exceptions. [Although that would contradict the
> conclusion of the previous discussion about NPE in CM. And restart it,
> without even getting a chance to go forward with what had been decided!]
>
>
> Hence, to summarize:
>  * The fix, in a 3.2 release, should be to replace the matrix
> implementation
>with one that does not exhaust the memory, e.g. "OpenMapRealMatrix"[1]
> or
>"DiagonalMatrix" (see my patch for MATH-924), but not change the API.
>  * We must decide wether to deprecate the weights feature in that release
>(and thus remove it in 4.0) or to keep it in its general form (and thus
>un-deprecate "OpenMapRealMatrix"[2]).
>
>
> Best regards,
> Gilles
>
> [1] The inconsistencies that led to the deprecation will have no bearing
> on usage within the optimizers.
> [2] The latter option seems likely to entail a fair amount of work to
> improve the performance of "OpenMapRealMatrix" (which is quite poor
> for some operations, e.g. "multiply").
>
> I have never been happy with deprecating the sparse implementations of
vectors and matrices. I also think we should "undeprecate" them and work on
them, with some help!
Regarding [1], my choice would be to point at the problematic cases in the
Javadoc (and possibly the user's guide), and live with them.
Regarding [2], would there be any performance gain if we designed an
immutable sparse vector/matrix. I guess it would. The question is: do we
need these objects to be mutable?

Sébastien

> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-parent] drop cobertura

[Mark Struberg]

or just move it to a profile?
In our project we have this enabled via

$> mvn clean instal -Pcoverage

LieGrue,
strub




- Original Message -
> From: Luc Maisonobe 
> To: Commons Developers List 
> Cc: 
> Sent: Saturday, December 29, 2012 9:43 AM
> Subject: Re: [commons-parent] drop cobertura
> 
> Hi Phil,
> 
> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>  On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>  It seems a shame to turn off this feature for ALL projects because one
>>>  project can't figure out a workaround.
>> 
>>  Can *any* project find a workaround?  Is there *any way* to turn
>>  this thing off?
> 
> What about every project being declared in the aggregator project
> Olivier set up in our instance of Sonar
> ?
> 
> Luc
> 
>> 
>>  Phil
>>> 
>>>  Gary
>>> 
>>>  On Dec 28, 2012, at 12:21, Phil Steitz  
> wrote:
>>> 
  Any objections to this?  In [math] at least we can't seem to 
> turn it
  off and it is causing the site build to take forever.
 
  Thanks!
 
  Phil
 
 
> -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
>>>  -
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 
>> 
>>  -
>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Luc Maisonobe]

Le 29/12/2012 04:09, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

> 
>> [...]
> 
>>> third is just bug-fix.  Does the fix for the issue that started this
>>> thread change the API?  If so, we would need to cut 3.2 in any case.
> 
> The current fix does change the usage (one needs to call optimize with an
> argument of a different type). IIUC, it also silently removes the handling
> of uncorrelated observations.
> 
>> Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
>> and committed the fix as of r1426616.
>>
>> Could someone please review what I have done?
> 
> I don't like the fix...

Thanks for reviewing.

> 
> Handling weighted observations must take correlations into account, i.e. use
> a _matrix_.
> There is the _practical_ problem of memory. Solving it correctly is by using
> a sparse implementation (and this is actually an implementation _detail_).

Yes.

> If we _need_ such an implementation to solve the practical problem, I
> strongly suggest that we focus on creating it (or fixing what CM already
> has, or accept that some inconsistency will be present), rather than
> reducing the code applicability (i.e. allowing only uncorrelated data).
> If the observations are not correlated, the matrix is a diagonal matrix, not
> a vector.

It's fine with me. I simply thought it wouldn't be that easy. You proved
me wrong.

> CM also lacks implementations for symmetric, triangular, and diagonal matrix,
> which all would go some way to solving several practical problems of the same
> kind as the current one without sacrificing generality.

Yes, we have known that for years.

> 
> Now, and several years ago, it was noticed that CM does not _have_ to
> provide the "weights" feature because users can handle this before they
> call CM code. [IIRC, no CM unit test actually use weights different from 1.]
> IMO, the other valid option is thus to have a simpler version of the
> algorithm, but still a correct one.
> This would also have the advantage that we won't have the urgent need to
> keep the sparse matrix implementation.
> [Then, if at some point we include helper code to handle weights
> (_including_ correlations), we should also do it in a "preprocessing" step,
> without touching the optimization algorithms.]

So what do you suggest: keep the current support (with proper handling
as you did) or drop it?

Since several people asked for removing it (Dimitri, Konstantin and now
you), we can do that. Unitl now, this feature was a convenience that was
really useful for some cases, and it was simple. There were some errors
in it and Dimitri solved them in 2010, but no other problems appeared
since them, so it made sense simply keeping it as is. Now we are hit by
a second problem, and it seems it opens a can of worm. Dropping it
completely as a not so useful convenience which is tricky to set up
right would be fair.

> 
>> I also think (but did not test it), that there may be a problem with
>> missing OptimizationData. If someone call the optimizer but forget to
>> set the weight (or the target, or some other mandatory parameters), then
>> I'm not sure we fail with an appropriate error. Looking for example at
>> the private checkParameters method in the MultivariateVectorOptimizer
>> abstract class, I guess we may have a NullPointer Exception if either
>> Target or Weight/NonCorrelatedWeight has not been parsed in the
>> parseOptimizationData method. Could someone confirm this?
> 
> Yes.
> And this (not checking for missing data) _could_ be considered a feature, as
> I stressed several times on this ML, and in the code documentation
> (eliciting zero constructive comment).
> We also _agreed_ that users not passing needed data will result in NPE.
> [I imagined that applications would check that valid and complete input is
> passed to the lower level "optimize(OptimizationData ...)" methods.]

Yes, abd I agree with that. However, I found the javadoc to be
ambiguous. It says "The following data will be looked for:" followed by
a list. There is no distinction between optional and required
parameters. As an example, simple bounds are optional whereas initial
guess or weight are required, but there is nothing to tell it to user.
So in this case, either we should provide proper exception or proper
documentation. I am OK with both.

> 
> It is however straightforward to add a "checkParameters()" method that would
> raise more specific exceptions. [Although that would contradict the
> conclusion of the previous discussion about NPE in CM. And restart it,
> without even getting a chance to go forward with what had been decided!]

As long as we identify the parameters that are optional (and hence user
can deduce the other one are mandatory and will raise an NPE), this
would be fine. I don't ask to restart this tiring discussion, just make
sure users have the proper way to understand why they get an NPE when
the forget weight and why they don't get one when the forget simple bounds.

Also weight should rea

Re: [math] major problem with new released version 3.1

[Sébastien Brisard]

Hello,


2012/12/28 Konstantin Berlin 

> >
> > That's what I was going to write. At the moment, the current
> implementation
> > for sparse matrices and vector is deprecated, for lack of convincing
> fixes
> > for the bugs which have been found. These bugs are mainly related to the
> > fact that zero --the unstored value-- is signed, and the sign is lost in
> > sparse implementations. This might be considered as unimportant, but
> leads
> > to the fact that wa cannot achieve the same level of correctness in our
> > sparse impl as in our dense impls.
> >
> > As for data copying, I strongly agree, and it is not really related to
> the
> > implementation of sparse vectors/matrices. For example, our
> implementation
> > of the conjugate gradient only requires a linear operator --not a
> matrix--,
> > which can be as sparse as you want. The problem is that all
> implementations
> > of iterative linear solvers use basic vector operations (add, sub,
> etc...),
> > which cannot be carried out in-place in the current abstract class
> > RealVector. This leads to unnecessary memory allocations for very large
> > problems. I am currently facing this issue. My matrix is not a problem
> > (it's actually a so-called "matrix-free" problem), and the vectors are
> > dense. The only problem is the demand in RAM. We should really give a
> > thought to in-place linear operations, without cluttering too much the
> API!
> > A possible way would be to use visitors.
> >
> > Best regards,
> > Sébastien
> >
>
> I think this issue can be overcome by proper OO design, and hacked on to
> the current interface for now.
>
> We can create an "InPlace" interface that all linear operators (including
> RealMatrix etc) would implement. For example in a hypothetical
> InPlaceMatrix class
>
> function InPlaceVector mult(InPlaceVector x), depending on implementation
> details, would either return back overwritten x in the return value, or a
> new value for multiplication leaving x in tact. This would allow the user
> to implement their more efficient version, while also allowing the usage of
> current linear algebra package if they don't care about performance. The
> idea is that the optimization classes would rely only on the InPlace
> interface for all their tasks.
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
I'm not sure about that. If I understand correctly, this would mean that
the _user_ has to provide the solver with a so-called InPlaceVector. I
don't think it should be the responsibility of the user to chose whether or
not a solver performs in place operations. As I said previously visitors
are a good way to do that without cluttering the interface. For example, we
could define a Multiply visitor, which scales all components of a vector. A
nice idiom would be to have a factory method Multiply.by(double) instead of
a constructor new Multiply(double). This way, scaling a vector in place
would read
v.walkInDefaultOrder(Multiply.by(double))

What do you think?
Sébastien

Re: [commons-parent] drop cobertura

[Sébastien Brisard]

Hi Mark,


2012/12/29 Mark Struberg 

> or just move it to a profile?
> In our project we have this enabled via
>
> $> mvn clean instal -Pcoverage
>
> LieGrue,
> strub
>
> We've been trying to do that unsuccessfully in Commons Math. What project
are you talking about? We could look at the pom.
Thanks,

Sébastien

>
>
>
> - Original Message -
> > From: Luc Maisonobe 
> > To: Commons Developers List 
> > Cc:
> > Sent: Saturday, December 29, 2012 9:43 AM
> > Subject: Re: [commons-parent] drop cobertura
> >
> > Hi Phil,
> >
> > Le 28/12/2012 21:10, Phil Steitz a écrit :
> >>  On 12/28/12 11:44 AM, Gary Gregory wrote:
> >>>  It seems a shame to turn off this feature for ALL projects because one
> >>>  project can't figure out a workaround.
> >>
> >>  Can *any* project find a workaround?  Is there *any way* to turn
> >>  this thing off?
> >
> > What about every project being declared in the aggregator project
> > Olivier set up in our instance of Sonar
> > ?
> >
> > Luc
> >
> >>
> >>  Phil
> >>>
> >>>  Gary
> >>>
> >>>  On Dec 28, 2012, at 12:21, Phil Steitz 
> > wrote:
> >>>
>   Any objections to this?  In [math] at least we can't seem to
> > turn it
>   off and it is causing the site build to take forever.
> 
>   Thanks!
> 
>   Phil
> 
> 
> > -
>   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>   For additional commands, e-mail: dev-h...@commons.apache.org
> 
> >>>  -
> >>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>  For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >>  -
> >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>  For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] major problem with new released version 3.1

[Dimitri Pourbaix]

Gilles,


Handling weighted observations must take correlations into account, i.e. use
a _matrix_.
There is the _practical_ problem of memory. Solving it correctly is by
using a sparse implementation (and this is actually an implementation
_detail_).


The problem is where something becomes a detail!  You are right that the
general least square problem copes with a matrix of weights ... but the
way it is implemented is a detail.  As already pointed out, even the
vector of weights API allows for a complicated matrix of weights.  The user
premultiplies by the 'square root' of that matrix and sets all the compo-
nents of the weight vector to 1.  So, your enthusiasm to generalise the
vector of weights to a matrix was a detail to make the life of very few
users easier ... without adding any functionality.

There are so many different configurations (e.g. block diagonal, ...), I
doubt you can handle all of them in the most efficient way so it is likely
preferable to have the user taking care of them.

It is however true that simple weights (i.e. vector form) are a very usual
situation ... which is also very common in fitting tools.  So, I think CM
should offer that approach as well.

In conclusion: the old CM 3.0 API was enough! :)

Regards,
 Dim.

Dimitri Pourbaix *  Don't worry, be happy
Institut d'Astronomie et d'Astrophysique * and CARPE DIEM.
CP 226, office 2.N4.211, building NO *
Universite Libre de Bruxelles*  Tel : +32-2-650.35.71
Boulevard du Triomphe*  Fax : +32-2-650.42.26
 B-1050 Bruxelles*NAC: HBZSC RG2Z6
http://sb9.astro.ulb.ac.be/~pourbaix * mailto:pourb...@astro.ulb.ac.be

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Luc Maisonobe]

Le 29/12/2012 10:08, Luc Maisonobe a écrit :
> Le 29/12/2012 04:09, Gilles Sadowski a écrit :
>> Hi.
> 
> Hi Gilles,
> 
>>
>>> [...]
>>
 third is just bug-fix.  Does the fix for the issue that started this
 thread change the API?  If so, we would need to cut 3.2 in any case.
>>
>> The current fix does change the usage (one needs to call optimize with an
>> argument of a different type). IIUC, it also silently removes the handling
>> of uncorrelated observations.
>>
>>> Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
>>> and committed the fix as of r1426616.
>>>
>>> Could someone please review what I have done?
>>
>> I don't like the fix...
> 
> Thanks for reviewing.
> 
>>
>> Handling weighted observations must take correlations into account, i.e. use
>> a _matrix_.
>> There is the _practical_ problem of memory. Solving it correctly is by using
>> a sparse implementation (and this is actually an implementation _detail_).
> 
> Yes.
> 
>> If we _need_ such an implementation to solve the practical problem, I
>> strongly suggest that we focus on creating it (or fixing what CM already
>> has, or accept that some inconsistency will be present), rather than
>> reducing the code applicability (i.e. allowing only uncorrelated data).
>> If the observations are not correlated, the matrix is a diagonal matrix, not
>> a vector.
> 
> It's fine with me. I simply thought it wouldn't be that easy. You proved
> me wrong.
> 
>> CM also lacks implementations for symmetric, triangular, and diagonal matrix,
>> which all would go some way to solving several practical problems of the same
>> kind as the current one without sacrificing generality.
> 
> Yes, we have known that for years.
> 
>>
>> Now, and several years ago, it was noticed that CM does not _have_ to
>> provide the "weights" feature because users can handle this before they
>> call CM code. [IIRC, no CM unit test actually use weights different from 1.]
>> IMO, the other valid option is thus to have a simpler version of the
>> algorithm, but still a correct one.
>> This would also have the advantage that we won't have the urgent need to
>> keep the sparse matrix implementation.
>> [Then, if at some point we include helper code to handle weights
>> (_including_ correlations), we should also do it in a "preprocessing" step,
>> without touching the optimization algorithms.]
> 
> So what do you suggest: keep the current support (with proper handling
> as you did) or drop it?
> 
> Since several people asked for removing it (Dimitri, Konstantin and now
> you), we can do that. Unitl now, this feature was a convenience that was
> really useful for some cases, and it was simple. There were some errors
> in it and Dimitri solved them in 2010, but no other problems appeared
> since them, so it made sense simply keeping it as is. Now we are hit by
> a second problem, and it seems it opens a can of worm. Dropping it
> completely as a not so useful convenience which is tricky to set up
> right would be fair.
> 
>>
>>> I also think (but did not test it), that there may be a problem with
>>> missing OptimizationData. If someone call the optimizer but forget to
>>> set the weight (or the target, or some other mandatory parameters), then
>>> I'm not sure we fail with an appropriate error. Looking for example at
>>> the private checkParameters method in the MultivariateVectorOptimizer
>>> abstract class, I guess we may have a NullPointer Exception if either
>>> Target or Weight/NonCorrelatedWeight has not been parsed in the
>>> parseOptimizationData method. Could someone confirm this?
>>
>> Yes.
>> And this (not checking for missing data) _could_ be considered a feature, as
>> I stressed several times on this ML, and in the code documentation
>> (eliciting zero constructive comment).
>> We also _agreed_ that users not passing needed data will result in NPE.
>> [I imagined that applications would check that valid and complete input is
>> passed to the lower level "optimize(OptimizationData ...)" methods.]
> 
> Yes, abd I agree with that. However, I found the javadoc to be
> ambiguous. It says "The following data will be looked for:" followed by
> a list. There is no distinction between optional and required
> parameters. As an example, simple bounds are optional whereas initial
> guess or weight are required, but there is nothing to tell it to user.
> So in this case, either we should provide proper exception or proper
> documentation. I am OK with both.
> 
>>
>> It is however straightforward to add a "checkParameters()" method that would
>> raise more specific exceptions. [Although that would contradict the
>> conclusion of the previous discussion about NPE in CM. And restart it,
>> without even getting a chance to go forward with what had been decided!]
> 
> As long as we identify the parameters that are optional (and hence user
> can deduce the other one are mandatory and will raise an NPE), this
> would be fine. I don't ask to restart this tiring discus

Re: [math] major problem with new released version 3.1

[Gilles Sadowski]

On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
> Le 29/12/2012 10:08, Luc Maisonobe a écrit :
> > Le 29/12/2012 04:09, Gilles Sadowski a écrit :
> >> Hi.
> > 
> > Hi Gilles,
> > 
> >>
> >>> [...]
> >>
>  third is just bug-fix.  Does the fix for the issue that started this
>  thread change the API?  If so, we would need to cut 3.2 in any case.
> >>
> >> The current fix does change the usage (one needs to call optimize with an
> >> argument of a different type). IIUC, it also silently removes the handling
> >> of uncorrelated observations.
> >>
> >>> Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
> >>> and committed the fix as of r1426616.
> >>>
> >>> Could someone please review what I have done?
> >>
> >> I don't like the fix...
> > 
> > Thanks for reviewing.
> > 
> >>
> >> Handling weighted observations must take correlations into account, i.e. 
> >> use
> >> a _matrix_.
> >> There is the _practical_ problem of memory. Solving it correctly is by 
> >> using
> >> a sparse implementation (and this is actually an implementation _detail_).
> > 
> > Yes.
> > 
> >> If we _need_ such an implementation to solve the practical problem, I
> >> strongly suggest that we focus on creating it (or fixing what CM already
> >> has, or accept that some inconsistency will be present), rather than
> >> reducing the code applicability (i.e. allowing only uncorrelated data).
> >> If the observations are not correlated, the matrix is a diagonal matrix, 
> >> not
> >> a vector.
> > 
> > It's fine with me. I simply thought it wouldn't be that easy. You proved
> > me wrong.
> > 
> >> CM also lacks implementations for symmetric, triangular, and diagonal 
> >> matrix,
> >> which all would go some way to solving several practical problems of the 
> >> same
> >> kind as the current one without sacrificing generality.
> > 
> > Yes, we have known that for years.
> > 
> >>
> >> Now, and several years ago, it was noticed that CM does not _have_ to
> >> provide the "weights" feature because users can handle this before they
> >> call CM code. [IIRC, no CM unit test actually use weights different from 
> >> 1.]
> >> IMO, the other valid option is thus to have a simpler version of the
> >> algorithm, but still a correct one.
> >> This would also have the advantage that we won't have the urgent need to
> >> keep the sparse matrix implementation.
> >> [Then, if at some point we include helper code to handle weights
> >> (_including_ correlations), we should also do it in a "preprocessing" step,
> >> without touching the optimization algorithms.]
> > 
> > So what do you suggest: keep the current support (with proper handling
> > as you did) or drop it?
> > 
> > Since several people asked for removing it (Dimitri, Konstantin and now
> > you), we can do that. Unitl now, this feature was a convenience that was
> > really useful for some cases, and it was simple. There were some errors
> > in it and Dimitri solved them in 2010, but no other problems appeared
> > since them, so it made sense simply keeping it as is. Now we are hit by
> > a second problem, and it seems it opens a can of worm. Dropping it
> > completely as a not so useful convenience which is tricky to set up
> > right would be fair.
> > 
> >>
> >>> I also think (but did not test it), that there may be a problem with
> >>> missing OptimizationData. If someone call the optimizer but forget to
> >>> set the weight (or the target, or some other mandatory parameters), then
> >>> I'm not sure we fail with an appropriate error. Looking for example at
> >>> the private checkParameters method in the MultivariateVectorOptimizer
> >>> abstract class, I guess we may have a NullPointer Exception if either
> >>> Target or Weight/NonCorrelatedWeight has not been parsed in the
> >>> parseOptimizationData method. Could someone confirm this?
> >>
> >> Yes.
> >> And this (not checking for missing data) _could_ be considered a feature, 
> >> as
> >> I stressed several times on this ML, and in the code documentation
> >> (eliciting zero constructive comment).
> >> We also _agreed_ that users not passing needed data will result in NPE.
> >> [I imagined that applications would check that valid and complete input is
> >> passed to the lower level "optimize(OptimizationData ...)" methods.]
> > 
> > Yes, abd I agree with that. However, I found the javadoc to be
> > ambiguous. It says "The following data will be looked for:" followed by
> > a list. There is no distinction between optional and required
> > parameters. As an example, simple bounds are optional whereas initial
> > guess or weight are required, but there is nothing to tell it to user.
> > So in this case, either we should provide proper exception or proper
> > documentation. I am OK with both.
> > 
> >>
> >> It is however straightforward to add a "checkParameters()" method that 
> >> would
> >> raise more specific exceptions. [Although that would contradict the
> >> conclusion of the previous discussi

Re: [math] major problem with new released version 3.1

[Luc Maisonobe]

Le 29/12/2012 12:34, Gilles Sadowski a écrit :
> On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
>> Le 29/12/2012 10:08, Luc Maisonobe a écrit :
>>> Le 29/12/2012 04:09, Gilles Sadowski a écrit :
 Hi.
>>>
>>> Hi Gilles,
>>>

> [...]

>> third is just bug-fix.  Does the fix for the issue that started this
>> thread change the API?  If so, we would need to cut 3.2 in any case.

 The current fix does change the usage (one needs to call optimize with an
 argument of a different type). IIUC, it also silently removes the handling
 of uncorrelated observations.

> Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
> and committed the fix as of r1426616.
>
> Could someone please review what I have done?

 I don't like the fix...
>>>
>>> Thanks for reviewing.
>>>

 Handling weighted observations must take correlations into account, i.e. 
 use
 a _matrix_.
 There is the _practical_ problem of memory. Solving it correctly is by 
 using
 a sparse implementation (and this is actually an implementation _detail_).
>>>
>>> Yes.
>>>
 If we _need_ such an implementation to solve the practical problem, I
 strongly suggest that we focus on creating it (or fixing what CM already
 has, or accept that some inconsistency will be present), rather than
 reducing the code applicability (i.e. allowing only uncorrelated data).
 If the observations are not correlated, the matrix is a diagonal matrix, 
 not
 a vector.
>>>
>>> It's fine with me. I simply thought it wouldn't be that easy. You proved
>>> me wrong.
>>>
 CM also lacks implementations for symmetric, triangular, and diagonal 
 matrix,
 which all would go some way to solving several practical problems of the 
 same
 kind as the current one without sacrificing generality.
>>>
>>> Yes, we have known that for years.
>>>

 Now, and several years ago, it was noticed that CM does not _have_ to
 provide the "weights" feature because users can handle this before they
 call CM code. [IIRC, no CM unit test actually use weights different from 
 1.]
 IMO, the other valid option is thus to have a simpler version of the
 algorithm, but still a correct one.
 This would also have the advantage that we won't have the urgent need to
 keep the sparse matrix implementation.
 [Then, if at some point we include helper code to handle weights
 (_including_ correlations), we should also do it in a "preprocessing" step,
 without touching the optimization algorithms.]
>>>
>>> So what do you suggest: keep the current support (with proper handling
>>> as you did) or drop it?
>>>
>>> Since several people asked for removing it (Dimitri, Konstantin and now
>>> you), we can do that. Unitl now, this feature was a convenience that was
>>> really useful for some cases, and it was simple. There were some errors
>>> in it and Dimitri solved them in 2010, but no other problems appeared
>>> since them, so it made sense simply keeping it as is. Now we are hit by
>>> a second problem, and it seems it opens a can of worm. Dropping it
>>> completely as a not so useful convenience which is tricky to set up
>>> right would be fair.
>>>

> I also think (but did not test it), that there may be a problem with
> missing OptimizationData. If someone call the optimizer but forget to
> set the weight (or the target, or some other mandatory parameters), then
> I'm not sure we fail with an appropriate error. Looking for example at
> the private checkParameters method in the MultivariateVectorOptimizer
> abstract class, I guess we may have a NullPointer Exception if either
> Target or Weight/NonCorrelatedWeight has not been parsed in the
> parseOptimizationData method. Could someone confirm this?

 Yes.
 And this (not checking for missing data) _could_ be considered a feature, 
 as
 I stressed several times on this ML, and in the code documentation
 (eliciting zero constructive comment).
 We also _agreed_ that users not passing needed data will result in NPE.
 [I imagined that applications would check that valid and complete input is
 passed to the lower level "optimize(OptimizationData ...)" methods.]
>>>
>>> Yes, abd I agree with that. However, I found the javadoc to be
>>> ambiguous. It says "The following data will be looked for:" followed by
>>> a list. There is no distinction between optional and required
>>> parameters. As an example, simple bounds are optional whereas initial
>>> guess or weight are required, but there is nothing to tell it to user.
>>> So in this case, either we should provide proper exception or proper
>>> documentation. I am OK with both.
>>>

 It is however straightforward to add a "checkParameters()" method that 
 would
 raise more specific exceptions. [Although that would contradict the
 

Re: [commons-parent] drop cobertura

[Simone Tripodi]

> or just move it to a profile?

+1

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Gilles Sadowski]

On Sat, Dec 29, 2012 at 10:22:20AM +0100, Dimitri Pourbaix wrote:
> Gilles,
> 
> >Handling weighted observations must take correlations into account, i.e. use
> >a _matrix_.
> >There is the _practical_ problem of memory. Solving it correctly is by
> >using a sparse implementation (and this is actually an implementation
> >_detail_).
> 
> The problem is where something becomes a detail!  You are right that the
> general least square problem copes with a matrix of weights ... but the
> way it is implemented is a detail.

That's what I said above, although I suspect that we don't mean the same
thing. OO programming allows to define types that will represent the
"real" concepts: in this case, if the problem is expressed in terms of a
a (mathematical) matrix, the algorithm should use a "Matrix" (type).
This is not an implementation detail; the goal is for the code to be as
close as possible to the mathematical description of the procedure
(self-documenting code).

The implementation detail is how the matrix type stores its data internally;
and this can be the subject of any necessary efficiency improvements,
independently of the matrix concept used at a higher level (e.g. in the
optimization algorithms).

> As already pointed out, even the
> vector of weights API allows for a complicated matrix of weights.  The user
> premultiplies by the 'square root' of that matrix and sets all the compo-
> nents of the weight vector to 1.  So, your enthusiasm to generalise the
> vector of weights to a matrix was a detail to make the life of very few
> users easier ... without adding any functionality.

This is a backward description of my change.
In reality:
1. The handling of weights was there.
2. Assuming that people wanted to keep it, I added the functionality to
   handle correlated observations.

If indeed the weight feature is independent of the optimization procedure,
then _all_ references to weights should be banned.
[If just because keeping an array of "ones" and doing loops that "multiply
by one" are obviously not going to improve clarity and performance.]
Eventually, this seems to be the accepted compromise now (IIUC).

> There are so many different configurations (e.g. block diagonal, ...), I
> doubt you can handle all of them in the most efficient way

Actually, my "Weight" class trivially handles _any_ "RealMatrix" (thanks to
inheritance!).

> so it is likely
> preferable to have the user taking care of them.

This is exactly what "Weight" does.
The problem is that CM does not provide efficient implementations for
matrix forms suited for this context (symmetric, sparse, diagonal).[1]

Above and in the previous post, I agreed that this would not be a problem i
we entirely drop the support for weights in the optimizers.

> It is however true that simple weights (i.e. vector form) are a very usual
> situation ... which is also very common in fitting tools.  So, I think CM
> should offer that approach as well.

Where? In the fitting tools or in the optimizers?
We just said that weights could be handled independenttly from the
optimization procedure. But we could indeed put weights back where they are
most useful (e.g. in the curve fitting) without dragging everywhere (where
most of the time they'd be equal to one...).

> In conclusion: the old CM 3.0 API was enough! :)

If that's so, then people can just copy/paste the source code of that
version and not care about subsequent versions of CM.


Cordially,
Gilles

[1] Actually, the problem is that some people complain that we don't do
enough to their taste: In the past, at least 3 persons raised issues
with matrix implementations, but without providing any useful help,
unfortunately (to be clear, I'm not talking of current contributors!).

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Gilles Sadowski]

Hi.

> > [...]
> >
> > [1] The inconsistencies that led to the deprecation will have no bearing
> > on usage within the optimizers.
> > [2] The latter option seems likely to entail a fair amount of work to
> > improve the performance of "OpenMapRealMatrix" (which is quite poor
> > for some operations, e.g. "multiply").
> >
> > I have never been happy with deprecating the sparse implementations of
> vectors and matrices. I also think we should "undeprecate" them and work on
> them, with some help!
> Regarding [1], my choice would be to point at the problematic cases in the
> Javadoc (and possibly the user's guide), and live with them.
> Regarding [2], would there be any performance gain if we designed an
> immutable sparse vector/matrix. I guess it would. The question is: do we
> need these objects to be mutable?

I don't think so. And certainly not for the usage in the optimizers.

Anyways, I assume that it would be quite useful to have a new matrix
hierarchy (with more types than we have now, and appropriately optimized for
storage and/or speed). And a good starting point would be to assume
immutability.


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Oliver Heger]

Am 29.12.2012 09:43, schrieb Luc Maisonobe:

Hi Phil,

Le 28/12/2012 21:10, Phil Steitz a écrit :

On 12/28/12 11:44 AM, Gary Gregory wrote:

It seems a shame to turn off this feature for ALL projects because one
project can't figure out a workaround.


Can *any* project find a workaround?  Is there *any way* to turn
this thing off?


What about every project being declared in the aggregator project
Olivier set up in our instance of Sonar
?



+1

We could then even disable more reports in the components' poms 
(findbugs, pmd, checkstyle, ...) and just add a link to the Sonar instance.


This would provide comprehensive up-to-date statistics for all 
components. It would also be a step forward in making the components 
more uniform.


Oliver


Luc



Phil


Gary

On Dec 28, 2012, at 12:21, Phil Steitz  wrote:


Any objections to this?  In [math] at least we can't seem to turn it
off and it is causing the site build to take forever.

Thanks!

Phil

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Phil Steitz]

On 12/29/12 9:46 AM, Oliver Heger wrote:
> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>> Hi Phil,
>>
>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
 It seems a shame to turn off this feature for ALL projects
 because one
 project can't figure out a workaround.
>>>
>>> Can *any* project find a workaround?  Is there *any way* to turn
>>> this thing off?
>>
>> What about every project being declared in the aggregator project
>> Olivier set up in our instance of Sonar
>> ?
>>
>
> +1
>
> We could then even disable more reports in the components' poms
> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
> instance.
>
> This would provide comprehensive up-to-date statistics for all
> components. It would also be a step forward in making the
> components more uniform.

+1 - and as yet another bonus, it would reduce wasted infra
resources duplicating all of the images, etc on all of the
individual sites and the need to store all of that stuff in svn.

Phil
>
> Oliver
>
>> Luc
>>
>>>
>>> Phil

 Gary

 On Dec 28, 2012, at 12:21, Phil Steitz 
 wrote:

> Any objections to this?  In [math] at least we can't seem to
> turn it
> off and it is causing the site build to take forever.
>
> Thanks!
>
> Phil
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
 -

 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


>>>
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Gary Gregory]

Using Sonar is useless for local development. When I make changes and run a
build, I want to see all of the reports based on my local changes, not what
is in the VCS. I know we usually do CTR but this would force me to commit
to see reports in Sonar, a non-starter IMO.

Gary


On Sat, Dec 29, 2012 at 12:46 PM, Oliver Heger  wrote:

> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>
>  Hi Phil,
>>
>> Le 28/12/2012 21:10, Phil Steitz a écrit :
>>
>>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>
 It seems a shame to turn off this feature for ALL projects because one
 project can't figure out a workaround.

>>>
>>> Can *any* project find a workaround?  Is there *any way* to turn
>>> this thing off?
>>>
>>
>> What about every project being declared in the aggregator project
>> Olivier set up in our instance of Sonar
>> 
>> >?
>>
>>
> +1
>
> We could then even disable more reports in the components' poms (findbugs,
> pmd, checkstyle, ...) and just add a link to the Sonar instance.
>
> This would provide comprehensive up-to-date statistics for all components.
> It would also be a step forward in making the components more uniform.
>
> Oliver
>
>
>  Luc
>>
>>
>>> Phil
>>>

 Gary

 On Dec 28, 2012, at 12:21, Phil Steitz  wrote:

  Any objections to this?  In [math] at least we can't seem to turn it
> off and it is causing the site build to take forever.
>
> Thanks!
>
> Phil
>
> --**--**
> -
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>  --**--**
 -
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@commons.**apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@commons.**apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [commons-parent] drop cobertura

[Gary Gregory]

Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
commons components to Sonar, just do not mess up development for all the
other components because one class in [math] is not performing acceptably
for the Cobertura report.

Gary


On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz  wrote:

> On 12/29/12 9:46 AM, Oliver Heger wrote:
> > Am 29.12.2012 09:43, schrieb Luc Maisonobe:
> >> Hi Phil,
> >>
> >> Le 28/12/2012 21:10, Phil Steitz a écrit :
> >>> On 12/28/12 11:44 AM, Gary Gregory wrote:
>  It seems a shame to turn off this feature for ALL projects
>  because one
>  project can't figure out a workaround.
> >>>
> >>> Can *any* project find a workaround?  Is there *any way* to turn
> >>> this thing off?
> >>
> >> What about every project being declared in the aggregator project
> >> Olivier set up in our instance of Sonar
> >> ?
> >>
> >
> > +1
> >
> > We could then even disable more reports in the components' poms
> > (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
> > instance.
> >
> > This would provide comprehensive up-to-date statistics for all
> > components. It would also be a step forward in making the
> > components more uniform.
>
> +1 - and as yet another bonus, it would reduce wasted infra
> resources duplicating all of the images, etc on all of the
> individual sites and the need to store all of that stuff in svn.
>
> Phil
> >
> > Oliver
> >
> >> Luc
> >>
> >>>
> >>> Phil
> 
>  Gary
> 
>  On Dec 28, 2012, at 12:21, Phil Steitz 
>  wrote:
> 
> > Any objections to this?  In [math] at least we can't seem to
> > turn it
> > off and it is causing the site build to take forever.
> >
> > Thanks!
> >
> > Phil
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>  -
> 
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> >>>
> >>>
> >>> -
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> -
> >>
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [commons-parent] drop cobertura

[Phil Steitz]

On 12/29/12 10:02 AM, Gary Gregory wrote:
> Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
> commons components to Sonar, just do not mess up development for all the
> other components because one class in [math] is not performing acceptably
> for the Cobertura report.

The problem is that the plugin is bugged and effectively impossible
to turn off. 

I think the sonar idea is a great one and consistent with what we
have talked about on and off for years - separating the CI-type
development reports from the component sites.  As we are about to go
over the "site deployment cliff ;"  now is a great time to think
about losing some weight :)

I guess an alternative for [math] is to drop commons-parent
entirely, just grabbing the stuff we need.  Any better suggestions
for [math]?

Phil
>
> Gary
>
>
> On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz  wrote:
>
>> On 12/29/12 9:46 AM, Oliver Heger wrote:
>>> Am 29.12.2012 09:43, schrieb Luc Maisonobe:
 Hi Phil,

 Le 28/12/2012 21:10, Phil Steitz a écrit :
> On 12/28/12 11:44 AM, Gary Gregory wrote:
>> It seems a shame to turn off this feature for ALL projects
>> because one
>> project can't figure out a workaround.
> Can *any* project find a workaround?  Is there *any way* to turn
> this thing off?
 What about every project being declared in the aggregator project
 Olivier set up in our instance of Sonar
 ?

>>> +1
>>>
>>> We could then even disable more reports in the components' poms
>>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>> instance.
>>>
>>> This would provide comprehensive up-to-date statistics for all
>>> components. It would also be a step forward in making the
>>> components more uniform.
>> +1 - and as yet another bonus, it would reduce wasted infra
>> resources duplicating all of the images, etc on all of the
>> individual sites and the need to store all of that stuff in svn.
>>
>> Phil
>>> Oliver
>>>
 Luc

> Phil
>> Gary
>>
>> On Dec 28, 2012, at 12:21, Phil Steitz 
>> wrote:
>>
>>> Any objections to this?  In [math] at least we can't seem to
>>> turn it
>>> off and it is causing the site build to take forever.
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

 -

 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Mark Struberg]

> Any better suggestions for [math]?

Yes, as I see it there are two options.

a.) move some parts into a profile
b.) create 2 parent pom. One with the infrastructure stuff and one with all the 
tons of additional goodies only needed for the other projects.


LieGrue,
strub


PS: I find it pretty weird that the commons-parent has a profile to build all 
the other stuff. This can be done much cleaner in having an own 
build-aggregator pom which just contains the .


- Original Message -
> From: Phil Steitz 
> To: Commons Developers List 
> Cc: 
> Sent: Saturday, December 29, 2012 7:29 PM
> Subject: Re: [commons-parent] drop cobertura
> 
> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>>  commons components to Sonar, just do not mess up development for all the
>>  other components because one class in [math] is not performing acceptably
>>  for the Cobertura report.
> 
> The problem is that the plugin is bugged and effectively impossible
> to turn off. 
> 
> I think the sonar idea is a great one and consistent with what we
> have talked about on and off for years - separating the CI-type
> development reports from the component sites.  As we are about to go
> over the "site deployment cliff ;"  now is a great time to think
> about losing some weight :)
> 
> I guess an alternative for [math] is to drop commons-parent
> entirely, just grabbing the stuff we need.  Any better suggestions
> for [math]?
> 
> Phil
>> 
>>  Gary
>> 
>> 
>>  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz  
> wrote:
>> 
>>>  On 12/29/12 9:46 AM, Oliver Heger wrote:
  Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>  Hi Phil,
> 
>  Le 28/12/2012 21:10, Phil Steitz a écrit :
>>  On 12/28/12 11:44 AM, Gary Gregory wrote:
>>>  It seems a shame to turn off this feature for ALL 
> projects
>>>  because one
>>>  project can't figure out a workaround.
>>  Can *any* project find a workaround?  Is there *any way* to 
> turn
>>  this thing off?
>  What about every project being declared in the aggregator 
> project
>  Olivier set up in our instance of Sonar
>  ?
> 
  +1
 
  We could then even disable more reports in the components' poms
  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
  instance.
 
  This would provide comprehensive up-to-date statistics for all
  components. It would also be a step forward in making the
  components more uniform.
>>>  +1 - and as yet another bonus, it would reduce wasted infra
>>>  resources duplicating all of the images, etc on all of the
>>>  individual sites and the need to store all of that stuff in svn.
>>> 
>>>  Phil
  Oliver
 
>  Luc
> 
>>  Phil
>>>  Gary
>>> 
>>>  On Dec 28, 2012, at 12:21, Phil Steitz 
> 
>>>  wrote:
>>> 
  Any objections to this?  In [math] at least we 
> can't seem to
  turn it
  off and it is causing the site build to take 
> forever.
 
  Thanks!
 
  Phil
 
 
> -
 
  To unsubscribe, e-mail: 
> dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
> dev-h...@commons.apache.org
 
>>> 
> -
>>> 
>>>  To unsubscribe, e-mail: 
> dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: 
> dev-h...@commons.apache.org
>>> 
>>> 
>> 
>> 
> -
>> 
>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  For additional commands, e-mail: 
> dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -
> 
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 
> -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
>>> 
>>>  -
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.a

Re: [math] major problem with new released version 3.1

[Phil Steitz]

On 12/29/12 4:16 AM, Luc Maisonobe wrote:
> Le 29/12/2012 12:34, Gilles Sadowski a écrit :
>> On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
>>> Le 29/12/2012 10:08, Luc Maisonobe a écrit :
 Le 29/12/2012 04:09, Gilles Sadowski a écrit :
> Hi.
 Hi Gilles,

>> [...]
>>> third is just bug-fix.  Does the fix for the issue that started this
>>> thread change the API?  If so, we would need to cut 3.2 in any case.
> The current fix does change the usage (one needs to call optimize with an
> argument of a different type). IIUC, it also silently removes the handling
> of uncorrelated observations.
>
>> Yes, this fixes the issue. I have created/resolved the issue (MATH-924)
>> and committed the fix as of r1426616.
>>
>> Could someone please review what I have done?
> I don't like the fix...
 Thanks for reviewing.

> Handling weighted observations must take correlations into account, i.e. 
> use
> a _matrix_.
> There is the _practical_ problem of memory. Solving it correctly is by 
> using
> a sparse implementation (and this is actually an implementation _detail_).
 Yes.

> If we _need_ such an implementation to solve the practical problem, I
> strongly suggest that we focus on creating it (or fixing what CM already
> has, or accept that some inconsistency will be present), rather than
> reducing the code applicability (i.e. allowing only uncorrelated data).
> If the observations are not correlated, the matrix is a diagonal matrix, 
> not
> a vector.
 It's fine with me. I simply thought it wouldn't be that easy. You proved
 me wrong.

> CM also lacks implementations for symmetric, triangular, and diagonal 
> matrix,
> which all would go some way to solving several practical problems of the 
> same
> kind as the current one without sacrificing generality.
 Yes, we have known that for years.

> Now, and several years ago, it was noticed that CM does not _have_ to
> provide the "weights" feature because users can handle this before they
> call CM code. [IIRC, no CM unit test actually use weights different from 
> 1.]
> IMO, the other valid option is thus to have a simpler version of the
> algorithm, but still a correct one.
> This would also have the advantage that we won't have the urgent need to
> keep the sparse matrix implementation.
> [Then, if at some point we include helper code to handle weights
> (_including_ correlations), we should also do it in a "preprocessing" 
> step,
> without touching the optimization algorithms.]
 So what do you suggest: keep the current support (with proper handling
 as you did) or drop it?

 Since several people asked for removing it (Dimitri, Konstantin and now
 you), we can do that. Unitl now, this feature was a convenience that was
 really useful for some cases, and it was simple. There were some errors
 in it and Dimitri solved them in 2010, but no other problems appeared
 since them, so it made sense simply keeping it as is. Now we are hit by
 a second problem, and it seems it opens a can of worm. Dropping it
 completely as a not so useful convenience which is tricky to set up
 right would be fair.

>> I also think (but did not test it), that there may be a problem with
>> missing OptimizationData. If someone call the optimizer but forget to
>> set the weight (or the target, or some other mandatory parameters), then
>> I'm not sure we fail with an appropriate error. Looking for example at
>> the private checkParameters method in the MultivariateVectorOptimizer
>> abstract class, I guess we may have a NullPointer Exception if either
>> Target or Weight/NonCorrelatedWeight has not been parsed in the
>> parseOptimizationData method. Could someone confirm this?
> Yes.
> And this (not checking for missing data) _could_ be considered a feature, 
> as
> I stressed several times on this ML, and in the code documentation
> (eliciting zero constructive comment).
> We also _agreed_ that users not passing needed data will result in NPE.
> [I imagined that applications would check that valid and complete input is
> passed to the lower level "optimize(OptimizationData ...)" methods.]
 Yes, abd I agree with that. However, I found the javadoc to be
 ambiguous. It says "The following data will be looked for:" followed by
 a list. There is no distinction between optional and required
 parameters. As an example, simple bounds are optional whereas initial
 guess or weight are required, but there is nothing to tell it to user.
 So in this case, either we should provide proper exception or proper
 documentation. I am OK with both.

> It is however straightforward to add a "checkParameters()" method that 
> would
> 

[commons-parent] cut a release?

[Phil Steitz]

To get sites prepared for svn pub/sub, we now need to depend on
commons-parent snapshot.  We should cut a release so this is not
necessary.  I have no idea how to do this.  I will RM if I can get a
recipe that works and others are OK with releasing now.  It would be
great if someone could add a readme to the parent svn showing how to
cut a release, similar to what Gilles did for [math].

Phil

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Phil Steitz]

On 12/29/12 10:44 AM, Mark Struberg wrote:
>> Any better suggestions for [math]?
> Yes, as I see it there are two options.
>
> a.) move some parts into a profile

How exactly would this work?  Can we get rid of stuff that way,
really?  We can get it to ignore stuff the parent specifies?  Or are
you talking about yet another profile in the parent?
> b.) create 2 parent pom. One with the infrastructure stuff and one with all 
> the tons of additional goodies only needed for the other projects.

That seems pretty ugly.  I wonder how bad it would be, actually, to
just get rid of the parent and define the stuff we actually use /
need in [math] itself.  I think I have on balance spent more time
figuring out what was going on in the parent than I would have spent
just maintaining properties actually used by the components that I
work on.  Maybe just strip it down to some common properties and
things like the mailing lists.  At the very least, we should drop
the reporting section and the one you mention below.

>
>
> LieGrue,
> strub
>
>
> PS: I find it pretty weird that the commons-parent has a profile to build all 
> the other stuff. This can be done much cleaner in having an own 
> build-aggregator pom which just contains the .

Agreed.  I wonder if anyone ever uses this.  I would be +1 to drop.

Phil
>
>
> - Original Message -
>> From: Phil Steitz 
>> To: Commons Developers List 
>> Cc: 
>> Sent: Saturday, December 29, 2012 7:29 PM
>> Subject: Re: [commons-parent] drop cobertura
>>
>> On 12/29/12 10:02 AM, Gary Gregory wrote:
>>>  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
>>>  commons components to Sonar, just do not mess up development for all the
>>>  other components because one class in [math] is not performing acceptably
>>>  for the Cobertura report.
>> The problem is that the plugin is bugged and effectively impossible
>> to turn off. 
>>
>> I think the sonar idea is a great one and consistent with what we
>> have talked about on and off for years - separating the CI-type
>> development reports from the component sites.  As we are about to go
>> over the "site deployment cliff ;"  now is a great time to think
>> about losing some weight :)
>>
>> I guess an alternative for [math] is to drop commons-parent
>> entirely, just grabbing the stuff we need.  Any better suggestions
>> for [math]?
>>
>> Phil
>>>  Gary
>>>
>>>
>>>  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz  
>> wrote:
  On 12/29/12 9:46 AM, Oliver Heger wrote:
>  Am 29.12.2012 09:43, schrieb Luc Maisonobe:
>>  Hi Phil,
>>
>>  Le 28/12/2012 21:10, Phil Steitz a écrit :
>>>  On 12/28/12 11:44 AM, Gary Gregory wrote:
  It seems a shame to turn off this feature for ALL 
>> projects
  because one
  project can't figure out a workaround.
>>>  Can *any* project find a workaround?  Is there *any way* to 
>> turn
>>>  this thing off?
>>  What about every project being declared in the aggregator 
>> project
>>  Olivier set up in our instance of Sonar
>>  ?
>>
>  +1
>
>  We could then even disable more reports in the components' poms
>  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>  instance.
>
>  This would provide comprehensive up-to-date statistics for all
>  components. It would also be a step forward in making the
>  components more uniform.
  +1 - and as yet another bonus, it would reduce wasted infra
  resources duplicating all of the images, etc on all of the
  individual sites and the need to store all of that stuff in svn.

  Phil
>  Oliver
>
>>  Luc
>>
>>>  Phil
  Gary

  On Dec 28, 2012, at 12:21, Phil Steitz 
>> 
  wrote:

>  Any objections to this?  In [math] at least we 
>> can't seem to
>  turn it
>  off and it is causing the site build to take 
>> forever.
>  Thanks!
>
>  Phil
>
>
>> -
>  To unsubscribe, e-mail: 
>> dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: 
>> dev-h...@commons.apache.org
>> -
  To unsubscribe, e-mail: 
>> dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
>> dev-h...@commons.apache.org

>>>
>> -
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: 
>> dev-h...@commons.apache.org
>>>
>>
>> -
>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>

Re: [commons-parent] drop cobertura

[Oliver Heger]

Am 29.12.2012 21:21, schrieb Phil Steitz:

On 12/29/12 10:44 AM, Mark Struberg wrote:

Any better suggestions for [math]?

Yes, as I see it there are two options.

a.) move some parts into a profile


How exactly would this work?  Can we get rid of stuff that way,
really?  We can get it to ignore stuff the parent specifies?  Or are
you talking about yet another profile in the parent?


Could we move the major part of the reports into a profile which is not 
enabled per default? Then everybody can build a site locally containing 
all these reports by just enabling the profile. The official sites would 
not contain reports, but reference Sonar.


Oliver


b.) create 2 parent pom. One with the infrastructure stuff and one with all the 
tons of additional goodies only needed for the other projects.


That seems pretty ugly.  I wonder how bad it would be, actually, to
just get rid of the parent and define the stuff we actually use /
need in [math] itself.  I think I have on balance spent more time
figuring out what was going on in the parent than I would have spent
just maintaining properties actually used by the components that I
work on.  Maybe just strip it down to some common properties and
things like the mailing lists.  At the very least, we should drop
the reporting section and the one you mention below.




LieGrue,
strub


PS: I find it pretty weird that the commons-parent has a profile to build all the 
other stuff. This can be done much cleaner in having an own build-aggregator pom 
which just contains the .


Agreed.  I wonder if anyone ever uses this.  I would be +1 to drop.

Phil



- Original Message -

From: Phil Steitz 
To: Commons Developers List 
Cc:
Sent: Saturday, December 29, 2012 7:29 PM
Subject: Re: [commons-parent] drop cobertura

On 12/29/12 10:02 AM, Gary Gregory wrote:

  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
  commons components to Sonar, just do not mess up development for all the
  other components because one class in [math] is not performing acceptably
  for the Cobertura report.

The problem is that the plugin is bugged and effectively impossible
to turn off.

I think the sonar idea is a great one and consistent with what we
have talked about on and off for years - separating the CI-type
development reports from the component sites.  As we are about to go
over the "site deployment cliff ;"  now is a great time to think
about losing some weight :)

I guess an alternative for [math] is to drop commons-parent
entirely, just grabbing the stuff we need.  Any better suggestions
for [math]?

Phil

  Gary


  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz 

wrote:

  On 12/29/12 9:46 AM, Oliver Heger wrote:

  Am 29.12.2012 09:43, schrieb Luc Maisonobe:

  Hi Phil,

  Le 28/12/2012 21:10, Phil Steitz a écrit :

  On 12/28/12 11:44 AM, Gary Gregory wrote:

  It seems a shame to turn off this feature for ALL

projects

  because one
  project can't figure out a workaround.

  Can *any* project find a workaround?  Is there *any way* to

turn

  this thing off?

  What about every project being declared in the aggregator

project

  Olivier set up in our instance of Sonar
  ?


  +1

  We could then even disable more reports in the components' poms
  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
  instance.

  This would provide comprehensive up-to-date statistics for all
  components. It would also be a step forward in making the
  components more uniform.

  +1 - and as yet another bonus, it would reduce wasted infra
  resources duplicating all of the images, etc on all of the
  individual sites and the need to store all of that stuff in svn.

  Phil

  Oliver


  Luc


  Phil

  Gary

  On Dec 28, 2012, at 12:21, Phil Steitz



  wrote:


  Any objections to this?  In [math] at least we

can't seem to

  turn it
  off and it is causing the site build to take

forever.

  Thanks!

  Phil



-

  To unsubscribe, e-mail:

dev-unsubscr...@commons.apache.org

  For additional commands, e-mail:

dev-h...@commons.apache.org
-

  To unsubscribe, e-mail:

dev-unsubscr...@commons.apache.org

  For additional commands, e-mail:

dev-h...@commons.apache.org





-

  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail:

dev-h...@commons.apache.org





-

  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org




-

  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org



  

Re: [math] major problem with new released version 3.1

[Konstantin Berlin]

>> 
>> I think this issue can be overcome by proper OO design, and hacked on to
>> the current interface for now.
>> 
>> We can create an "InPlace" interface that all linear operators (including
>> RealMatrix etc) would implement. For example in a hypothetical
>> InPlaceMatrix class
>> 
>> function InPlaceVector mult(InPlaceVector x), depending on implementation
>> details, would either return back overwritten x in the return value, or a
>> new value for multiplication leaving x in tact. This would allow the user
>> to implement their more efficient version, while also allowing the usage of
>> current linear algebra package if they don't care about performance. The
>> idea is that the optimization classes would rely only on the InPlace
>> interface for all their tasks.
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> I'm not sure about that. If I understand correctly, this would mean that
> the _user_ has to provide the solver with a so-called InPlaceVector. I
> don't think it should be the responsibility of the user to chose whether or
> not a solver performs in place operations. As I said previously visitors
> are a good way to do that without cluttering the interface. For example, we
> could define a Multiply visitor, which scales all components of a vector. A
> nice idiom would be to have a factory method Multiply.by(double) instead of
> a constructor new Multiply(double). This way, scaling a vector in place
> would read
> v.walkInDefaultOrder(Multiply.by(double))
> 
> What do you think?
> Sébastien

The user would not have to do anything, since any RealMatrix implementation 
would implement the InPlace interface. The user is free to just pass in a 
standard RealMatrix class, it will just (temporarily) not actually perform an 
in place operation, so it would waste memory, but otherwise would provide 
correct behavior. The choice of InPlace operation (and any other required 
operation) is controlled by the implementation of the optimization solver, not 
the user. I think design wise it's better, since the optimization function does 
not require anything more basic than some class that implements a few vector 
operations. It does not need to rely on something as heavy as a RealMatrix, or 
as limiting as a double[][], and this would allow for the user to implement 
their own version, if they have some large problem that they want to optimize.

While visitor pattern is a good abstraction, I think it would make for terrible 
linear algebra performance. All operations should be based on basic vector 
operations, which internally can take advantage of sequential memory access. 
For large problems it makes a difference. The visitor pattern is a nice add on, 
but it should not be the engine driving the package under the hood, in my 
opinion.

-Konstantin
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Ted Dunning]

Actually, the visitor pattern or variants thereof can produce very
performant linear algebra implementations.  You can't usually get quite
down to optimized BLAS performance, but you get pretty darned fast code.

The reason is that the visitor is typically a very simple class which is
immediately inlined by the JIT.  Then it is subject to all of the normal
optimizations exactly as if the code were written as a single concrete
loop.  For many implementations, the bounds checks will be hoisted out of
the loop so you get pretty decent code.

More importantly in many cases, visitors allow in place algorithms.
 Combined with view operators that limit visibility to part of a matrix,
and the inlining phenomenon mentioned above, this can have enormous
implications to performance.

A great case in point is the Mahout math library.  With no special efforts
taken and using the visitor style fairly ubiquitously, I can get about 2 G
flops from my laptop.  Using Atlas as a LINPAK implementation gives me
about 5 G flops.

I agree with the point that linear algebra operators should be used where
possible, but that just isn't feasible for lots of operations in real
applications.  Getting solid performance with simple code in those
applications is a real virtue.

On Sat, Dec 29, 2012 at 3:22 PM, Konstantin Berlin wrote:

> While visitor pattern is a good abstraction, I think it would make for
> terrible linear algebra performance. All operations should be based on
> basic vector operations, which internally can take advantage of sequential
> memory access. For large problems it makes a difference. The visitor
> pattern is a nice add on, but it should not be the engine driving the
> package under the hood, in my opinion.
>

Re: [math] major problem with new released version 3.1

[Konstantin Berlin]

That's a good point about the compiler. I never tested the performance of 
visitors vs. sequential array access. I just don't want the vector operations 
to be tied to any particular implementation detail.

On Dec 29, 2012, at 6:30 PM, Ted Dunning  wrote:

> Actually, the visitor pattern or variants thereof can produce very
> performant linear algebra implementations.  You can't usually get quite
> down to optimized BLAS performance, but you get pretty darned fast code.
> 
> The reason is that the visitor is typically a very simple class which is
> immediately inlined by the JIT.  Then it is subject to all of the normal
> optimizations exactly as if the code were written as a single concrete
> loop.  For many implementations, the bounds checks will be hoisted out of
> the loop so you get pretty decent code.
> 
> More importantly in many cases, visitors allow in place algorithms.
> Combined with view operators that limit visibility to part of a matrix,
> and the inlining phenomenon mentioned above, this can have enormous
> implications to performance.
> 
> A great case in point is the Mahout math library.  With no special efforts
> taken and using the visitor style fairly ubiquitously, I can get about 2 G
> flops from my laptop.  Using Atlas as a LINPAK implementation gives me
> about 5 G flops.
> 
> I agree with the point that linear algebra operators should be used where
> possible, but that just isn't feasible for lots of operations in real
> applications.  Getting solid performance with simple code in those
> applications is a real virtue.
> 
> On Sat, Dec 29, 2012 at 3:22 PM, Konstantin Berlin wrote:
> 
>> While visitor pattern is a good abstraction, I think it would make for
>> terrible linear algebra performance. All operations should be based on
>> basic vector operations, which internally can take advantage of sequential
>> memory access. For large problems it makes a difference. The visitor
>> pattern is a nice add on, but it should not be the engine driving the
>> package under the hood, in my opinion.
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Konstantin Berlin]

Hi,

In my opinion is that the whole weights fiasco is consequence of improper 
design, as much as anything else. All components should be as simple as 
possible, with any additional add ons, like weights, not added to the base 
implementation, but instead done as an extension of these classes. If these was 
done, all the optimization packages would have been just fine, and only the 
extension classes would need fixing. 

I am very against having a correlation function be an input to the basic 
optimizers. The eigendecomposition of the matrix is an O(N^3) operation, which 
could be actually more expensive than the whole optimization. In addition you 
are doing this inversion every time you call the optimize method. If you are 
trying to do multiple starting points, you are forcing an inversion to be done 
each time.


On Dec 29, 2012, at 7:29 AM, Gilles Sadowski  
wrote:

> On Sat, Dec 29, 2012 at 10:22:20AM +0100, Dimitri Pourbaix wrote:
>> Gilles,
>> 
>>> Handling weighted observations must take correlations into account, i.e. use
>>> a _matrix_.
>>> There is the _practical_ problem of memory. Solving it correctly is by
>>> using a sparse implementation (and this is actually an implementation
>>> _detail_).
>> 
>> The problem is where something becomes a detail!  You are right that the
>> general least square problem copes with a matrix of weights ... but the
>> way it is implemented is a detail.
> 
> That's what I said above, although I suspect that we don't mean the same
> thing. OO programming allows to define types that will represent the
> "real" concepts: in this case, if the problem is expressed in terms of a
> a (mathematical) matrix, the algorithm should use a "Matrix" (type).
> This is not an implementation detail; the goal is for the code to be as
> close as possible to the mathematical description of the procedure
> (self-documenting code).
> 
> The implementation detail is how the matrix type stores its data internally;
> and this can be the subject of any necessary efficiency improvements,
> independently of the matrix concept used at a higher level (e.g. in the
> optimization algorithms).
> 
>> As already pointed out, even the
>> vector of weights API allows for a complicated matrix of weights.  The user
>> premultiplies by the 'square root' of that matrix and sets all the compo-
>> nents of the weight vector to 1.  So, your enthusiasm to generalise the
>> vector of weights to a matrix was a detail to make the life of very few
>> users easier ... without adding any functionality.
> 
> This is a backward description of my change.
> In reality:
> 1. The handling of weights was there.
> 2. Assuming that people wanted to keep it, I added the functionality to
>   handle correlated observations.
> 
> If indeed the weight feature is independent of the optimization procedure,
> then _all_ references to weights should be banned.
> [If just because keeping an array of "ones" and doing loops that "multiply
> by one" are obviously not going to improve clarity and performance.]
> Eventually, this seems to be the accepted compromise now (IIUC).
> 
>> There are so many different configurations (e.g. block diagonal, ...), I
>> doubt you can handle all of them in the most efficient way
> 
> Actually, my "Weight" class trivially handles _any_ "RealMatrix" (thanks to
> inheritance!).
> 
>> so it is likely
>> preferable to have the user taking care of them.
> 
> This is exactly what "Weight" does.
> The problem is that CM does not provide efficient implementations for
> matrix forms suited for this context (symmetric, sparse, diagonal).[1]
> 
> Above and in the previous post, I agreed that this would not be a problem i
> we entirely drop the support for weights in the optimizers.
> 
>> It is however true that simple weights (i.e. vector form) are a very usual
>> situation ... which is also very common in fitting tools.  So, I think CM
>> should offer that approach as well.
> 
> Where? In the fitting tools or in the optimizers?
> We just said that weights could be handled independenttly from the
> optimization procedure. But we could indeed put weights back where they are
> most useful (e.g. in the curve fitting) without dragging everywhere (where
> most of the time they'd be equal to one...).
> 
>> In conclusion: the old CM 3.0 API was enough! :)
> 
> If that's so, then people can just copy/paste the source code of that
> version and not care about subsequent versions of CM.
> 
> 
> Cordially,
> Gilles
> 
> [1] Actually, the problem is that some people complain that we don't do
>enough to their taste: In the past, at least 3 persons raised issues
>with matrix implementations, but without providing any useful help,
>unfortunately (to be clear, I'm not talking of current contributors!).
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [math] major problem with new released version 3.1

[Konstantin Berlin]

Also. If you have GPU implementation of a matrix, or use another type of a 
vector processor, there is no way you can program that in if you force vector 
operations to use a visitor patterns. 

On Dec 29, 2012, at 6:43 PM, Konstantin Berlin  wrote:

> That's a good point about the compiler. I never tested the performance of 
> visitors vs. sequential array access. I just don't want the vector operations 
> to be tied to any particular implementation detail.
> 
> On Dec 29, 2012, at 6:30 PM, Ted Dunning  wrote:
> 
>> Actually, the visitor pattern or variants thereof can produce very
>> performant linear algebra implementations.  You can't usually get quite
>> down to optimized BLAS performance, but you get pretty darned fast code.
>> 
>> The reason is that the visitor is typically a very simple class which is
>> immediately inlined by the JIT.  Then it is subject to all of the normal
>> optimizations exactly as if the code were written as a single concrete
>> loop.  For many implementations, the bounds checks will be hoisted out of
>> the loop so you get pretty decent code.
>> 
>> More importantly in many cases, visitors allow in place algorithms.
>> Combined with view operators that limit visibility to part of a matrix,
>> and the inlining phenomenon mentioned above, this can have enormous
>> implications to performance.
>> 
>> A great case in point is the Mahout math library.  With no special efforts
>> taken and using the visitor style fairly ubiquitously, I can get about 2 G
>> flops from my laptop.  Using Atlas as a LINPAK implementation gives me
>> about 5 G flops.
>> 
>> I agree with the point that linear algebra operators should be used where
>> possible, but that just isn't feasible for lots of operations in real
>> applications.  Getting solid performance with simple code in those
>> applications is a real virtue.
>> 
>> On Sat, Dec 29, 2012 at 3:22 PM, Konstantin Berlin wrote:
>> 
>>> While visitor pattern is a good abstraction, I think it would make for
>>> terrible linear algebra performance. All operations should be based on
>>> basic vector operations, which internally can take advantage of sequential
>>> memory access. For large problems it makes a difference. The visitor
>>> pattern is a nice add on, but it should not be the engine driving the
>>> package under the hood, in my opinion.
>>> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] major problem with new released version 3.1

[Ted Dunning]

Who said force?  Linear algebra operations should be available.

Visitors should be available.

Your mileage will vary.  That was always true.

On Sat, Dec 29, 2012 at 3:59 PM, Konstantin Berlin wrote:

> Also. If you have GPU implementation of a matrix, or use another type of a
> vector processor, there is no way you can program that in if you force
> vector operations to use a visitor patterns.
>
> On Dec 29, 2012, at 6:43 PM, Konstantin Berlin  wrote:
>
> > That's a good point about the compiler. I never tested the performance
> of visitors vs. sequential array access. I just don't want the vector
> operations to be tied to any particular implementation detail.
> >
> > On Dec 29, 2012, at 6:30 PM, Ted Dunning  wrote:
> >
> >> Actually, the visitor pattern or variants thereof can produce very
> >> performant linear algebra implementations.  You can't usually get quite
> >> down to optimized BLAS performance, but you get pretty darned fast code.
> >>
> >> The reason is that the visitor is typically a very simple class which is
> >> immediately inlined by the JIT.  Then it is subject to all of the normal
> >> optimizations exactly as if the code were written as a single concrete
> >> loop.  For many implementations, the bounds checks will be hoisted out
> of
> >> the loop so you get pretty decent code.
> >>
> >> More importantly in many cases, visitors allow in place algorithms.
> >> Combined with view operators that limit visibility to part of a matrix,
> >> and the inlining phenomenon mentioned above, this can have enormous
> >> implications to performance.
> >>
> >> A great case in point is the Mahout math library.  With no special
> efforts
> >> taken and using the visitor style fairly ubiquitously, I can get about
> 2 G
> >> flops from my laptop.  Using Atlas as a LINPAK implementation gives me
> >> about 5 G flops.
> >>
> >> I agree with the point that linear algebra operators should be used
> where
> >> possible, but that just isn't feasible for lots of operations in real
> >> applications.  Getting solid performance with simple code in those
> >> applications is a real virtue.
> >>
> >> On Sat, Dec 29, 2012 at 3:22 PM, Konstantin Berlin  >wrote:
> >>
> >>> While visitor pattern is a good abstraction, I think it would make for
> >>> terrible linear algebra performance. All operations should be based on
> >>> basic vector operations, which internally can take advantage of
> sequential
> >>> memory access. For large problems it makes a difference. The visitor
> >>> pattern is a nice add on, but it should not be the engine driving the
> >>> package under the hood, in my opinion.
> >>>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-parent] drop cobertura

[Olivier Lamy]

2012/12/29 Oliver Heger :
> Am 29.12.2012 21:21, schrieb Phil Steitz:
>
>> On 12/29/12 10:44 AM, Mark Struberg wrote:

 Any better suggestions for [math]?
>>>
>>> Yes, as I see it there are two options.
>>>
>>> a.) move some parts into a profile
>>
>>
>> How exactly would this work?  Can we get rid of stuff that way,
>> really?  We can get it to ignore stuff the parent specifies?  Or are
>> you talking about yet another profile in the parent?
>
>
> Could we move the major part of the reports into a profile which is not
> enabled per default? Then everybody can build a site locally containing all
> these reports by just enabling the profile. The official sites would not
> contain reports, but reference Sonar.
Sounds good call it reporting.
If folks want to run cobertura, findbugs etc they just need to add -Preporting.
If you want to publish those reports run maven site with it.

>
> Oliver
>
>
>>> b.) create 2 parent pom. One with the infrastructure stuff and one with
>>> all the tons of additional goodies only needed for the other projects.
>>
>>
>> That seems pretty ugly.  I wonder how bad it would be, actually, to
>> just get rid of the parent and define the stuff we actually use /
>> need in [math] itself.  I think I have on balance spent more time
>> figuring out what was going on in the parent than I would have spent
>> just maintaining properties actually used by the components that I
>> work on.  Maybe just strip it down to some common properties and
>> things like the mailing lists.  At the very least, we should drop
>> the reporting section and the one you mention below.
>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> PS: I find it pretty weird that the commons-parent has a profile to build
>>> all the other stuff. This can be done much cleaner in having an own
>>> build-aggregator pom which just contains the .
>>
>>
>> Agreed.  I wonder if anyone ever uses this.  I would be +1 to drop.
>>
>> Phil
>>>
>>>
>>>
>>> - Original Message -

 From: Phil Steitz 
 To: Commons Developers List 
 Cc:
 Sent: Saturday, December 29, 2012 7:29 PM
 Subject: Re: [commons-parent] drop cobertura

 On 12/29/12 10:02 AM, Gary Gregory wrote:
>
>   Using Sonar is an orthogonal issue to using reports in the POM. Sure,
> add
>   commons components to Sonar, just do not mess up development for all
> the
>   other components because one class in [math] is not performing
> acceptably
>   for the Cobertura report.

 The problem is that the plugin is bugged and effectively impossible
 to turn off.

 I think the sonar idea is a great one and consistent with what we
 have talked about on and off for years - separating the CI-type
 development reports from the component sites.  As we are about to go
 over the "site deployment cliff ;"  now is a great time to think
 about losing some weight :)

 I guess an alternative for [math] is to drop commons-parent
 entirely, just grabbing the stuff we need.  Any better suggestions
 for [math]?

 Phil
>
>   Gary
>
>
>   On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz 

 wrote:
>>
>>   On 12/29/12 9:46 AM, Oliver Heger wrote:
>>>
>>>   Am 29.12.2012 09:43, schrieb Luc Maisonobe:

   Hi Phil,

   Le 28/12/2012 21:10, Phil Steitz a écrit :
>
>   On 12/28/12 11:44 AM, Gary Gregory wrote:
>>
>>   It seems a shame to turn off this feature for ALL

 projects
>>
>>   because one
>>   project can't figure out a workaround.
>
>   Can *any* project find a workaround?  Is there *any way* to

 turn
>
>   this thing off?

   What about every project being declared in the aggregator

 project

   Olivier set up in our instance of Sonar
   ?

>>>   +1
>>>
>>>   We could then even disable more reports in the components' poms
>>>   (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
>>>   instance.
>>>
>>>   This would provide comprehensive up-to-date statistics for all
>>>   components. It would also be a step forward in making the
>>>   components more uniform.
>>
>>   +1 - and as yet another bonus, it would reduce wasted infra
>>   resources duplicating all of the images, etc on all of the
>>   individual sites and the need to store all of that stuff in svn.
>>
>>   Phil
>>>
>>>   Oliver
>>>
   Luc

>   Phil
>>
>>   Gary
>>
>>   On Dec 28, 2012, at 12:21, Phil Steitz

 
>>
>>   wrote:
>>
>>>   Any objections to this?  In [math] at least we

 can't seem to
>>>
>>>   turn it
>>>   o

Re: [commons-parent] cut a release?

[Olivier Lamy]

2012/12/29 Phil Steitz :
> To get sites prepared for svn pub/sub, we now need to depend on
> commons-parent snapshot.  We should cut a release so this is not
> necessary.  I have no idea how to do this.  I will RM if I can get a
> recipe that works and others are OK with releasing now.  It would be
> great if someone could add a readme to the parent svn showing how to
> cut a release, similar to what Gilles did for [math].
except the svn pub/sub is not correct in the parent.
still no response on https://issues.apache.org/jira/browse/INFRA-5657
but that will be probably
https://svn.apache.org/repos/infra/websites/production/commons/content

>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 105 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5 & Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-30122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-30122012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method getObject(String,Class) in ResultSet
[javac] public class DelegatingResultSet extends Aba

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 274 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-30122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-30122012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public clas

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 105 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 3 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] Building jar: 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/target/commons-digester3-samples-xmlrules-addressbook-3.3-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Commons Digester :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-digester3-ap:3.3-SNAPSHOT: checking 
for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-digester3-ap/3.3-SNAPSHOT/commons-digester3-ap-3.3-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-digester3-ap:pom:3.3-SNAPSHOT' in repository 
apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-digester3-ap/3.3-SNAPSHOT/commons-digester3-ap-3.3-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-digester3-ap:jar:3.3-SNAPSHOT' in repository 
apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-digester3-ap:jar:3.3-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-digester3-ap -Dversion=3.3-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-digester3-ap -Dversion=3.3-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-digester3-dist:pom:3.3-SNAPSHOT
2) org.apache.commons:commons-digester3-ap:jar:3.3-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-digester3-dist:pom:3.3-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Sun Dec 30 03:47:41 UTC 2012
[INFO] Final Memory: 92M/220M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-diges

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 296 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 48 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 46 seconds
[INFO] Finished at: Sun Dec 30 04:24:47 UTC 2012
[INFO] Final Memory: 103M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/atom

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 274 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1356844362894
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 30 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Mav

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 110 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 279 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 26 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.304 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.083 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO