Re: [math] RealVector.toArray() vs. RealVector.getData()

[Sébastien Brisard]

True enough.
Maybe the use of one those two could be strongly discouraged.
I personally was puzzled the first time I saw those two methods. I was
even wondering wether one of them would not return a shallow copy
(when possible), while the other would return a deep copy. Had to look
at the source to finally realize that toArray() and getData() do
exactly the same thing.
As for incompatible change, we are talking about 3.0, which gives us
(that's how I understand it anyway) a little bit of liberty, as long
as it improves the library.
Sébastien

2011/9/7 Jochen Wiedmann :
> 2011/9/7 Sébastien Brisard :
>> Hi,
>> as noted in MATH-653, these two methods are redundant, and one should
>> go. Pros and cons are
>> * toArray() is fairly classical in the Java world
>> * but getData() is consistent with ArrayRealVector.getDataRef().
>> Personnaly, my preference goes to keeping toArray(). In order to
>> maintain consistency, should ArrayRealVector.getDataRef() be renamed
>> getArrayRef() ?
>
> Another Con; INcompatible change, which should be avoided, if
> possible. Redundancy is not a compelling reason for such changes.
>
> --
> Capitalism is the astounding belief that the most wickedest of men
> will do the most wickedest of things for the greatest good of
> everyone.
>
> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)
>
> https://linuxcounter.net/user/221257.html
>
> -
> 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] RealVector.toArray() vs. RealVector.getData()

[Jochen Wiedmann]

2011/9/7 Sébastien Brisard :
> Hi,
> as noted in MATH-653, these two methods are redundant, and one should
> go. Pros and cons are
> * toArray() is fairly classical in the Java world
> * but getData() is consistent with ArrayRealVector.getDataRef().
> Personnaly, my preference goes to keeping toArray(). In order to
> maintain consistency, should ArrayRealVector.getDataRef() be renamed
> getArrayRef() ?

Another Con; INcompatible change, which should be avoided, if
possible. Redundancy is not a compelling reason for such changes.

-- 
Capitalism is the astounding belief that the most wickedest of men
will do the most wickedest of things for the greatest good of
everyone.

John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)

https://linuxcounter.net/user/221257.html

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

Re: [math] RealVector.toArray() vs. RealVector.getData()

[Sébastien Brisard]

In fact, getArrayRef does not belong to the RealVector class. It is
only defined in ArrayRealVector (which is backed by a double[]).
Sébastien

2011/9/7 Arne Ploese :
> If toArray() returns always a copy and if getArrayRef() throws an
> exception if there is no backing array, it would be much clearer. A
> property isArray() is needed in this case.
>
> Arne
>
> Am Mittwoch, den 07.09.2011, 04:19 +0200 schrieb Sébastien Brisard:
>> Hi,
>> as noted in MATH-653, these two methods are redundant, and one should
>> go. Pros and cons are
>> * toArray() is fairly classical in the Java world
>> * but getData() is consistent with ArrayRealVector.getDataRef().
>> Personnaly, my preference goes to keeping toArray(). In order to
>> maintain consistency, should ArrayRealVector.getDataRef() be renamed
>> getArrayRef() ?
>>
>> Sébastien
>>
>> -
>> 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] RealVector.toArray() vs. RealVector.getData()

[Arne Ploese]

If toArray() returns always a copy and if getArrayRef() throws an
exception if there is no backing array, it would be much clearer. A
property isArray() is needed in this case.

Arne

Am Mittwoch, den 07.09.2011, 04:19 +0200 schrieb Sébastien Brisard: 
> Hi,
> as noted in MATH-653, these two methods are redundant, and one should
> go. Pros and cons are
> * toArray() is fairly classical in the Java world
> * but getData() is consistent with ArrayRealVector.getDataRef().
> Personnaly, my preference goes to keeping toArray(). In order to
> maintain consistency, should ArrayRealVector.getDataRef() be renamed
> getArrayRef() ?
> 
> Sébastien
> 
> -
> 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: [parent] time to vote on 22?

[Gary Gregory]

On Wed, Sep 7, 2011 at 12:22 AM, Ralph Goers wrote:

> Why is the idea plugin defined?  IntelliJ hasn't needed it in a long time.
>

Good question.

Should we get rid of it?

The warning at the start of all commons build is annoying.

Gary


>
> Ralph
>
> On Sep 6, 2011, at 7:23 PM, Gary Gregory wrote:
>
> > Hi All:
> >
> > It feels like it's about time to vote on releasing version 22?
> >
> > Thoughts?
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://s.apache.org/rl
> > Spring Batch in Action: http://s.apache.org/HOq
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>
> -
> 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://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [parent] time to vote on 22?

[Ralph Goers]

Why is the idea plugin defined?  IntelliJ hasn't needed it in a long time.

Ralph

On Sep 6, 2011, at 7:23 PM, Gary Gregory wrote:

> Hi All:
> 
> It feels like it's about time to vote on releasing version 22?
> 
> Thoughts?
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://s.apache.org/rl
> Spring Batch in Action: http://s.apache.org/HOq
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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

[parent] time to vote on 22?

[Gary Gregory]

Hi All:

It feels like it's about time to vote on releasing version 22?

Thoughts?

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

[math] RealVector.toArray() vs. RealVector.getData()

[Sébastien Brisard]

Hi,
as noted in MATH-653, these two methods are redundant, and one should
go. Pros and cons are
* toArray() is fairly classical in the Java world
* but getData() is consistent with ArrayRealVector.getDataRef().
Personnaly, my preference goes to keeping toArray(). In order to
maintain consistency, should ArrayRealVector.getDataRef() be renamed
getArrayRef() ?

Sébastien

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

Re: [MATH-653] Closing MATH-653?

[Sébastien Brisard]

I don't think MATH-653 has been marked as resolved...

2011/9/6 Gilles Sadowski :
>> [...]
>> >
>> >>Also, when
>> >>opening a new ticket, should it be assigned to someone, if this person
>> >>agrees to take care of it?
>> >
>> >If you are willing to fix some issue, you should probably assign it to
>> >yourself. That would help prevent duplicate work.
>>
>> As far as I know, it's this other way round. When someone wants to
>> solve the issue, he assigned it to him directly, thus saying to
>> other people to not waste their time on it. We don't use it too
>> often, but it helps sharing the work.
>
> Hmm, I think that's what I said... ;-)
>
>
> Gilles
>
> -
> 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

[math] Iteration manager [was: General framework for iterative algorithms]

[Sébastien Brisard]

Hi,
please let me know what you think of the modified code I've attached
to MATH-655. I took Phil's into account (composition vs. inheritance).
I believe the provided classes would go into o.a.c.m.util.
Thanks beforehand for your comments,
Sébastien

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

Re: svn commit: r1165846 [2/2] - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java

[sebb]

On 7 September 2011 00:04, Gilles Sadowski  wrote:
> Hello.
>
>> Modified: 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846&r1=1165845&r2=1165846&view=diff
>> ==
>> --- 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>>  (original)
>> +++ 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>>  Tue Sep  6 21:06:58 2011
>> @@ -74,31 +74,6147 @@ public class FastMath {
>>      /** Napier's constant e, base of the natural logarithm. */
>>      public static final double E = 2850325.0 / 1048576.0 + 
>> 8.254840070411028747e-8;
>>
>> +    private static final int EXP_INT_TABLE_MAX_INDEX = 750;
>> +    private static final int EXP_INT_TABLE_LEN = EXP_INT_TABLE_MAX_INDEX * 
>> 2;
>> +
>>      /** Exponential evaluated at integer values,
>> -     * exp(x) =  expIntTableA[x + 750] + expIntTableB[x+750].
>> +     * exp(x) =  expIntTableA[x + EXP_INT_TABLE_MAX_INDEX] + 
>> expIntTableB[x+EXP_INT_TABLE_MAX_INDEX].
>>       */
>> -    private static final double EXP_INT_TABLE_A[] = new double[1500];
>> +    private static final double EXP_INT_TABLE_A[] =
>> +    {
>> +        +0.0d,
>> +        Double.NaN,
>
> [More than 6000 lines stripped.]
>
> Wouldn't it be advantageous to store those tabulated data in separate
> Java files? E.g.
> ---
> class ExpIntTables {
>    static final double[] A = {
>      // Very long table.
>    };
>    static final double[] B = {
>      // ...
>    };
> ---
>
> And in "FastMath.java":
> ---
> public class FastMath {
>    private static final double[] EXP_INT_TABLE_A = ExpIntTables.A;
>    private static final double[] EXP_INT_TABLE_B = ExpIntTables.B;
> }
> ---

That would be possible, but would require the tables to be
non-private, increasing the theoretical risk of accidental changes.

>
> Gilles
>
> -
> 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: svn commit: r1165846 [2/2] - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java

[Gilles Sadowski]

Hello.

> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846&r1=1165845&r2=1165846&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>  Tue Sep  6 21:06:58 2011
> @@ -74,31 +74,6147 @@ public class FastMath {
>  /** Napier's constant e, base of the natural logarithm. */
>  public static final double E = 2850325.0 / 1048576.0 + 
> 8.254840070411028747e-8;
>  
> +private static final int EXP_INT_TABLE_MAX_INDEX = 750;
> +private static final int EXP_INT_TABLE_LEN = EXP_INT_TABLE_MAX_INDEX * 2;
> +
>  /** Exponential evaluated at integer values,
> - * exp(x) =  expIntTableA[x + 750] + expIntTableB[x+750].
> + * exp(x) =  expIntTableA[x + EXP_INT_TABLE_MAX_INDEX] + 
> expIntTableB[x+EXP_INT_TABLE_MAX_INDEX].
>   */
> -private static final double EXP_INT_TABLE_A[] = new double[1500];
> +private static final double EXP_INT_TABLE_A[] = 
> +{
> ++0.0d,
> +Double.NaN,

[More than 6000 lines stripped.]

Wouldn't it be advantageous to store those tabulated data in separate
Java files? E.g.
---
class ExpIntTables {
static final double[] A = {
  // Very long table.
};
static final double[] B = {
  // ...
};
---

And in "FastMath.java":
---
public class FastMath {
private static final double[] EXP_INT_TABLE_A = ExpIntTables.A;
private static final double[] EXP_INT_TABLE_B = ExpIntTables.B;
}
---


Gilles

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

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[Gary Gregory]

On Tue, Sep 6, 2011 at 4:53 PM, sebb  wrote:

> On 6 September 2011 17:55, Gary Gregory  wrote:
> > Here is the current set up:
> >
> > - To run tests: Same as before: "mvn test"
> > - To runt tests with the Java security manager: comment out some XML in
> the
> > POM and run "mvn integration-test"
> >
> > The policy file does for Sufire+JUnit 4 what Surefire does by itself for
> > JUnit 3: It grants Surefire and JUnit just enough permissions to run
> tests,
> > no more, no less.
> >
> > Surefire needs to get fixed.
> >
> > I hope this clarifies it all :)
>
> OK, I see now [1] et seq.
>

I created http://jira.codehaus.org/browse/SUREFIRE-767 to track JUnit 4
support.


>
> With JUnit3, Surefire is able to independently change the permissions
> for the Surefire and JUnit code, regardless of whatever permissions
> are set up for the test run as a whole.
>
> Otherwise, the permissions have to be set up to support the test code
> and the code under test.
>

Right, the current policy file is enough to get tests started but does not
guarantee a clean separation b/w the test infra and the tests themselves.

Gary

>
> [1]
> http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html#Using_a_security_manager_JUnit3_only
>
> > Gary
> >
> > On Tue, Sep 6, 2011 at 12:42 PM, sebb  wrote:
> >
> >> On 6 September 2011 17:16, Gary Gregory  wrote:
> >> > On Tue, Sep 6, 2011 at 11:14 AM, sebb  wrote:
> >> >
> >> >> On 6 September 2011 15:44, Gary Gregory 
> wrote:
> >> >> > On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
> >> >> >
> >> >> >> On 6 September 2011 13:46,   wrote:
> >> >> >> > Author: ggregory
> >> >> >> > Date: Tue Sep  6 12:46:39 2011
> >> >> >> > New Revision: 1165645
> >> >> >> >
> >> >> >> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> >> >> >> > Log:
> >> >> >> > Changes for [parent] 22-SNAPSHOT.
> >> >> >> >
> >> >> >> > Modified:
> >> >> >> >commons/proper/lang/trunk/src/test/resources/java.policy
> >> >> >> >
> >> >> >> > Modified:
> commons/proper/lang/trunk/src/test/resources/java.policy
> >> >> >> > URL:
> >> >> >>
> >> >>
> >>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
> >> >> >> >
> >> >> >>
> >> >>
> >>
> ==
> >> >> >> > --- commons/proper/lang/trunk/src/test/resources/java.policy
> >> >> (original)
> >> >> >> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue
> >> Sep
> >> >>  6
> >> >> >> 12:46:39 2011
> >> >> >> > @@ -194,6 +194,7 @@ grant {
> >> >> >> >  //at
> >> >> >>
> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >> >> >
> >> >> >> >   permission java.io.FilePermission
> >> >> >>
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
> >> >> >> "read";
> >> >> >> > +  permission java.io.FilePermission
> >> >> >>
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
> >> >> >> "read";
> >> >> >>
> >> >> >> That won't work for me - I use a customised repo directory. Also
> it's
> >> >> >> a pain to keep changing the jar versions.
> >> >> >> Probably won't work for some IDEs either, and may not work on CIs
> >> such
> >> >> >> as Gump and Continuum.
> >> >> >>
> >> >> >> Is there any way to give the test classes normal permissions, and
> >> just
> >> >> >> restrict the classes under test?
> >> >> >>
> >> >> >
> >> >> > Yes, only if you use Surefire with JUnit 3. JUnit 4 is not
> supported
> >> >> IIRC.
> >> >>
> >> >> Surely this is a JAAS issue?
> >> >>
> >> >
> >> > This is about configuring JAAS, which surefire does for JUnit 3 but
> not 4
> >> > (based on what I read).
> >>
> >> I thought it was controlled by setting properties for the JVM, i.e.
> >> nothing to do with Surefire (except it has to pass the parameters to
> >> the forked JVM).
> >>
> >> > Gary
> >> >
> >> >
> >> >>
> >> >> > Gary
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> >
> >> >> >> >  //java.security.AccessControlException: access denied
> >> >> >> (java.io.FilePermission
> >> >> >>
> >> >>
> >>
> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
> >> >> >> read)
> >> >> >> > @@ -212,6 +213,7 @@ grant {
> >> >> >> >  //at
> >> >> >>
> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >> >> >
> >> >> >> >   permission java.io.FilePermission
> >> >> >>
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
> >> >> >> "read";
> >> >> >> > +  permission java.io.FilePermission
> >> >> >>
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
> >> >> >> "read";
> >> >> >> >
> >> >> >> >
> >> >> >> >  //java.security.AccessControlException: access denied

Re: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[sebb]

On 6 September 2011 19:47, Oliver Heger  wrote:
> Am 06.09.2011 04:40, schrieb sebb:
>>
>> On 5 September 2011 21:20, sebb  wrote:
>>>
>>> On 5 September 2011 19:19, Oliver Heger
>>>  wrote:

 Am 05.09.2011 15:52, schrieb sebb:
>
> On 5 September 2011 10:42, Oliver Heger
>  wrote:
>>
>> Am 05.09.2011 02:03, schrieb sebb:
>>>
>>> On 4 September 2011 20:07, Oliver Heger
>>>  wrote:

 Am 02.09.2011 17:08, schrieb sebb AT ASF:
>
> I've updated to the latest versions of all the plugins.
>
> Some of these changes may well cause problems, but the best way to
> find this out is for various people to try using the POM, so I've
> uploaded 22-SNAPSHOT to the snapshot repo.
>
> Please report any issues with using 22-SNAPSHOT (you have to
> temporarily update your pom to use it; it does not happen
> automatically).
>
> S///

 I tested the new snapshot version with [configuration]. Both
 building
 the
 jar and the site succeed.

 However, the generated site has some defects: The navigation is
 missing
 some
 links, e.g. for project info and reports. Also, the header and the
 logo
 are
 not displayed correctly. It seems that elements inherited from the
 template
 for all commons sites are not processed.
>>>
>>> What was the last comons parent version for which the site did build
>>> correctly?
>>
>> Version 21.
>>
>> But it seems Jörg has found a solution for this problem.
>
> I've tried building the configuration site with
>
> mvn site -DskipTests -Dmaven.javadoc.skip -Dmaven.clover.skip
> -Dcobertura.skip
>
> (the skips are to speed it up)
>
> When I compare the output for parent 21 and parent 22-SNAPSHOT there
> are quite a few differences which are due to ordering changes in
> reports and html attributes, but I don't see any obvious missing
> links.
>
> Tried with both Maven 2.2.1 and 3.0.3.
>
> So what are some of the errors you have seen?
> And what command did you use to create the site?
>
> The only minor issue I can see is that the configuration site.xml has
> leading / for some links; these are not necessary and should be
> removed.

 I used the command mvn clean site:site, maven version is 2.2.1 on
 Windows 7,
 JDK 1.6. I uploaded the results at
 http://people.apache.org/~oheger/configuration-site/
>>>
>>> I see - looks like the site has been generated from the local site.xml
>>> only, completely ignoring commons parent site.xml
>>>
>>> I suspect your local repo does not have the site.xml file - have a
>>> look and see, it should be under
>>>
>>> \repository\org\apache\commons\commons-parent\22-SNAPSHOT
>>>
>>> I just checked, and the site.xml file has been uploaded to the SNAPSHOT
>>> repo at:
>>>
>>>
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/22-SNAPSHOT/
>>>
>>> but when I tried deleting the local copy, only the pom was downloaded
>>> from the snapshot repo - maybe a bug in Maven?
>>
>> I tried to reproduce the error to report the issue, and initially it
>> apppeared to show that site.xml was not being downloaded.
>> However, now I cannot get the download to fail. No idea why it has
>> suddenly started working for me.
>>
>> Note that the site.xml is only downloaded as part of the Maven site
>> processing.
>>
>> I've also updated the snapshot; there were stale references to site
>> v2.2 and 3.0-beta3.
>
> Did some more testing: Obviously, there was actually something wrong with
> site.xml in my local repository. There were two site.xml files (standard and
> _en), but both were empty.
>
> I did a fresh checkout of commons-parent and built it using mvn install, and
> this helped. Now I have a correct site.xml in my local repository.
>
> Consequently the site looks much better now. The only difference I noticed
> is that excludes for the RAT plug-in seem to behave differently now. In the
> configuration pom the conf directory is excluded, but nevertheless the RAT
> report lists the files with unknown licenses.

That's because the RAT plugin is now under a different Maven group and
id; you need to use

org.apache.rat
apache-rat-plugin
not
org.codehaus.mojo
rat-maven-plugin

> Oliver
>
>>
>>> To fix this, update to the current commons-parent, and use mvn install
>>> from your local workspace.
>>>
 The same command with commons-parent 21 produced the site which is part
 of
 the ongoing vote for the configuration release:
 http://people.apache.org/~oheger/configuration-1.7rc3/site/

 Oliver

>
>> Oliver
>>
>>>
 Oliver

>
> On 2 September 2011 15:58,        w

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[sebb]

On 6 September 2011 17:55, Gary Gregory  wrote:
> Here is the current set up:
>
> - To run tests: Same as before: "mvn test"
> - To runt tests with the Java security manager: comment out some XML in the
> POM and run "mvn integration-test"
>
> The policy file does for Sufire+JUnit 4 what Surefire does by itself for
> JUnit 3: It grants Surefire and JUnit just enough permissions to run tests,
> no more, no less.
>
> Surefire needs to get fixed.
>
> I hope this clarifies it all :)

OK, I see now [1] et seq.

With JUnit3, Surefire is able to independently change the permissions
for the Surefire and JUnit code, regardless of whatever permissions
are set up for the test run as a whole.

Otherwise, the permissions have to be set up to support the test code
and the code under test.

[1] 
http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html#Using_a_security_manager_JUnit3_only

> Gary
>
> On Tue, Sep 6, 2011 at 12:42 PM, sebb  wrote:
>
>> On 6 September 2011 17:16, Gary Gregory  wrote:
>> > On Tue, Sep 6, 2011 at 11:14 AM, sebb  wrote:
>> >
>> >> On 6 September 2011 15:44, Gary Gregory  wrote:
>> >> > On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
>> >> >
>> >> >> On 6 September 2011 13:46,   wrote:
>> >> >> > Author: ggregory
>> >> >> > Date: Tue Sep  6 12:46:39 2011
>> >> >> > New Revision: 1165645
>> >> >> >
>> >> >> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
>> >> >> > Log:
>> >> >> > Changes for [parent] 22-SNAPSHOT.
>> >> >> >
>> >> >> > Modified:
>> >> >> >    commons/proper/lang/trunk/src/test/resources/java.policy
>> >> >> >
>> >> >> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
>> >> >> > URL:
>> >> >>
>> >>
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
>> >> >> >
>> >> >>
>> >>
>> ==
>> >> >> > --- commons/proper/lang/trunk/src/test/resources/java.policy
>> >> (original)
>> >> >> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue
>> Sep
>> >>  6
>> >> >> 12:46:39 2011
>> >> >> > @@ -194,6 +194,7 @@ grant {
>> >> >> >  //            at
>> >> >>
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >> >> >
>> >> >> >   permission java.io.FilePermission
>> >> >>
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
>> >> >> "read";
>> >> >> > +  permission java.io.FilePermission
>> >> >>
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
>> >> >> "read";
>> >> >>
>> >> >> That won't work for me - I use a customised repo directory. Also it's
>> >> >> a pain to keep changing the jar versions.
>> >> >> Probably won't work for some IDEs either, and may not work on CIs
>> such
>> >> >> as Gump and Continuum.
>> >> >>
>> >> >> Is there any way to give the test classes normal permissions, and
>> just
>> >> >> restrict the classes under test?
>> >> >>
>> >> >
>> >> > Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported
>> >> IIRC.
>> >>
>> >> Surely this is a JAAS issue?
>> >>
>> >
>> > This is about configuring JAAS, which surefire does for JUnit 3 but not 4
>> > (based on what I read).
>>
>> I thought it was controlled by setting properties for the JVM, i.e.
>> nothing to do with Surefire (except it has to pass the parameters to
>> the forked JVM).
>>
>> > Gary
>> >
>> >
>> >>
>> >> > Gary
>> >> >
>> >> >
>> >> >>
>> >> >> >
>> >> >> >  //    java.security.AccessControlException: access denied
>> >> >> (java.io.FilePermission
>> >> >>
>> >>
>> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
>> >> >> read)
>> >> >> > @@ -212,6 +213,7 @@ grant {
>> >> >> >  //at
>> >> >>
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >> >> >
>> >> >> >   permission java.io.FilePermission
>> >> >>
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
>> >> >> "read";
>> >> >> > +  permission java.io.FilePermission
>> >> >>
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
>> >> >> "read";
>> >> >> >
>> >> >> >
>> >> >> >  //    java.security.AccessControlException: access denied
>> >> >> (java.lang.RuntimePermission createClassLoader)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> -
>> >> >> 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://s.apache.org/rl
>> >> > Spring Batch in Action: http://s.apache.org/HOq
>> >> > Blog: http://garygregory.wordpress.com
>> >> 

Re: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Oliver Heger]

Am 06.09.2011 04:40, schrieb sebb:

On 5 September 2011 21:20, sebb  wrote:

On 5 September 2011 19:19, Oliver Heger  wrote:

Am 05.09.2011 15:52, schrieb sebb:


On 5 September 2011 10:42, Oliver Heger
  wrote:


Am 05.09.2011 02:03, schrieb sebb:


On 4 September 2011 20:07, Oliver Heger
  wrote:


Am 02.09.2011 17:08, schrieb sebb AT ASF:


I've updated to the latest versions of all the plugins.

Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.

Please report any issues with using 22-SNAPSHOT (you have to
temporarily update your pom to use it; it does not happen
automatically).

S///


I tested the new snapshot version with [configuration]. Both building
the
jar and the site succeed.

However, the generated site has some defects: The navigation is missing
some
links, e.g. for project info and reports. Also, the header and the logo
are
not displayed correctly. It seems that elements inherited from the
template
for all commons sites are not processed.


What was the last comons parent version for which the site did build
correctly?


Version 21.

But it seems Jörg has found a solution for this problem.


I've tried building the configuration site with

mvn site -DskipTests -Dmaven.javadoc.skip -Dmaven.clover.skip
-Dcobertura.skip

(the skips are to speed it up)

When I compare the output for parent 21 and parent 22-SNAPSHOT there
are quite a few differences which are due to ordering changes in
reports and html attributes, but I don't see any obvious missing
links.

Tried with both Maven 2.2.1 and 3.0.3.

So what are some of the errors you have seen?
And what command did you use to create the site?

The only minor issue I can see is that the configuration site.xml has
leading / for some links; these are not necessary and should be
removed.


I used the command mvn clean site:site, maven version is 2.2.1 on Windows 7,
JDK 1.6. I uploaded the results at
http://people.apache.org/~oheger/configuration-site/


I see - looks like the site has been generated from the local site.xml
only, completely ignoring commons parent site.xml

I suspect your local repo does not have the site.xml file - have a
look and see, it should be under

\repository\org\apache\commons\commons-parent\22-SNAPSHOT

I just checked, and the site.xml file has been uploaded to the SNAPSHOT repo at:

https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/22-SNAPSHOT/

but when I tried deleting the local copy, only the pom was downloaded
from the snapshot repo - maybe a bug in Maven?


I tried to reproduce the error to report the issue, and initially it
apppeared to show that site.xml was not being downloaded.
However, now I cannot get the download to fail. No idea why it has
suddenly started working for me.

Note that the site.xml is only downloaded as part of the Maven site processing.

I've also updated the snapshot; there were stale references to site
v2.2 and 3.0-beta3.


Did some more testing: Obviously, there was actually something wrong 
with site.xml in my local repository. There were two site.xml files 
(standard and _en), but both were empty.


I did a fresh checkout of commons-parent and built it using mvn install, 
and this helped. Now I have a correct site.xml in my local repository.


Consequently the site looks much better now. The only difference I 
noticed is that excludes for the RAT plug-in seem to behave differently 
now. In the configuration pom the conf directory is excluded, but 
nevertheless the RAT report lists the files with unknown licenses.


Oliver




To fix this, update to the current commons-parent, and use mvn install
from your local workspace.


The same command with commons-parent 21 produced the site which is part of
the ongoing vote for the configuration release:
http://people.apache.org/~oheger/configuration-1.7rc3/site/

Oliver




Oliver




Oliver



On 2 September 2011 15:58,wrote:


Author: sebb
Date: Fri Sep  2 14:58:22 2011
New Revision: 1164565

URL: http://svn.apache.org/viewvc?rev=1164565&view=rev
Log:
Update to latest versions of plugins
TODO - these need checking on projects

Modified:
commons/proper/commons-parent/trunk/pom.xml

Modified: commons/proper/commons-parent/trunk/pom.xml
URL:


http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1164565&r1=1164564&r2=1164565&view=diff



==
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Fri Sep  2 14:58:22
2011
@@ -151,7 +151,7 @@
 
   org.apache.maven.plugins
   maven-compiler-plugin
-2.1
+2.3.2
   
 ${maven.compile.source}
 ${maven.compile.target}
@@ -164,12 +164,12 @@
 
   org.apache.maven.plugins
   maven-deploy-plugin
-2.6
+2.7

Re: [MATH-653] Closing MATH-653?

[Gilles Sadowski]

> [...]
> >
> >>Also, when
> >>opening a new ticket, should it be assigned to someone, if this person
> >>agrees to take care of it?
> >
> >If you are willing to fix some issue, you should probably assign it to
> >yourself. That would help prevent duplicate work.
> 
> As far as I know, it's this other way round. When someone wants to
> solve the issue, he assigned it to him directly, thus saying to
> other people to not waste their time on it. We don't use it too
> often, but it helps sharing the work.

Hmm, I think that's what I said... ;-)


Gilles

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

Re: [MATH-653] Closing MATH-653?

[Luc Maisonobe]

Le 06/09/2011 14:29, Gilles Sadowski a écrit :

Hello.


Hi,




as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.


That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on "RealVector".


The same thing should probably be done with solve(double[][]),


You could create a ticket for this already, to keep track of the tasks
that must be performed.


Gilles suggested we should probably wait and see what is going to
happen to the RealMatrix interface (creating views and all that) ===>
has a consensus been arrived at on this issue? This is a very exciting
topic, but I got the feeling that it meant: start again from zero.


The discussion seems to have quiet down; so starting the refactoring with
the removal of methods with primitive array argument is fine too, I think...



I haven't proceeded yet to clean FieldDecompositionSolver in the same
spirit. Should it be done?


That would seem logical.
But, let's wait for a confirmation.


Yes, these two classes hierarchies should be as similar as possible.




On a more general level, what's the policy in terms of closing a JIRA
ticket. I've looked on the website but could not find guidance. Who
takes the decision, on what grounds (question on the ML?).


If you mean "Close", I think that this is done only just before a release.

If you mean "Resolve", I guess that you can do it when the changes described
in the issue have been applied. If some additional changes (not formally
agreed on) were needed in the patch, I'd (usually) request agreement by
adding a comment to that effect, and if no objection is raised within a few
days, I'd set the issue as resolved.  One can always reopen it afterwards if
necessary.


Yes. We set the issue as "Resolved" when a fix is available, and 
"Closed" when it has been released.





Also, when
opening a new ticket, should it be assigned to someone, if this person
agrees to take care of it?


If you are willing to fix some issue, you should probably assign it to
yourself. That would help prevent duplicate work.


As far as I know, it's this other way round. When someone wants to solve 
the issue, he assigned it to him directly, thus saying to other people 
to not waste their time on it. We don't use it too often, but it helps 
sharing the work.


Luc




Best,
Gilles

-
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: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[Gary Gregory]

Here is the current set up:

- To run tests: Same as before: "mvn test"
- To runt tests with the Java security manager: comment out some XML in the
POM and run "mvn integration-test"

The policy file does for Sufire+JUnit 4 what Surefire does by itself for
JUnit 3: It grants Surefire and JUnit just enough permissions to run tests,
no more, no less.

Surefire needs to get fixed.

I hope this clarifies it all :)

Gary

On Tue, Sep 6, 2011 at 12:42 PM, sebb  wrote:

> On 6 September 2011 17:16, Gary Gregory  wrote:
> > On Tue, Sep 6, 2011 at 11:14 AM, sebb  wrote:
> >
> >> On 6 September 2011 15:44, Gary Gregory  wrote:
> >> > On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
> >> >
> >> >> On 6 September 2011 13:46,   wrote:
> >> >> > Author: ggregory
> >> >> > Date: Tue Sep  6 12:46:39 2011
> >> >> > New Revision: 1165645
> >> >> >
> >> >> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> >> >> > Log:
> >> >> > Changes for [parent] 22-SNAPSHOT.
> >> >> >
> >> >> > Modified:
> >> >> >commons/proper/lang/trunk/src/test/resources/java.policy
> >> >> >
> >> >> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
> >> >> > URL:
> >> >>
> >>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
> >> >> >
> >> >>
> >>
> ==
> >> >> > --- commons/proper/lang/trunk/src/test/resources/java.policy
> >> (original)
> >> >> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue
> Sep
> >>  6
> >> >> 12:46:39 2011
> >> >> > @@ -194,6 +194,7 @@ grant {
> >> >> >  //at
> >> >>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >> >
> >> >> >   permission java.io.FilePermission
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
> >> >> "read";
> >> >> > +  permission java.io.FilePermission
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
> >> >> "read";
> >> >>
> >> >> That won't work for me - I use a customised repo directory. Also it's
> >> >> a pain to keep changing the jar versions.
> >> >> Probably won't work for some IDEs either, and may not work on CIs
> such
> >> >> as Gump and Continuum.
> >> >>
> >> >> Is there any way to give the test classes normal permissions, and
> just
> >> >> restrict the classes under test?
> >> >>
> >> >
> >> > Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported
> >> IIRC.
> >>
> >> Surely this is a JAAS issue?
> >>
> >
> > This is about configuring JAAS, which surefire does for JUnit 3 but not 4
> > (based on what I read).
>
> I thought it was controlled by setting properties for the JVM, i.e.
> nothing to do with Surefire (except it has to pass the parameters to
> the forked JVM).
>
> > Gary
> >
> >
> >>
> >> > Gary
> >> >
> >> >
> >> >>
> >> >> >
> >> >> >  //java.security.AccessControlException: access denied
> >> >> (java.io.FilePermission
> >> >>
> >>
> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
> >> >> read)
> >> >> > @@ -212,6 +213,7 @@ grant {
> >> >> >  //at
> >> >>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >> >
> >> >> >   permission java.io.FilePermission
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
> >> >> "read";
> >> >> > +  permission java.io.FilePermission
> >> >>
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
> >> >> "read";
> >> >> >
> >> >> >
> >> >> >  //java.security.AccessControlException: access denied
> >> >> (java.lang.RuntimePermission createClassLoader)
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> -
> >> >> 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://s.apache.org/rl
> >> > Spring Batch in Action: http://s.apache.org/HOq
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >> >
> >>
> >> -
> >> 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://s.apache.org/rl
> > Spring Batch in Action: http://s.apache.org/HOq
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
> 

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[sebb]

On 6 September 2011 17:16, Gary Gregory  wrote:
> On Tue, Sep 6, 2011 at 11:14 AM, sebb  wrote:
>
>> On 6 September 2011 15:44, Gary Gregory  wrote:
>> > On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
>> >
>> >> On 6 September 2011 13:46,   wrote:
>> >> > Author: ggregory
>> >> > Date: Tue Sep  6 12:46:39 2011
>> >> > New Revision: 1165645
>> >> >
>> >> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
>> >> > Log:
>> >> > Changes for [parent] 22-SNAPSHOT.
>> >> >
>> >> > Modified:
>> >> >    commons/proper/lang/trunk/src/test/resources/java.policy
>> >> >
>> >> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
>> >> > URL:
>> >>
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
>> >> >
>> >>
>> ==
>> >> > --- commons/proper/lang/trunk/src/test/resources/java.policy
>> (original)
>> >> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep
>>  6
>> >> 12:46:39 2011
>> >> > @@ -194,6 +194,7 @@ grant {
>> >> >  //            at
>> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >> >
>> >> >   permission java.io.FilePermission
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
>> >> "read";
>> >> > +  permission java.io.FilePermission
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
>> >> "read";
>> >>
>> >> That won't work for me - I use a customised repo directory. Also it's
>> >> a pain to keep changing the jar versions.
>> >> Probably won't work for some IDEs either, and may not work on CIs such
>> >> as Gump and Continuum.
>> >>
>> >> Is there any way to give the test classes normal permissions, and just
>> >> restrict the classes under test?
>> >>
>> >
>> > Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported
>> IIRC.
>>
>> Surely this is a JAAS issue?
>>
>
> This is about configuring JAAS, which surefire does for JUnit 3 but not 4
> (based on what I read).

I thought it was controlled by setting properties for the JVM, i.e.
nothing to do with Surefire (except it has to pass the parameters to
the forked JVM).

> Gary
>
>
>>
>> > Gary
>> >
>> >
>> >>
>> >> >
>> >> >  //    java.security.AccessControlException: access denied
>> >> (java.io.FilePermission
>> >>
>> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
>> >> read)
>> >> > @@ -212,6 +213,7 @@ grant {
>> >> >  //at
>> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >> >
>> >> >   permission java.io.FilePermission
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
>> >> "read";
>> >> > +  permission java.io.FilePermission
>> >>
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
>> >> "read";
>> >> >
>> >> >
>> >> >  //    java.security.AccessControlException: access denied
>> >> (java.lang.RuntimePermission createClassLoader)
>> >> >
>> >> >
>> >> >
>> >>
>> >> -
>> >> 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://s.apache.org/rl
>> > Spring Batch in Action: http://s.apache.org/HOq
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>> >
>>
>> -
>> 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://s.apache.org/rl
> Spring Batch in Action: http://s.apache.org/HOq
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

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

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[Gary Gregory]

On Tue, Sep 6, 2011 at 11:14 AM, sebb  wrote:

> On 6 September 2011 15:44, Gary Gregory  wrote:
> > On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
> >
> >> On 6 September 2011 13:46,   wrote:
> >> > Author: ggregory
> >> > Date: Tue Sep  6 12:46:39 2011
> >> > New Revision: 1165645
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> >> > Log:
> >> > Changes for [parent] 22-SNAPSHOT.
> >> >
> >> > Modified:
> >> >commons/proper/lang/trunk/src/test/resources/java.policy
> >> >
> >> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
> >> > URL:
> >>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
> >> >
> >>
> ==
> >> > --- commons/proper/lang/trunk/src/test/resources/java.policy
> (original)
> >> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep
>  6
> >> 12:46:39 2011
> >> > @@ -194,6 +194,7 @@ grant {
> >> >  //at
> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >
> >> >   permission java.io.FilePermission
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
> >> "read";
> >> > +  permission java.io.FilePermission
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
> >> "read";
> >>
> >> That won't work for me - I use a customised repo directory. Also it's
> >> a pain to keep changing the jar versions.
> >> Probably won't work for some IDEs either, and may not work on CIs such
> >> as Gump and Continuum.
> >>
> >> Is there any way to give the test classes normal permissions, and just
> >> restrict the classes under test?
> >>
> >
> > Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported
> IIRC.
>
> Surely this is a JAAS issue?
>

This is about configuring JAAS, which surefire does for JUnit 3 but not 4
(based on what I read).

Gary


>
> > Gary
> >
> >
> >>
> >> >
> >> >  //java.security.AccessControlException: access denied
> >> (java.io.FilePermission
> >>
> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
> >> read)
> >> > @@ -212,6 +213,7 @@ grant {
> >> >  //at
> >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >> >
> >> >   permission java.io.FilePermission
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
> >> "read";
> >> > +  permission java.io.FilePermission
> >>
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
> >> "read";
> >> >
> >> >
> >> >  //java.security.AccessControlException: access denied
> >> (java.lang.RuntimePermission createClassLoader)
> >> >
> >> >
> >> >
> >>
> >> -
> >> 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://s.apache.org/rl
> > Spring Batch in Action: http://s.apache.org/HOq
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
> -
> 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://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1165395 - /commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java

[Simone Tripodi]

I am an idiot and I don't have to commit while watching TV :)
Thanks for notifying, going to fix it now!
All the best,
Simo

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



On Tue, Sep 6, 2011 at 6:01 PM, Matt Benson  wrote:
> @since 3.0?  Should this be 2.0?  :)  Same for previous commit to this...
>
> Matt
>
> On Mon, Sep 5, 2011 at 2:07 PM,   wrote:
>> Author: simonetripodi
>> Date: Mon Sep  5 19:07:51 2011
>> New Revision: 1165395
>>
>> URL: http://svn.apache.org/viewvc?rev=1165395&view=rev
>> Log:
>> added missing @since tag in isFrozen() method javadoc
>>
>> Modified:
>>    
>> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>>
>> Modified: 
>> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java?rev=1165395&r1=1165394&r2=1165395&view=diff
>> ==
>> --- 
>> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>>  (original)
>> +++ 
>> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>>  Mon Sep  5 19:07:51 2011
>> @@ -234,6 +234,7 @@ public class ChainBase>      * @return true, if the configuration of our commands list
>>      * has been frozen by a call to the execute() method,
>>      * false otherwise.
>> +     * @since 3.0
>>      */
>>     public boolean isFrozen() {
>>         return frozen;
>>
>>
>>
>
> -
> 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: svn commit: r1165395 - /commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java

[Matt Benson]

@since 3.0?  Should this be 2.0?  :)  Same for previous commit to this...

Matt

On Mon, Sep 5, 2011 at 2:07 PM,   wrote:
> Author: simonetripodi
> Date: Mon Sep  5 19:07:51 2011
> New Revision: 1165395
>
> URL: http://svn.apache.org/viewvc?rev=1165395&view=rev
> Log:
> added missing @since tag in isFrozen() method javadoc
>
> Modified:
>    
> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>
> Modified: 
> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java?rev=1165395&r1=1165394&r2=1165395&view=diff
> ==
> --- 
> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>  (original)
> +++ 
> commons/proper/chain/branches/version-2.0-work/src/main/java/org/apache/commons/chain/impl/ChainBase.java
>  Mon Sep  5 19:07:51 2011
> @@ -234,6 +234,7 @@ public class ChainBase      * @return true, if the configuration of our commands list
>      * has been frozen by a call to the execute() method,
>      * false otherwise.
> +     * @since 3.0
>      */
>     public boolean isFrozen() {
>         return frozen;
>
>
>

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

Re: [math] EmpiricalDistribution

[Mikkel Meyer Andersen]

2011/9/6 Phil Steitz :
> On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
>> 2011/9/5 Phil Steitz :
>>> I have a couple of proposals for this class:
>>>
>>> 0) Merge the interface and impl.   This is consistent with what we
>>> are doing in some other places where we have only one implementation.
>> Fine with me.
>>> 1) Extend this class to actually provide a distribution - i.e.
>>> implement the Distribution interface.
>> Won't we have problems, e.g. with implementing cumulativeProbability?
>
> The idea I had was to interpolate within bins.  So to compute the
> cdf at x you would find its bin, sum the mass (based on number of
> original sample points contained, like the sampling does) of the
> bins below its containing bin and then use the defined kernel within
> bin to determine how much of its own bin's mass to include.
Seems reasonable. But: We might want to include a user specified
support - just simple (endpoints of an interval) - or else the highest
and lowest value specifies the support which might not be a good idea.
>
>>> 2) make the kernel used within bins configurable.  Currently, values
>>> are generated (and the cdf would be computed) assuming a Gaussian
>>> distribution within bins.  I think at least a uniform option should
>>> be provided.
>> +1, maybe it can be generalised to providing user-defined kernels.
>
> Good idea.  Need to think about how to enable that.
>
> Thanks!
>
> Phil
>>> Thanks in advance for any feedback on this or further suggestions
>>> for improvement.
>>>
>>> Phil
>>>
Cheers, Mikkel.

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

Re: [MATH-653] Closing MATH-653?

[Ted Dunning]

I doubt there is a policy, but practically speaking it helps a lot if JIRA's
don't live forever.  They should express an issue and that should get fixed
and the JIRA closed.  The scope of work shouldn't be extended to cover
additional work.

Tasks under blanket JIRA's might help.

2011/9/6 Sébastien Brisard 

> On a more general level, what's the policy in terms of closing a JIRA
> ticket. I've looked on the website but could not find guidance. Who
> takes the decision, on what grounds (question on the ML?). Also, when
> opening a new ticket, should it be assigned to someone, if this person
> agrees to take care of it?
>

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[sebb]

On 6 September 2011 15:44, Gary Gregory  wrote:
> On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:
>
>> On 6 September 2011 13:46,   wrote:
>> > Author: ggregory
>> > Date: Tue Sep  6 12:46:39 2011
>> > New Revision: 1165645
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
>> > Log:
>> > Changes for [parent] 22-SNAPSHOT.
>> >
>> > Modified:
>> >    commons/proper/lang/trunk/src/test/resources/java.policy
>> >
>> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
>> >
>> ==
>> > --- commons/proper/lang/trunk/src/test/resources/java.policy (original)
>> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep  6
>> 12:46:39 2011
>> > @@ -194,6 +194,7 @@ grant {
>> >  //            at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >
>> >   permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
>> "read";
>> > +  permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
>> "read";
>>
>> That won't work for me - I use a customised repo directory. Also it's
>> a pain to keep changing the jar versions.
>> Probably won't work for some IDEs either, and may not work on CIs such
>> as Gump and Continuum.
>>
>> Is there any way to give the test classes normal permissions, and just
>> restrict the classes under test?
>>
>
> Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported IIRC.

Surely this is a JAAS issue?

> Gary
>
>
>>
>> >
>> >  //    java.security.AccessControlException: access denied
>> (java.io.FilePermission
>> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
>> read)
>> > @@ -212,6 +213,7 @@ grant {
>> >  //at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> >
>> >   permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
>> "read";
>> > +  permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
>> "read";
>> >
>> >
>> >  //    java.security.AccessControlException: access denied
>> (java.lang.RuntimePermission createClassLoader)
>> >
>> >
>> >
>>
>> -
>> 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://s.apache.org/rl
> Spring Batch in Action: http://s.apache.org/HOq
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

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

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[Gary Gregory]

On Tue, Sep 6, 2011 at 9:48 AM, sebb  wrote:

> On 6 September 2011 13:46,   wrote:
> > Author: ggregory
> > Date: Tue Sep  6 12:46:39 2011
> > New Revision: 1165645
> >
> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> > Log:
> > Changes for [parent] 22-SNAPSHOT.
> >
> > Modified:
> >commons/proper/lang/trunk/src/test/resources/java.policy
> >
> > Modified: commons/proper/lang/trunk/src/test/resources/java.policy
> > URL:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
> >
> ==
> > --- commons/proper/lang/trunk/src/test/resources/java.policy (original)
> > +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep  6
> 12:46:39 2011
> > @@ -194,6 +194,7 @@ grant {
> >  //at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >
> >   permission java.io.FilePermission
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
> "read";
> > +  permission java.io.FilePermission
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
> "read";
>
> That won't work for me - I use a customised repo directory. Also it's
> a pain to keep changing the jar versions.
> Probably won't work for some IDEs either, and may not work on CIs such
> as Gump and Continuum.
>
> Is there any way to give the test classes normal permissions, and just
> restrict the classes under test?
>

Yes, only if you use Surefire with JUnit 3. JUnit 4 is not supported IIRC.

Gary


>
> >
> >  //java.security.AccessControlException: access denied
> (java.io.FilePermission
> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
> read)
> > @@ -212,6 +213,7 @@ grant {
> >  //at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> >
> >   permission java.io.FilePermission
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
> "read";
> > +  permission java.io.FilePermission
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
> "read";
> >
> >
> >  //java.security.AccessControlException: access denied
> (java.lang.RuntimePermission createClassLoader)
> >
> >
> >
>
> -
> 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://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] Running lang under a security manager and LANG-744

[sebb]

I'm working on a fix now. Have a look when it is committed to see if
it can be improved.

On 6 September 2011 15:48, Paul Benedict  wrote:
> Make the sun class be loaded dynamically -- not statically -- and if
> it is not present, just throw an UnsupportedOperationException? I
> think that would solve Android's problem.
>
> On Tue, Sep 6, 2011 at 8:36 AM, sebb  wrote:
>> On 6 September 2011 05:44, David Karlsen  wrote:
>>> I think tying to sun classes is a bad idea.
>>
>> Yes, which is why the code checks to see if the class is present.
>>
>> If the Java 6 method is available, then it uses that, otherwise it
>> checks for the Sun method.
>> If neither is available, then the code throws an
>> UnsupportedOperationException in the stripAccents() method.
>>
>>> Den 6. sep. 2011 05:54 skrev "sebb"  følgende:
 On 6 September 2011 04:33, Henri Yandell  wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb  wrote:
>> On 3 September 2011 05:37, Henri Yandell  wrote:
>>> I'm less concerned with the 115 errors, unless they're all as grievous
>>> as the StringUtils one - ie) the method causing trouble is not the
>>> only one broken.
>>>
>>> If the error happened when calling stripAccents, that would be
>>> workable; but having all of StringUtils unavailable is very painful.
>>> One option would be to move the code out of the static initializer and
>>> make it lazy when stripAccents is first called - leading to only
>>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>>> pain.
>>
>> I thought we'd already fixed that by catching the extra Exception?
>>
>> I already suggested localising the error display to the stripAccents
>>> method.
>
> Sorry - not operating at 100% last week.
>
>>> I thought we could simplify things by simply making the java6Available
>>> flag be a real test for Java 6, but Android seems very weird there. Is
>>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>>> compatible? IIUC it reports itself as 0.9, which we've declared as
>>> equivalent to JDK 1.5.
>>
>> Are you sure that is the issue?
>> Surely the Android problem is that we check for the sun class but
>> don't handle all possible errors?
>> So the class does not load; it cannot use the Java6 method even if it
>>> exists.
>
> I'm very confused between Android and GAE :)
>
>>> That relates to another (simple) solution - move to Java 6 :)
>>
>> Or capture Exception for both the java6 and sun tests; report the
>> exception(s) if neither is available when required.
>
> I like this. Capture the exception in the static initializer and then
> throw a new runtime exception in stripAccents that refers to said
> exception. Perhaps an IllegalStateException("blah", originalException)
> ?

 It currently throws UnsupportedOperationException; I think we should
 keep that as it's more accurate.

 There will always be two Exceptions at that point (otherwise we must
 have Java 6 or Sun).
 We know we need to report the Sun Exception - is there any need to
 report the Java 6 exception?
 i.e. could we be running on Java 6 but still get an Exception?

 For completeness (and debugging) we should probably report both.

 Perhaps we could nest the exceptions.

> Hen
>
> -
> 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: [chain][v2] clever context

[Elijah Zupancic]

As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity object. With regards to extending Map, the nice
thing about it is that you can digest the contents of other contexts
easily. I can just take another context with a different signature and
do a .putAll and now I have all of its properties auto-magically -
even if not all of the getters / setters are present. This actually
saves time in projects - especially when dealing with large entity
(Context) objects with a lot of overlapping properties.

I'm all for having a asMap() method that externalizes map from the
Context implementation as long as we keep the ability to consume other
Contexts as a data source for population.

Thanks,
-Elijah

@Niall, sorry this isn't really a reply to what you wrote. I just
wanted to jump on the thread somewhere.

On Mon, Sep 5, 2011 at 5:19 PM, Niall Pemberton
 wrote:
> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>  wrote:
>> I agree with Paul here.  Extending Map (or any other class for that
>> matter) when what you really want to do is encapsulate it is silly.
>> Is the Context really meant to be used in any place where a Map can be
>> used?  I would think not.
>
> I always thought the other way. I never understood why context wasn't
> just a Map, rather than a new Chain specific type extending Map.
>
> Using Map has its advantages. Firstly the contract it provides besides
> get/put are useful operations on the context (containsKey(), size(),
> entrySet() etc.etc) , secondly (if it was a "plain" Map) there are
> standard implementations & wrappers that can be used giving features
> such as concurrency, ready-only etc. and thirdly tools & libraries
> understand how to operate on a Map.
>
> Niall
>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict  wrote:
>>> I want to get rid of it extending map. Have it define as asMap()
>>> function instead. Especially since JDK 8 is bringing in extension
>>> methods, which adds new (and default) methods to all collections, it
>>> won't look very nice. Let's make a break now.
>>>
>>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta  wrote:
 On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi  
> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not 
> "auto-cast."  :)

 Thanks for the explanation... I see now that via the generic method
 the compiler infers the return type from the assignment type.

 Cheers,
 Raman

 -
 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: [lang] Running lang under a security manager and LANG-744

[Paul Benedict]

Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.

On Tue, Sep 6, 2011 at 8:36 AM, sebb  wrote:
> On 6 September 2011 05:44, David Karlsen  wrote:
>> I think tying to sun classes is a bad idea.
>
> Yes, which is why the code checks to see if the class is present.
>
> If the Java 6 method is available, then it uses that, otherwise it
> checks for the Sun method.
> If neither is available, then the code throws an
> UnsupportedOperationException in the stripAccents() method.
>
>> Den 6. sep. 2011 05:54 skrev "sebb"  følgende:
>>> On 6 September 2011 04:33, Henri Yandell  wrote:
 On Sat, Sep 3, 2011 at 8:10 AM, sebb  wrote:
> On 3 September 2011 05:37, Henri Yandell  wrote:
>> I'm less concerned with the 115 errors, unless they're all as grievous
>> as the StringUtils one - ie) the method causing trouble is not the
>> only one broken.
>>
>> If the error happened when calling stripAccents, that would be
>> workable; but having all of StringUtils unavailable is very painful.
>> One option would be to move the code out of the static initializer and
>> make it lazy when stripAccents is first called - leading to only
>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>> pain.
>
> I thought we'd already fixed that by catching the extra Exception?
>
> I already suggested localising the error display to the stripAccents
>> method.

 Sorry - not operating at 100% last week.

>> I thought we could simplify things by simply making the java6Available
>> flag be a real test for Java 6, but Android seems very weird there. Is
>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>> compatible? IIUC it reports itself as 0.9, which we've declared as
>> equivalent to JDK 1.5.
>
> Are you sure that is the issue?
> Surely the Android problem is that we check for the sun class but
> don't handle all possible errors?
> So the class does not load; it cannot use the Java6 method even if it
>> exists.

 I'm very confused between Android and GAE :)

>> That relates to another (simple) solution - move to Java 6 :)
>
> Or capture Exception for both the java6 and sun tests; report the
> exception(s) if neither is available when required.

 I like this. Capture the exception in the static initializer and then
 throw a new runtime exception in stripAccents that refers to said
 exception. Perhaps an IllegalStateException("blah", originalException)
 ?
>>>
>>> It currently throws UnsupportedOperationException; I think we should
>>> keep that as it's more accurate.
>>>
>>> There will always be two Exceptions at that point (otherwise we must
>>> have Java 6 or Sun).
>>> We know we need to report the Sun Exception - is there any need to
>>> report the Java 6 exception?
>>> i.e. could we be running on Java 6 but still get an Exception?
>>>
>>> For completeness (and debugging) we should probably report both.
>>>
>>> Perhaps we could nest the exceptions.
>>>
 Hen

 -
 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] Complex division WASRe [jira] [Commented] (MATH-657) Division by zero

[Arne Ploese]

I added the file ComplexOctaveTest.java to JIRA MATH-620.

What really will happen, if Inf and NaN values com up I dont know at
this point - the complex signal path is in its infancy at the moment ...
(I currently have no need for that)

Arne


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

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[Jörg Schaible]

We use in XStream a dynamic approach:
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/xstream/testutil/DynamicSecurityManager.java
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/acceptance/SecurityManagerTest.java

sebb wrote:

> On 6 September 2011 13:46,   wrote:
>> Author: ggregory
>> Date: Tue Sep  6 12:46:39 2011
>> New Revision: 1165645
>>
>> URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
>> Log:
>> Changes for [parent] 22-SNAPSHOT.
>>
>> Modified:
>> commons/proper/lang/trunk/src/test/resources/java.policy
>>
>> Modified: commons/proper/lang/trunk/src/test/resources/java.policy
>> URL:
>> 
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
>> 
==
>> --- commons/proper/lang/trunk/src/test/resources/java.policy (original)
>> +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep  6
>> 12:46:39 2011 @@ -194,6 +194,7 @@ grant { //at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>>
>> permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-
junit4/2.8.1/surefire-junit4-2.8.1.jar",
>> "read"; +  permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-
junit4/2.9/surefire-junit4-2.9.jar",
>> "read";
> 
> That won't work for me - I use a customised repo directory. Also it's
> a pain to keep changing the jar versions.
> Probably won't work for some IDEs either, and may not work on CIs such
> as Gump and Continuum.
> 
> Is there any way to give the test classes normal permissions, and just
> restrict the classes under test?
> 
>>
>> //java.security.AccessControlException: access denied
>> (java.io.FilePermission
>> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-
api\2.8.1\surefire-api-2.8.1.jar
>> read) @@ -212,6 +213,7 @@ grant { //at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>>
>> permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-
api/2.8.1/surefire-api-2.8.1.jar",
>> "read"; +  permission java.io.FilePermission
>> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-
api/2.9/surefire-api-2.9.jar",
>> "read";
>>
>>
>> //java.security.AccessControlException: access denied
>> (java.lang.RuntimePermission createClassLoader)
>>
>>
>>



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

Re: svn commit: r1165645 - /commons/proper/lang/trunk/src/test/resources/java.policy

[sebb]

On 6 September 2011 13:46,   wrote:
> Author: ggregory
> Date: Tue Sep  6 12:46:39 2011
> New Revision: 1165645
>
> URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> Log:
> Changes for [parent] 22-SNAPSHOT.
>
> Modified:
>    commons/proper/lang/trunk/src/test/resources/java.policy
>
> Modified: commons/proper/lang/trunk/src/test/resources/java.policy
> URL: 
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/resources/java.policy?rev=1165645&r1=1165644&r2=1165645&view=diff
> ==
> --- commons/proper/lang/trunk/src/test/resources/java.policy (original)
> +++ commons/proper/lang/trunk/src/test/resources/java.policy Tue Sep  6 
> 12:46:39 2011
> @@ -194,6 +194,7 @@ grant {
>  //            at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>
>   permission java.io.FilePermission 
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.8.1/surefire-junit4-2.8.1.jar",
>  "read";
> +  permission java.io.FilePermission 
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-junit4/2.9/surefire-junit4-2.9.jar",
>  "read";

That won't work for me - I use a customised repo directory. Also it's
a pain to keep changing the jar versions.
Probably won't work for some IDEs either, and may not work on CIs such
as Gump and Continuum.

Is there any way to give the test classes normal permissions, and just
restrict the classes under test?

>
>  //    java.security.AccessControlException: access denied 
> (java.io.FilePermission 
> C:\Users\ggregory\.m2\repository\org\apache\maven\surefire\surefire-api\2.8.1\surefire-api-2.8.1.jar
>  read)
> @@ -212,6 +213,7 @@ grant {
>  //at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>
>   permission java.io.FilePermission 
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.8.1/surefire-api-2.8.1.jar",
>  "read";
> +  permission java.io.FilePermission 
> "${user.home}/.m2/repository/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar",
>  "read";
>
>
>  //    java.security.AccessControlException: access denied 
> (java.lang.RuntimePermission createClassLoader)
>
>
>

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

Re: [lang] Running lang under a security manager and LANG-744

[sebb]

On 6 September 2011 05:44, David Karlsen  wrote:
> I think tying to sun classes is a bad idea.

Yes, which is why the code checks to see if the class is present.

If the Java 6 method is available, then it uses that, otherwise it
checks for the Sun method.
If neither is available, then the code throws an
UnsupportedOperationException in the stripAccents() method.

> Den 6. sep. 2011 05:54 skrev "sebb"  følgende:
>> On 6 September 2011 04:33, Henri Yandell  wrote:
>>> On Sat, Sep 3, 2011 at 8:10 AM, sebb  wrote:
 On 3 September 2011 05:37, Henri Yandell  wrote:
> I'm less concerned with the 115 errors, unless they're all as grievous
> as the StringUtils one - ie) the method causing trouble is not the
> only one broken.
>
> If the error happened when calling stripAccents, that would be
> workable; but having all of StringUtils unavailable is very painful.
> One option would be to move the code out of the static initializer and
> make it lazy when stripAccents is first called - leading to only
> callers of stripAccents when the JDK 6 class is unavailable to suffer
> pain.

 I thought we'd already fixed that by catching the extra Exception?

 I already suggested localising the error display to the stripAccents
> method.
>>>
>>> Sorry - not operating at 100% last week.
>>>
> I thought we could simplify things by simply making the java6Available
> flag be a real test for Java 6, but Android seems very weird there. Is
> Android going to force us to stay on the EOL Java 5, or is it Java 6
> compatible? IIUC it reports itself as 0.9, which we've declared as
> equivalent to JDK 1.5.

 Are you sure that is the issue?
 Surely the Android problem is that we check for the sun class but
 don't handle all possible errors?
 So the class does not load; it cannot use the Java6 method even if it
> exists.
>>>
>>> I'm very confused between Android and GAE :)
>>>
> That relates to another (simple) solution - move to Java 6 :)

 Or capture Exception for both the java6 and sun tests; report the
 exception(s) if neither is available when required.
>>>
>>> I like this. Capture the exception in the static initializer and then
>>> throw a new runtime exception in stripAccents that refers to said
>>> exception. Perhaps an IllegalStateException("blah", originalException)
>>> ?
>>
>> It currently throws UnsupportedOperationException; I think we should
>> keep that as it's more accurate.
>>
>> There will always be two Exceptions at that point (otherwise we must
>> have Java 6 or Sun).
>> We know we need to report the Sun Exception - is there any need to
>> report the Java 6 exception?
>> i.e. could we be running on Java 6 but still get an Exception?
>>
>> For completeness (and debugging) we should probably report both.
>>
>> Perhaps we could nest the exceptions.
>>
>>> Hen
>>>
>>> -
>>> 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] EmpiricalDistribution

[Phil Steitz]

On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
> 2011/9/5 Phil Steitz :
>> I have a couple of proposals for this class:
>>
>> 0) Merge the interface and impl.   This is consistent with what we
>> are doing in some other places where we have only one implementation.
> Fine with me.
>> 1) Extend this class to actually provide a distribution - i.e.
>> implement the Distribution interface.
> Won't we have problems, e.g. with implementing cumulativeProbability?

The idea I had was to interpolate within bins.  So to compute the
cdf at x you would find its bin, sum the mass (based on number of
original sample points contained, like the sampling does) of the
bins below its containing bin and then use the defined kernel within
bin to determine how much of its own bin's mass to include.

>> 2) make the kernel used within bins configurable.  Currently, values
>> are generated (and the cdf would be computed) assuming a Gaussian
>> distribution within bins.  I think at least a uniform option should
>> be provided.
> +1, maybe it can be generalised to providing user-defined kernels.

Good idea.  Need to think about how to enable that.

Thanks!

Phil
>> Thanks in advance for any feedback on this or further suggestions
>> for improvement.
>>
>> 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

Re: [MATH-653] Closing MATH-653?

[Gilles Sadowski]

Hello.

> as agreed in this ticket, references to double[] solve(double[]) have
> been wiped out from all decomposition solvers.

That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on "RealVector".

> The same thing should probably be done with solve(double[][]),

You could create a ticket for this already, to keep track of the tasks
that must be performed.

> Gilles suggested we should probably wait and see what is going to
> happen to the RealMatrix interface (creating views and all that) ===>
> has a consensus been arrived at on this issue? This is a very exciting
> topic, but I got the feeling that it meant: start again from zero.

The discussion seems to have quiet down; so starting the refactoring with
the removal of methods with primitive array argument is fine too, I think...

> 
> I haven't proceeded yet to clean FieldDecompositionSolver in the same
> spirit. Should it be done?

That would seem logical.
But, let's wait for a confirmation.

> On a more general level, what's the policy in terms of closing a JIRA
> ticket. I've looked on the website but could not find guidance. Who
> takes the decision, on what grounds (question on the ML?).

If you mean "Close", I think that this is done only just before a release.

If you mean "Resolve", I guess that you can do it when the changes described
in the issue have been applied. If some additional changes (not formally
agreed on) were needed in the patch, I'd (usually) request agreement by
adding a comment to that effect, and if no objection is raised within a few
days, I'd set the issue as resolved.  One can always reopen it afterwards if
necessary.

> Also, when
> opening a new ticket, should it be assigned to someone, if this person
> agrees to take care of it?

If you are willing to fix some issue, you should probably assign it to
yourself. That would help prevent duplicate work.


Best,
Gilles

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

[math] Closing MATH-653?

[Sébastien Brisard]

Not sure it went through the first time...

Le 6 septembre 2011 08:33, Sébastien Brisard
 a écrit :
> Hi,
> as agreed in this ticket, references to double[] solve(double[]) have
> been wiped out from all decomposition solvers.
> The same thing should probably be done with solve(double[][]), but
> Gilles suggested we should probably wait and see what is going to
> happen to the RealMatrix interface (creating views and all that) ===>
> has a consensus been arrived at on this issue? This is a very exciting
> topic, but I got the feeling that it meant: start again from zero.
>
> I haven't proceeded yet to clean FieldDecompositionSolver in the same
> spirit. Should it be done?
>
> On a more general level, what's the policy in terms of closing a JIRA
> ticket. I've looked on the website but could not find guidance. Who
> takes the decision, on what grounds (question on the ML?). Also, when
> opening a new ticket, should it be assigned to someone, if this person
> agrees to take care of it?
>
> Best regards for now,
> Sébastien
>

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

Re: [lang] Running lang under a security manager and LANG-744

[Gary Gregory]

On Sep 5, 2011, at 23:34, Henri Yandell  wrote:

> On Sat, Sep 3, 2011 at 8:10 AM, sebb  wrote:
>> On 3 September 2011 05:37, Henri Yandell  wrote:
>>> I'm less concerned with the 115 errors, unless they're all as grievous
>>> as the StringUtils one - ie) the method causing trouble is not the
>>> only one broken.
>>>
>>> If the error happened when calling stripAccents, that would be
>>> workable; but having all of StringUtils unavailable is very painful.
>>> One option would be to move the code out of the static initializer and
>>> make it lazy when stripAccents is first called - leading to only
>>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>>> pain.
>>
>> I thought we'd already fixed that by catching the extra Exception?
>>
>> I already suggested localising the error display to the stripAccents method.
>
> Sorry - not operating at 100% last week.
>
>>> I thought we could simplify things by simply making the java6Available
>>> flag be a real test for Java 6, but Android seems very weird there. Is
>>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>>> compatible? IIUC it reports itself as 0.9, which we've declared as
>>> equivalent to JDK 1.5.
>>
>> Are you sure that is the issue?
>> Surely the Android problem is that we check for the sun class but
>> don't handle all possible errors?
>> So the class does not load; it cannot use the Java6 method even if it exists.
>
> I'm very confused between Android and GAE :)
>
>>> That relates to another (simple) solution - move to Java 6 :)
>>
>> Or capture Exception for both the java6 and sun tests; report the
>> exception(s) if neither is available when required.
>
> I like this. Capture the exception in the static initializer and then
> throw a new runtime exception in stripAccents that refers to said
> exception. Perhaps an IllegalStateException("blah", originalException)
> ?

Sounds less painful than the current code. Give it a try.

Gary

>
> Hen
>
> -
> 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: svn commit: r1165490 - /commons/proper/io/trunk/pom.xml

[Gary Gregory]

On Sep 5, 2011, at 23:35, sebb  wrote:

> On 6 September 2011 04:26, Gary Gregory  wrote:
>> Can the clirr version be inherited from the parent pom?
>
> Tried that just now.
>
> Has to be defined in reporting section.
>
> That works fine, except it does not appear to be possible to suppress
> the report in the component pom - skip does not seem to work for mvn
> site.
> Though one can override other Clirr parameters.
>
> We could only add clirr to parent if every component had a Clirr
> report; that may be acceptable.

I for one would welcome more consistency between components in this Dept.

Gary

>
>> Could we set up the parent such that a component just specifies which 
>> version to compare against? In a property for example.
>
> AFAIK that already happens automatically; it only has to be overridden
> if the default previous version does not apply.
> Try removing the previous version definition and see what happens.
>
>> Gary
>>
>> On Sep 5, 2011, at 23:23, "s...@apache.org"  wrote:
>>
>>> Author: sebb
>>> Date: Tue Sep  6 03:22:59 2011
>>> New Revision: 1165490
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1165490&view=rev
>>> Log:
>>> Clirr 2.2.3 => 2.3
>>>
>>> Modified:
>>>commons/proper/io/trunk/pom.xml
>>>
>>> Modified: commons/proper/io/trunk/pom.xml
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/io/trunk/pom.xml?rev=1165490&r1=1165489&r2=1165490&view=diff
>>> ==
>>> --- commons/proper/io/trunk/pom.xml (original)
>>> +++ commons/proper/io/trunk/pom.xml Tue Sep  6 03:22:59 2011
>>> @@ -272,7 +272,7 @@
>>>   
>>> org.codehaus.mojo
>>> clirr-maven-plugin
>>> -2.2.3
>>> +2.3
>>> 
>>>   2.0
>>>   info
>>>
>>>
>>
>> -
>> 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

[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 82 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: 11 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
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.163 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

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

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Tue Sep 06 10:18:08 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

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

Re: [chain][v2] clever context

[Simone Tripodi]

Hi Niall,
thanks for the hint!

Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
so I couldn't say the truth) I immagine that users would be interested
on having, as a Context, not just a place where storing computed
element to be shared between chain commands, but having also the
possibility of customizations adding, for example, shared clever
methods - take a look at the concrete default
{{org.apache.commons.chain.impl.ContextBase}} implementation where
there is an index of PropertiesDescriptors.

Honestly thinking, after raw your message, I'd tend to agree that
Map would be more than enough - just for the record,
that's what we deed indeed in the Apache Cocoon3 Pipeline APIs - but
at the same time I like the idea of having dedicated Chain API as
shown in the current implementation.

Hard to take a decision...
Simo

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



On Tue, Sep 6, 2011 at 2:19 AM, Niall Pemberton
 wrote:
> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>  wrote:
>> I agree with Paul here.  Extending Map (or any other class for that
>> matter) when what you really want to do is encapsulate it is silly.
>> Is the Context really meant to be used in any place where a Map can be
>> used?  I would think not.
>
> I always thought the other way. I never understood why context wasn't
> just a Map, rather than a new Chain specific type extending Map.
>
> Using Map has its advantages. Firstly the contract it provides besides
> get/put are useful operations on the context (containsKey(), size(),
> entrySet() etc.etc) , secondly (if it was a "plain" Map) there are
> standard implementations & wrappers that can be used giving features
> such as concurrency, ready-only etc. and thirdly tools & libraries
> understand how to operate on a Map.
>
> Niall
>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict  wrote:
>>> I want to get rid of it extending map. Have it define as asMap()
>>> function instead. Especially since JDK 8 is bringing in extension
>>> methods, which adds new (and default) methods to all collections, it
>>> won't look very nice. Let's make a break now.
>>>
>>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta  wrote:
 On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi  
> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not 
> "auto-cast."  :)

 Thanks for the explanation... I see now that via the generic method
 the compiler infers the return type from the assignment type.

 Cheers,
 Raman

 -
 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] removing MathUserException

[Tanguy Yannick]

>As shown in this exemple the exception is really something local to
user code and there is a guarantee [math] will not mess with it. The
user >is safe.
>
>I would like to finish implementing this for ODE (i.e. simply commit
what I have already done), and to extend it to the rest of [math],
>>>completely removing MathUserException. I would also document this as
a general rule for [math] users (using the example above).

>What do you think ?

+1 : I think this is a good idea.

Regards,

Yannick

>Luc

-
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] EmpiricalDistribution

[Mikkel Meyer Andersen]

2011/9/5 Phil Steitz :
> I have a couple of proposals for this class:
>
> 0) Merge the interface and impl.   This is consistent with what we
> are doing in some other places where we have only one implementation.
Fine with me.
> 1) Extend this class to actually provide a distribution - i.e.
> implement the Distribution interface.
Won't we have problems, e.g. with implementing cumulativeProbability?
> 2) make the kernel used within bins configurable.  Currently, values
> are generated (and the cdf would be computed) assuming a Gaussian
> distribution within bins.  I think at least a uniform option should
> be provided.
+1, maybe it can be generalised to providing user-defined kernels.
>
> Thanks in advance for any feedback on this or further suggestions
> for improvement.
>
> 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