[MATH-653] Closing MATH-653?

[Sébastien Brisard]

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: [Math] Merging unique "...Impl" classes with their interface?

[Sébastien Brisard]

OK, I'm happy to do it.
Sébastien

2011/9/5 Gilles Sadowski :
> Hi Sébastien.
>
>> Gilles,
>> if you're going to do that soon, I'll stop removing methods
>> solve(double[]) from DecompositionSolvers (I've only done Cholesky so
>> far), so that our modifications do not conflict.
>
> If you want, you can do it.
> [A JIRA issue has yet to be opened, which you can do too.]
>
>
> Best regards,
> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Ralph Goers]

On Sep 5, 2011, at 7:41 PM, sebb wrote:

> On 5 September 2011 15:55, Ralph Goers  wrote:
>> If you are making changes that affect the site I'd appreciate you also 
>> testing vfs as it is a multi-module build.
> 
> What command do you use for checking the site?
> 

mvn site:stage-deploy -DstagingSiteURL=file:///Users/rgoers/vfssite

Ralph

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

[David Karlsen]

I think tying to sun classes is a bad idea.
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
>

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

[sebb]

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

Re: svn commit: r1165490 - /commons/proper/io/trunk/pom.xml

[sebb]

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.

> 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

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

[Henri Yandell]

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)
?

Hen

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

Can the clirr version be inherited from the parent pom?

Could we set up the parent such that a component just specifies which version 
to compare against? In a property for example. 

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

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

[Gary Gregory]

I am going to play with surefire executions and see how that goes.

Gary

On Sep 3, 2011, at 19:37, Mark Struberg  wrote:

> Create a test.jar as attached artifact. Then create a sub module where you 
> dependency:unpack this test-jar and run the tests in your new configuration. 
> This can also be done via the maven-invoker-plugin.
>
> LieGrue,
> strub
>
>
> - Original Message -
>> From: sebb 
>> To: Commons Developers List 
>> Cc:
>> Sent: Saturday, September 3, 2011 5:10 PM
>> Subject: Re: [lang] Running lang under a security manager and LANG-744
>>
>> 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.
>>
>>> 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.
>>
>>> 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.
>>
>> The static block would then always complete; only methods using the
>> optional code would be affected.
>>
>>> Hen
>>>
>>> On Thu, Sep 1, 2011 at 5:20 PM, Gary Gregory 
>> wrote:
 WRT LANG-744 "StringUtils throws
>> java.security.AccessControlException on
 Google App Engine"

 Well, I've ruminated, pondered and experimented.

 Running all unit tests with a security managers results in:

 Tests run: 2046, Failures: 2, Errors: 115, Skipped: 0

 Clearly, we need a good overall solution to avoid 117 new Jiras (an
 exaggeration I know.)

 I've created a JAAS policy file to grant just enough permissions to
>> run the
 unit tests in {{src/test/resource/java.policy}}

 The file contains instructions for using it with JAAS.

 What this shows is that we should either:

 # Run all unit tests a second time with JAAS enabled, or
 # Run all unit tests with JAAS enabled, always

 We should our solution as a pattern for other Commons component.

 Specifically for StringUtils, should we have a SunStringUtils? This
>> would
 let you know that you are depending on com.sun code.

 Thoughts?

 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory

>>>
>>> -
>>> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[sebb]

On 5 September 2011 15:55, Ralph Goers  wrote:
> If you are making changes that affect the site I'd appreciate you also 
> testing vfs as it is a multi-module build.

What command do you use for checking the site?

> Ralph
>
> On Sep 5, 2011, at 6:52 AM, sebb wrote:
>
>> 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.
>>
>>> 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
>>>         
>>>         
>>>           org.apache.maven.plugins
>>>           maven-gpg-plugin
>>> -1.3
>>> +1.4
>>>         
>>>         
>>>           org.apache.maven.plugins
>>> @@ -179,7 +179,7 @@
>>>         
>>>           org.apache.maven.plugins
>>>           maven-jar-plugin
>>> -2.3
>>> +2.3.2
>>>         
>>>         
>>>           org.apache.maven.plugins
>>> @@ -227,7 +227,7 @@
>>>         
>>>           org.apache.maven.plugins
>>>           maven-site-plugin
>>> -2.2
>>> +3.0
>>>         
>>>         
>>>           org.apache.maven.plugins
>>> @@ -259,8 +259,7 @@
>>>         
>>>           org.apache.felix
>>>           maven-bundle-plugin
>>> -
>>> -1.4.3
>>> +2.3.5
>>>           true
>>>         
>>>       
>>>
>>>
>>>
>>
>> -
>> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[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.

> 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 @@
         
 

Re: [chain][discuss] v2 upgrade - follow-up

[Niall Pemberton]

On Mon, Aug 29, 2011 at 9:31 PM, Matt Benson  wrote:
> On Mon, Aug 29, 2011 at 2:53 PM, Simone Tripodi
>  wrote:
>> Hi all guys,
>> I just fixed the clirr report generation and deployed the chain2 site
>> on my personal ASF space[1], in order we can discuss the patch that
>> Elijah kindly provided.
>> WDYT? It is IMHO acceptable in order to apply the modifications in /trunk.
>
> Simo, thanks for taking the lead on this and, most importantly,
> getting the report published for perusal.  The report brought to my
> attention the change in the inheritance hierarchy of the ContextBase
> class, which seems really to present the largest available surface
> area for concern.  I have noted the only real consequence I see on the
> JIRA issue, but for my own personal interpretation of the situation I
> can agree that the minor assaults on backward compatibility don't
> really concern me, taken in context.  Do we have any active Commons
> committers who have developed, or even *used* [chain]?

Chain was born out of Struts 1.3 which wanted to move from a
monolithic RequestProcessor to something that could be composed of
Commands enabling people to customize the request processing of Struts
by adding/replacing their own commands in the request processing
chain. Struts 1.x still depends on Commons Chain and while there are
probably still quite a few Struts 1.x apps still in use, there hasn't
been a Struts 1.x release for a number of years. For anyone wondering
why there is a "web" element of Chain though, this is the reason. I
seriously doubt that there is much call from users for the web
elements outside of old Struts 1.x users. Perhaps if there is going to
be incompatible changes, then it should be radical, change the package
name and dump the web parts? I don't believe Struts 1.x would have any
need to upgrade.

Niall

> Matt
>
>> TIA, all the best!!!
>> Simo
>>
>> [1] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Aug 23, 2011 at 10:52 AM, Simone Tripodi
>>  wrote:
>>> Hi Matt,
>>> your suggestion makes indeed a lot of sense! I'll copy the /trunk to a
>>> branch and publish the site, once applied the patch, on my home@asf as
>>> soon as I have spare time today, so we can discuss together clirr
>>> report results.
>>> Many thanks for your hint, have a nice day!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Aug 22, 2011 at 4:46 PM, Matt Benson  wrote:
 I am generally in favor.  I think it could be good to apply his patch
 on a branch so we can discuss the clirr results and agree on the
 severity of the (IMHO forgivable) backward-compatibility breaches.
 Then we will understand the proper path forward with respect to
 versions and all the changes that cascade from the potential major
 version bump.

 Matt

 On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
  wrote:
> Hi all guys,
> Elijah, a [chain] user, has been submitting worthy contributions[1] to
> improve and actualize the commons-chains component, providing also
> patches[2].
> I think it is the good time to start speaking about the next [chain]
> version (no new releases/development in the last months), any
> objections on applying Elijah patch?
> I can take care of it but please let me know if anyone else want to do.
> Many thanks in advance, have a nice day!!!
> Simo
>
> [1] http://markmail.org/message/ajh3sunrst7x5klv
> [2] https://issues.apache.org/jira/browse/CHAIN-53
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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


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

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

Re: [IO] 2.1 release?

[Niall Pemberton]

I did mean to do this several months ago :( - but there were 2/3
Tailer bugs that I meant to have a look at. Anyway, on the basis of
"release (more-)often" then go for it - can always do a bug fix for
Tailer later.

Niall

On Wed, Aug 31, 2011 at 3:31 AM, Gary Gregory  wrote:
> Hi All:
>
> I'd like to use the new IOUtils.toString(URL|URI) APIs as well as others.
>
> Any thoughts as to when we want to push a release out?
>
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [chain][v2] clever context

[Niall Pemberton]

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

Re: Default threshold in "LUDecompositionImpl"

[Gilles Sadowski]

On Mon, Sep 05, 2011 at 02:35:42PM -0700, Phil Steitz wrote:
> On 9/5/11 2:23 PM, Gilles Sadowski wrote:
> > On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
> >> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
> >>> Hello.
> >> Hi Gilles,
> >>
> >>> There might be a typo in the value for the default singularity threshold
> >>> value in class "LUDecompositionImpl" (at line 37): Was
> >>>  10E-12
> >>> the intended value, or was it
> >>>  1e-12
> >>> ?
> >> It is probably a typo, but the exact value was certainly chosen
> >> almost arbitrarily. However, since it has now been published and
> >> changing it may break code, I would suggest to write it 1e-11.
> > Done in revision 1165416.
> 
> Should we maybe make the default public?

The fewer "public" things, the better. [As it becomes part of the API, and
thus ... (known story).]

I think that we should view those simplified constructors as "syntactic
sugar" for those users and situations for which the exact value does not
matter.
If the default is made public, it seems that there was a rationale behind
choosing the particular value. Which is not the case here, according to Luc.

There are some other occurences in CM where I already indicated my
preference for keeping "private" the variable holding the default value, for
the same reason.


Regards,
Gilles

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

Re: Default threshold in "LUDecompositionImpl"

[Phil Steitz]

On 9/5/11 2:23 PM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
>> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
>>> Hello.
>> Hi Gilles,
>>
>>> There might be a typo in the value for the default singularity threshold
>>> value in class "LUDecompositionImpl" (at line 37): Was
>>>  10E-12
>>> the intended value, or was it
>>>  1e-12
>>> ?
>> It is probably a typo, but the exact value was certainly chosen
>> almost arbitrarily. However, since it has now been published and
>> changing it may break code, I would suggest to write it 1e-11.
> Done in revision 1165416.

Should we maybe make the default public?

Phil
>
> 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: Default threshold in "LUDecompositionImpl"

[Gilles Sadowski]

On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
> >Hello.
> 
> Hi Gilles,
> 
> >
> >There might be a typo in the value for the default singularity threshold
> >value in class "LUDecompositionImpl" (at line 37): Was
> >  10E-12
> >the intended value, or was it
> >  1e-12
> >?
> 
> It is probably a typo, but the exact value was certainly chosen
> almost arbitrarily. However, since it has now been published and
> changing it may break code, I would suggest to write it 1e-11.

Done in revision 1165416.

Gilles

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

RE: [math] removing MathUserException

[Hendriks, D.]

> What do you think ?

Sounds good Luc!

Best regards,
Dennis


Van: Luc Maisonobe [luc.maison...@free.fr]
Verzonden: maandag 5 september 2011 21:47
Aan: Commons Developers List
Onderwerp: [math] removing MathUserException

Hello,

Cleaning out the ode package, I have seen that we throw ourselves a
MathUserException when the max number of allowed evaluations was
exceeded. I have fixed that in my local copy (not committed yet) and
used the opportunity to replace the ad hoc code by the new Incrementor
class, which purpose is precisely to count things and throw a dedicated
exception (MaxCountExceededException) if needed. This also allowed to
remove the last use of MaxEvaluationExceededException and hence the
exception itself (which was still in the top level package).

As I wrote a few hours ago answering a question from Dennis, we can now
get completely rid of MathUserException in the ode package. I have also
done that and checked everything worked well. The idea behind this was
discussed some months ago if I remember well. It was simply that users
should better use their own unchecked exception, so they can be sure
[math] will never catch them, when they call [math] code which itself
call their functions back (like in ODE, root solvers, optimization ...).
The current behavior with MathUserException was not really clean since
we did throw it by ourselves (at least in ODE, which I removed). As an
example, some clean user code should be:

public class Myclass implements FirstOrderDifferentialEquation {
   private static class LocalException extends RuntimeException {
 public LocalException(int a, int b, int c) {
// store some information about a, b, c
 }

 // some getters go here

   }

   public void solveODE() {
  try {
  integrator.integrate(this, t0, y0, t, y);
  } catch (LocalException le) {
 // retrieve the a, b and c values
  }

   }

   public int getDimension() {
 return 3;
   }

   public void computeDerivatives(double t, double[] y, double[] yDot) {

  // compute things

  if (somethingBadHappens) {
throw new LocalException(a, b, c);
   }

}

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

[Gilles Sadowski]

> [...]
> 
> What do you think ?

+1
[Of course.]


Gilles

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

[math] EmpiricalDistribution

[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.
1) Extend this class to actually provide a distribution - i.e.
implement the Distribution interface. 
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.

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

Re: [VOTE] Release Commons Configuration 1.7 based on RC3

[sebb]

On 5 September 2011 19:33, Gary Gregory  wrote:
> On Mon, Sep 5, 2011 at 2:05 PM, sebb  wrote:
>
>> On 5 September 2011 18:27, Gary Gregory  wrote:
>> > Or maybe we should push this one out and then update everything in
>> trunk...
>> >
>> > So +1 from me with a note that src/site/xdoc/style/project.css should
>> have a
>> > license header for completness' sake for the next go around (it's a one
>> > liner file I know ;)
>>
>> It's not necessary to add an AL header to such a short file.
>>
>
> But it's nice to be consistent and not have to consider this file as a
> special case because the line count is less than X when evaluating a RAT
> report. ;)

Yes, I filed an enhancement request for RAT to ignore one-line files.

As a work-round you could exclude the css file from the RAT report.

> At what line count do we need a license header?

When there is enough to be copyrightable.

http://www.apache.org/legal/src-headers.html#faq-exceptions

> Gary
>
>
>>
>> > Gary
>> >
>> > On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory 
>> wrote:
>> >
>> >> I'm all for updating to the latest and greatest of all components.
>> >>
>> >> Gary
>> >>
>> >> On Sep 4, 2011, at 15:41, Oliver Heger 
>> >> wrote:
>> >>
>> >> > This is a vote to release Apache Commons Configuration 1.7 based on
>> the
>> >> 3rd RC.
>> >> >
>> >> > There have been the following changes since RC2:
>> >> > * Some files in the conf directory have been added Apache license
>> >> headers. (Note that the majority of files in this folder are simple test
>> >> files used by unit tests and do not have license headers.)
>> >> > * Minor changes in the wording of the site and the release notes
>> related
>> >> to trademark policy as suggested by sebb.
>> >> >
>> >> > Tag:
>> >>
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
>> >> >
>> >> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
>> >> >
>> >> > Maven artifacts:
>> >> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
>> >> >
>> >> > Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
>> >> >
>> >> > [ ] +1 release it
>> >> > [ ] +0 go ahead I don't care
>> >> > [ ] -1 no, do not release it because...
>> >> >
>> >> > Vote will remain open for 72 hours.
>> >> >
>> >> > Oliver
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://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: [math] removing MathUserException

[Phil Steitz]

On 9/5/11 12:47 PM, Luc Maisonobe wrote:
> Hello,
>
> Cleaning out the ode package, I have seen that we throw ourselves
> a MathUserException when the max number of allowed evaluations was
> exceeded. I have fixed that in my local copy (not committed yet)
> and used the opportunity to replace the ad hoc code by the new
> Incrementor class, which purpose is precisely to count things and
> throw a dedicated exception (MaxCountExceededException) if needed.
> This also allowed to remove the last use of
> MaxEvaluationExceededException and hence the exception itself
> (which was still in the top level package).
>
> As I wrote a few hours ago answering a question from Dennis, we
> can now get completely rid of MathUserException in the ode
> package. I have also done that and checked everything worked well.
> The idea behind this was discussed some months ago if I remember
> well. It was simply that users should better use their own
> unchecked exception, so they can be sure [math] will never catch
> them, when they call [math] code which itself call their functions
> back (like in ODE, root solvers, optimization ...). The current
> behavior with MathUserException was not really clean since we did
> throw it by ourselves (at least in ODE, which I removed). As an
> example, some clean user code should be:
>
> public class Myclass implements FirstOrderDifferentialEquation {
>   private static class LocalException extends RuntimeException {
> public LocalException(int a, int b, int c) {
>// store some information about a, b, c
> }
>
> // some getters go here
>
>   }
>
>   public void solveODE() {
>  try {
>  integrator.integrate(this, t0, y0, t, y);
>  } catch (LocalException le) {
> // retrieve the a, b and c values
>  }
>
>   }
>
>   public int getDimension() {
> return 3;
>   }
>
>   public void computeDerivatives(double t, double[] y, double[]
> yDot) {
>
>  // compute things
>
>  if (somethingBadHappens) {
>throw new LocalException(a, b, c);
>   }
>
> }
>
> 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 to go ahead and do this.  The only downside is if any users have
built dependency on the previous setup or want to use and have us
propagate checked exceptions.  This is a major release and we can
make this change now.  I think the important thing to document is
that we will not swallow or wrap exceptions thrown by user code. 
User's can then decide what and where to throw and catch in their
own code.

Phil
> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[sebb]

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?

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
>>>         
>>>         
>>>           org.apache.maven.plugins
>>>           maven-gpg-plugin
>>> -1.3
>>> +1.4
>>>         
>>>         
>>>           org.apache.maven.plugins
>>> @@ -179,7 +179,7 @@
>>>         
>>>           org.apache.maven.plugins
>>>           maven-jar-plugin
>>> -2.3
>>> +2.3.2
>>>         
>>>         
>>>           org.apache.maven.plugins
>>> @@ -227,7 +227,7 @@
>>>         
>>>

Re: [VOTE] Release Commons Configuration 1.7 based on RC3

[Phil Steitz]

+1

Sigs, hashes, release contents are good.

Tested build on Apple 1.6.0_26, BlackDown 1.4.2, Sun 1.4.2_19 , Sun
1.5.0_22, Sun 1.6.0_17, rockit 1.4.2,  Jrockit 1.5.0, Jrockit 1.6.0
using Ant for the 1.4 jdks and Ubuntu for all but the first test.

Nice work!

Phil

On 9/4/11 12:40 PM, Oliver Heger wrote:
> This is a vote to release Apache Commons Configuration 1.7 based
> on the 3rd RC.
>
> There have been the following changes since RC2:
> * Some files in the conf directory have been added Apache license
> headers. (Note that the majority of files in this folder are
> simple test files used by unit tests and do not have license
> headers.)
> * Minor changes in the wording of the site and the release notes
> related to trademark policy as suggested by sebb.
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
>
> Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
>
> Maven artifacts:
> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
>
> Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
>
> Vote will remain open for 72 hours.
>
> Oliver
>
> -
> 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

[math] removing MathUserException

[Luc Maisonobe]

Hello,

Cleaning out the ode package, I have seen that we throw ourselves a 
MathUserException when the max number of allowed evaluations was 
exceeded. I have fixed that in my local copy (not committed yet) and 
used the opportunity to replace the ad hoc code by the new Incrementor 
class, which purpose is precisely to count things and throw a dedicated 
exception (MaxCountExceededException) if needed. This also allowed to 
remove the last use of MaxEvaluationExceededException and hence the 
exception itself (which was still in the top level package).


As I wrote a few hours ago answering a question from Dennis, we can now 
get completely rid of MathUserException in the ode package. I have also 
done that and checked everything worked well. The idea behind this was 
discussed some months ago if I remember well. It was simply that users 
should better use their own unchecked exception, so they can be sure 
[math] will never catch them, when they call [math] code which itself 
call their functions back (like in ODE, root solvers, optimization ...). 
The current behavior with MathUserException was not really clean since 
we did throw it by ourselves (at least in ODE, which I removed). As an 
example, some clean user code should be:


public class Myclass implements FirstOrderDifferentialEquation {
  private static class LocalException extends RuntimeException {
public LocalException(int a, int b, int c) {
   // store some information about a, b, c
}

// some getters go here

  }

  public void solveODE() {
 try {
 integrator.integrate(this, t0, y0, t, y);
 } catch (LocalException le) {
// retrieve the a, b and c values
 }

  }

  public int getDimension() {
return 3;
  }

  public void computeDerivatives(double t, double[] y, double[] yDot) {

 // compute things

 if (somethingBadHappens) {
   throw new LocalException(a, b, c);
  }

}

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 ?
Luc

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

Re: [VOTE] Release Commons Configuration 1.7 based on RC3

[Simone Tripodi]

Hi Oliver,
sorry for question, I didn't pay enough attention on JVM compliance
level, sorry :(

+1 for the release:

 * build worked
 * gpg signatures are ok
 * checksums are ok
 * documentation site looks good

thanks for the hard work on configuration!
Simo

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



On Mon, Sep 5, 2011 at 8:33 PM, Gary Gregory  wrote:
> On Mon, Sep 5, 2011 at 2:05 PM, sebb  wrote:
>
>> On 5 September 2011 18:27, Gary Gregory  wrote:
>> > Or maybe we should push this one out and then update everything in
>> trunk...
>> >
>> > So +1 from me with a note that src/site/xdoc/style/project.css should
>> have a
>> > license header for completness' sake for the next go around (it's a one
>> > liner file I know ;)
>>
>> It's not necessary to add an AL header to such a short file.
>>
>
> But it's nice to be consistent and not have to consider this file as a
> special case because the line count is less than X when evaluating a RAT
> report. ;)
>
> At what line count do we need a license header?
>
> Gary
>
>
>>
>> > Gary
>> >
>> > On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory 
>> wrote:
>> >
>> >> I'm all for updating to the latest and greatest of all components.
>> >>
>> >> Gary
>> >>
>> >> On Sep 4, 2011, at 15:41, Oliver Heger 
>> >> wrote:
>> >>
>> >> > This is a vote to release Apache Commons Configuration 1.7 based on
>> the
>> >> 3rd RC.
>> >> >
>> >> > There have been the following changes since RC2:
>> >> > * Some files in the conf directory have been added Apache license
>> >> headers. (Note that the majority of files in this folder are simple test
>> >> files used by unit tests and do not have license headers.)
>> >> > * Minor changes in the wording of the site and the release notes
>> related
>> >> to trademark policy as suggested by sebb.
>> >> >
>> >> > Tag:
>> >>
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
>> >> >
>> >> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
>> >> >
>> >> > Maven artifacts:
>> >> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
>> >> >
>> >> > Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
>> >> >
>> >> > [ ] +1 release it
>> >> > [ ] +0 go ahead I don't care
>> >> > [ ] -1 no, do not release it because...
>> >> >
>> >> > Vote will remain open for 72 hours.
>> >> >
>> >> > Oliver
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://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: [Math] Merging unique "...Impl" classes with their interface?

[Gilles Sadowski]

Hi Sébastien.

> Gilles,
> if you're going to do that soon, I'll stop removing methods
> solve(double[]) from DecompositionSolvers (I've only done Cholesky so
> far), so that our modifications do not conflict.

If you want, you can do it.
[A JIRA issue has yet to be opened, which you can do too.]


Best regards,
Gilles

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

Re: [VOTE] Release Commons Configuration 1.7 based on RC3

[Gary Gregory]

On Mon, Sep 5, 2011 at 2:05 PM, sebb  wrote:

> On 5 September 2011 18:27, Gary Gregory  wrote:
> > Or maybe we should push this one out and then update everything in
> trunk...
> >
> > So +1 from me with a note that src/site/xdoc/style/project.css should
> have a
> > license header for completness' sake for the next go around (it's a one
> > liner file I know ;)
>
> It's not necessary to add an AL header to such a short file.
>

But it's nice to be consistent and not have to consider this file as a
special case because the line count is less than X when evaluating a RAT
report. ;)

At what line count do we need a license header?

Gary


>
> > Gary
> >
> > On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory 
> wrote:
> >
> >> I'm all for updating to the latest and greatest of all components.
> >>
> >> Gary
> >>
> >> On Sep 4, 2011, at 15:41, Oliver Heger 
> >> wrote:
> >>
> >> > This is a vote to release Apache Commons Configuration 1.7 based on
> the
> >> 3rd RC.
> >> >
> >> > There have been the following changes since RC2:
> >> > * Some files in the conf directory have been added Apache license
> >> headers. (Note that the majority of files in this folder are simple test
> >> files used by unit tests and do not have license headers.)
> >> > * Minor changes in the wording of the site and the release notes
> related
> >> to trademark policy as suggested by sebb.
> >> >
> >> > Tag:
> >>
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
> >> >
> >> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
> >> >
> >> > Maven artifacts:
> >> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
> >> >
> >> > Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
> >> >
> >> > [ ] +1 release it
> >> > [ ] +0 go ahead I don't care
> >> > [ ] -1 no, do not release it because...
> >> >
> >> > Vote will remain open for 72 hours.
> >> >
> >> > Oliver
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >>
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Oliver Heger]

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/

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
 
 
   org.apache.maven.plugins
   maven-gpg-plugin
-1.3
+1.4
 
 
   org.apache.maven.plugins
@@ -179,7 +179,7 @@
 
   org.apache.maven.plugins
   maven-jar-plugin
-2.3
+2.3.2
 
 
   org.apache.maven.plugins
@@ -227,7 +227,7 @@
 
   org.apache.maven.plugins
   maven-site-plugin
-2.2
+3.0
 
 
   org.apache.maven.plugins
@@ -259,8 +259,7 @@
 
   org.apache.felix
   maven-bundle-plugin
-
-1.4.3
+2.3.5
   true
 
   





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




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




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




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




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




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

Re: Default threshold in "LUDecompositionImpl"

[Luc Maisonobe]

Le 05/09/2011 15:23, Gilles Sadowski a écrit :

Hello.


Hi Gilles,



There might be a typo in the value for the default singularity threshold
value in class "LUDecompositionImpl" (at line 37): Was
  10E-12
the intended value, or was it
  1e-12
?


It is probably a typo, but the exact value was certainly chosen almost 
arbitrarily. However, since it has now been published and changing it 
may break code, I would suggest to write it 1e-11.


best regards,
Luc




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: [VOTE] Release Commons Configuration 1.7 based on RC3

[sebb]

On 5 September 2011 18:27, Gary Gregory  wrote:
> Or maybe we should push this one out and then update everything in trunk...
>
> So +1 from me with a note that src/site/xdoc/style/project.css should have a
> license header for completness' sake for the next go around (it's a one
> liner file I know ;)

It's not necessary to add an AL header to such a short file.

> Gary
>
> On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory  wrote:
>
>> I'm all for updating to the latest and greatest of all components.
>>
>> Gary
>>
>> On Sep 4, 2011, at 15:41, Oliver Heger 
>> wrote:
>>
>> > This is a vote to release Apache Commons Configuration 1.7 based on the
>> 3rd RC.
>> >
>> > There have been the following changes since RC2:
>> > * Some files in the conf directory have been added Apache license
>> headers. (Note that the majority of files in this folder are simple test
>> files used by unit tests and do not have license headers.)
>> > * Minor changes in the wording of the site and the release notes related
>> to trademark policy as suggested by sebb.
>> >
>> > Tag:
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
>> >
>> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
>> >
>> > Maven artifacts:
>> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
>> >
>> > Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
>> >
>> > [ ] +1 release it
>> > [ ] +0 go ahead I don't care
>> > [ ] -1 no, do not release it because...
>> >
>> > Vote will remain open for 72 hours.
>> >
>> > Oliver
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://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: [VOTE] Release Commons Configuration 1.7 based on RC3

[Oliver Heger]

Hi Simone,

IIUC Digester 2.x requires JDK 1.5 while this version of Configuration 
still targets 1.4. My plan is that the next version will go for 1.5, 
then we will of course update the dependencies.


Please see also my response to Gary's mail.

Oliver

Am 04.09.2011 21:52, schrieb Simone Tripodi:

Hallo Oliver,
I'm reviewing the tag and, sorry for not having noticed before, is
there any reason why the Digester is still at 1.8 version?
Upgrade to at least 2.1 should be painless enough, even if an upgrade
to 3.0 would be nicer :P
Anyway, not a blocker, just the time of reviewing all the stuff and
express my vote :)
Have a nice day, all the best!
Simo

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



On Sun, Sep 4, 2011 at 9:40 PM, Oliver Heger
  wrote:

This is a vote to release Apache Commons Configuration 1.7 based on the 3rd
RC.

There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license headers.
(Note that the majority of files in this folder are simple test files used
by unit tests and do not have license headers.)
* Minor changes in the wording of the site and the release notes related to
trademark policy as suggested by sebb.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/

Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc3/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Vote will remain open for 72 hours.

Oliver

-
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: [VOTE] Release Commons Configuration 1.7 based on RC3

[Oliver Heger]

Hi Gary,

Am 05.09.2011 19:27, schrieb Gary Gregory:

Or maybe we should push this one out and then update everything in trunk...


this was indeed my plan. The last version came out in December 2008, so 
a release is overdue.


I hope to be able to work on a version 1.8 afterwards which targets Java 
1.5 - no big changes, but some polishing of the API which can hopefully 
be binary compatible. This is a good opportunity to update all 
dependencies to the newest Commons components which are already on Java 1.5.





So +1 from me with a note that src/site/xdoc/style/project.css should have a
license header for completness' sake for the next go around (it's a one
liner file I know ;)


Thanks.
Oliver



Gary

On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory  wrote:


I'm all for updating to the latest and greatest of all components.

Gary

On Sep 4, 2011, at 15:41, Oliver Heger
wrote:


This is a vote to release Apache Commons Configuration 1.7 based on the

3rd RC.


There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license

headers. (Note that the majority of files in this folder are simple test
files used by unit tests and do not have license headers.)

* Minor changes in the wording of the site and the release notes related

to trademark policy as suggested by sebb.


Tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts:

http://people.apache.org/~oheger/configuration-1.7rc3/maven/


Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

Vote will remain open for 72 hours.

Oliver

-
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: [VOTE] Release Commons Configuration 1.7 based on RC3

[Gary Gregory]

Or maybe we should push this one out and then update everything in trunk...

So +1 from me with a note that src/site/xdoc/style/project.css should have a
license header for completness' sake for the next go around (it's a one
liner file I know ;)

Gary

On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory  wrote:

> I'm all for updating to the latest and greatest of all components.
>
> Gary
>
> On Sep 4, 2011, at 15:41, Oliver Heger 
> wrote:
>
> > This is a vote to release Apache Commons Configuration 1.7 based on the
> 3rd RC.
> >
> > There have been the following changes since RC2:
> > * Some files in the conf directory have been added Apache license
> headers. (Note that the majority of files in this folder are simple test
> files used by unit tests and do not have license headers.)
> > * Minor changes in the wording of the site and the release notes related
> to trademark policy as suggested by sebb.
> >
> > Tag:
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/
> >
> > Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/
> >
> > Maven artifacts:
> http://people.apache.org/~oheger/configuration-1.7rc3/maven/
> >
> > Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/
> >
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because...
> >
> > Vote will remain open for 72 hours.
> >
> > Oliver
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://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: [chain][v2] clever context

[Simone Tripodi]

Hi Paul,
agreed. I just started indeed a thread vote to accept the new codebase
as /trunk, so we can continue working toward a new releas wich
involves redesigns as well.

I would really appreciate if you and James partecipate in the vote and
could continue co-operate until next release!!!
Have a nice day, all the best,
Simo

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



On Mon, Sep 5, 2011 at 6:04 PM, Paul Benedict  wrote:
> Major versions don't need to keep compatibility. Even if it is
> laudable goal to try, I rather have a better designed software and do
> 30 minutes of upgrading code than keep dragging along old decisions.
>
> On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta  wrote:
>> On 09/05/2011 08:51 AM, Simone Tripodi wrote:
>>> I totally agree with you James, what is needed is just to understand
>>> if break the 1.X compatibility or not...
>>> I think that the discussion worths a vote call at that point, WDYT?
>>> Many thanks in advance, have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>
>> As a chain user, I'd be fine with that for 2.x: +1 non-binding.
>>
>> 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

Re: [CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[Simone Tripodi]

Hi Jochen!
we still haven't because, as emerged in the past discussions, actual
modifications can still be considered acceptable in therms of
retro-compatibility.
Anyway, we are also in the middle of discussions about API redesign,
and breaking the 1.X compatibility, so we will update those metadata
as soon as that compatibility is broken.
Thanks for the reminders!
Simo

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



On Mon, Sep 5, 2011 at 5:37 PM, sebb  wrote:
> On 5 September 2011 16:33, Jochen Wiedmann  wrote:
>> Housework check:
>>
>> -  Has the package name been changed?
>> A- Has thae Maven groupId aand/or artifactId been changed?
>
> I'd strongly recommend leaving these changes until just before release
> - it's much easier to run Clirr if the package name has not been
> changed.
>
>> DAOes t>
>> On Mon, Sep 5, 2011 at 5:13 PM, Simone Tripodi  
>> wrote:
>>> Hi all guys,
>>> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
>>> group of Commons committers started working on that component in a
>>> branch 2.0[1] to experiment updates and study improvements in order to
>>> push a next release soon.
>>> We are in the middle of discussing about the current/improved design,
>>> maintaining - or not - the retro-compatibility, better modularization
>>> - splitting the chain in submodules - and so on, so as you maybe
>>> noticed latest ML activity looks like there is a renewed interest from
>>> both committers and users that came back to submit contributions.
>>> You would be maybe interested on see which level of
>>> retro-compatibility we maintained after the update, by reading the
>>> Clirr report[2] published on my personal ASF space.
>>> So we are interested on releasing that code and our proposal is to
>>> move the current trunk in a 1.x branch and move the 2.0 work in trunk,
>>> please cast your vote:
>>>
>>> [+1]    let's make the branch the code we want to see released as new chain
>>> [+/- 0] feel free to express opinions
>>> [-1]     because...
>>>
>>> Feedbacks are, obviously, welcome.
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> [1] 
>>> https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
>>> [2] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>

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

Re: svn commit: r1165033 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java

[luc . maisonobe]

Hi Dennis,

- Mail original -
> Hi Luc,
> 
> The FirstOrderDifferentialEquations interface has a method
> computeDerivatives, which also still throws the MathUserException.
> Did you
> forget that one as well, or did you intentionally leave it in?


I forgot it. MathUserException should completely disappear from ODE, and maybe 
fom other packages too
like solvers or optimizers.

In fact, even if it does not disappear completely, I would suggest user to not 
use it anymore and use
their own unchecked exceptions. Users can define a class that does not throw 
this exception even if
the interface declaration does specifies it (but the other way round is 
forbidden: you can't add
a checked exception not declared in the interface).

best regards,
Luc

> 
> Best regards,
> Dennis
> 
> 
> luc.maison...@free.fr wrote:
> > Hi Dennis,
> > 
> > - Mail original -
> >> Hi Luc,
> >>
> >> question: is there a reason you applied this to StepHandler, but
> >> not
> >> FixedStepHandler?
> > 
> > No, I simply forgot it. I'll fix that. Thanks for reminding me
> > about it.
> > 
> > The proper way to propagate exception (discussed a while ago), is
> > to have user
> > set up an unchecked exception of his own. This way, he is certain
> > [math] will
> > not catch it.
> > 
> > best regards
> > 
> > Luc
> > 
> >> Best regards,
> >> Dennis
> >>
> >>
> >>
> >> l...@apache.org wrote:
> >>> Author: luc
> >>> Date: Sun Sep  4 14:36:48 2011
> >>> New Revision: 1165033
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1165033&view=rev
> >>> Log:
> >>> removed MathUserException from StepHandler interface
> >>>
> >>> JIRA: MATH-488
> >>>
> >>> Modified:
> >>> 
> >>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> >>>
> >>> Modified:
> >>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> >>> URL:
> >>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java?rev=1165033&r1=1165032&r2=1165033&view=diff
> >>> ==
> >>> ---
> >>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> >>> (original)
> >>> +++
> >>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> >>> Sun Sep  4 14:36:48 2011
> >>> @@ -17,7 +17,6 @@
> >>>  
> >>>  package org.apache.commons.math.ode.sampling;
> >>>  
> >>> -import org.apache.commons.math.exception.MathUserException;
> >>>  
> >>>  /**
> >>>   * This interface represents a handler that should be called
> >>>   after
> >>> @@ -60,9 +59,7 @@ public interface StepHandler {
> >>> * Keeping only a reference to the interpolator and reusing it
> >>> will
> >>> * result in unpredictable behavior (potentially crashing the
> >>> application).
> >>> * @param isLast true if the step is the last one
> >>> -   * @exception MathUserException if user code called from step
> >>> interpolator
> >>> -   * finalization triggers one
> >>> */
> >>> -  void handleStep(StepInterpolator interpolator, boolean isLast)
> >>> throws MathUserException;
> >>> +  void handleStep(StepInterpolator interpolator, boolean
> >>> isLast);
> >>>  
> >>>  }
> >>>
> >>>
> >>
> >> -
> >> 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

[Paul Benedict]

Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.

On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta  wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wrote:
>> I totally agree with you James, what is needed is just to understand
>> if break the 1.X compatibility or not...
>> I think that the discussion worths a vote call at that point, WDYT?
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>
> As a chain user, I'd be fine with that for 2.x: +1 non-binding.
>
> 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

Re: [chain][v2] clever context

[Raman Gupta]

On 09/05/2011 08:51 AM, Simone Tripodi wrote:
> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion worths a vote call at that point, WDYT?
> Many thanks in advance, have a nice day!
> Simo
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

As a chain user, I'd be fine with that for 2.x: +1 non-binding.

Cheers,
Raman

-
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

[Phil Steitz]

On 9/5/11 7:21 AM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
>> To make things clear here some octave (matlab as well) calculation with
>> complex:
>>
>> octave:1> a = Inf + sqrt(-Inf)
>> a = Inf + Infi
>> octave:2> a * a
>> ans = NaN + Infi
>> octave:3> a = Inf + sqrt(-1)
>> a = Inf +   1i
>> octave:4> a * a
>> ans = Inf + Infi
>> octave:5> a = 1 + sqrt(-Inf)
>> a =1 + Infi
>> octave:6> a * a
>> ans = -Inf + Infi
>> octave:7> a = 1 - sqrt(-Inf)
>> a =1 - Infi
>> octave:8> a * a
>> ans = -Inf - Infi
>>
>> Maybe Im wrong but I thought that was the result I could expect from
>> commons math too.
> It seems that the above outputs result from a direct application of the
> computational formula (whereas.
> As I suggested on JIRA, a complete set of comparisons, as a unit test, would
> be most helpful to check where the discrepancies occur.
>
>> In electrical engineering there is a difference if you have + or - 90
>> degree phase shift, the tan will be +infinity or -infinity...
>> If you math guys tell me that there is really no difference with complex
>> numbers - I can live with it (Even if I dont understand why ;-)). 
> What would be really interesting is to know when the final result of the
> DSP algorithm differ between Octave and the Java translation using CM.

Right, that's what I am having trouble finding good examples for. 
My own apps don't seem to be affected by the different choices - but
they tend to treat "divergence to an infinity" or "divergence to
NaN" similarly, so are not good test cases.  I suspect that in most
practical use cases, the differences in behavior will most likely be
on exception paths, but I would be very interested in hearing about
examples where people actually depend on either a) attempts to
faithfully model the Riemann Sphere (so infinities get collapsed) or
b) computation with signed infinities and even elements including
NaNs and infinities (as C99x appears to allow).

I can't find a clear statement in the Octave docs on exactly how
complex arithmetic (or other) functions are defined.  A decent
hypothesis is that it uses GCC under the covers, so it should be
more or less trying to do C99x (though depending on the version,
there are some spec compliance bugs reported).  Could be I am
looking in the wrong place [1] for the docs.  Does anyone know where
this is documented?

Phil

[1] http://www.gnu.org/software/octave/doc/interpreter/
>
>
> Regards,
> 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: [CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[sebb]

On 5 September 2011 16:33, Jochen Wiedmann  wrote:
> Housework check:
>
> -  Has the package name been changed?
> A- Has thae Maven groupId aand/or artifactId been changed?

I'd strongly recommend leaving these changes until just before release
- it's much easier to run Clirr if the package name has not been
changed.

> DAOes t
> On Mon, Sep 5, 2011 at 5:13 PM, Simone Tripodi  
> wrote:
>> Hi all guys,
>> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
>> group of Commons committers started working on that component in a
>> branch 2.0[1] to experiment updates and study improvements in order to
>> push a next release soon.
>> We are in the middle of discussing about the current/improved design,
>> maintaining - or not - the retro-compatibility, better modularization
>> - splitting the chain in submodules - and so on, so as you maybe
>> noticed latest ML activity looks like there is a renewed interest from
>> both committers and users that came back to submit contributions.
>> You would be maybe interested on see which level of
>> retro-compatibility we maintained after the update, by reading the
>> Clirr report[2] published on my personal ASF space.
>> So we are interested on releasing that code and our proposal is to
>> move the current trunk in a 1.x branch and move the 2.0 work in trunk,
>> please cast your vote:
>>
>> [+1]    let's make the branch the code we want to see released as new chain
>> [+/- 0] feel free to express opinions
>> [-1]     because...
>>
>> Feedbacks are, obviously, welcome.
>> Many thanks in advance, all the best!!!
>> Simo
>>
>> [1] 
>> https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
>> [2] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>
> --
> 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: [CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[Jochen Wiedmann]

Housework check:

-  Has the package name been changed?
A- Has thae Maven groupId aand/or artifactId been changed?

DAOes t wrote:
> Hi all guys,
> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
> group of Commons committers started working on that component in a
> branch 2.0[1] to experiment updates and study improvements in order to
> push a next release soon.
> We are in the middle of discussing about the current/improved design,
> maintaining - or not - the retro-compatibility, better modularization
> - splitting the chain in submodules - and so on, so as you maybe
> noticed latest ML activity looks like there is a renewed interest from
> both committers and users that came back to submit contributions.
> You would be maybe interested on see which level of
> retro-compatibility we maintained after the update, by reading the
> Clirr report[2] published on my personal ASF space.
> So we are interested on releasing that code and our proposal is to
> move the current trunk in a 1.x branch and move the 2.0 work in trunk,
> please cast your vote:
>
> [+1]    let's make the branch the code we want to see released as new chain
> [+/- 0] feel free to express opinions
> [-1]     because...
>
> Feedbacks are, obviously, welcome.
> Many thanks in advance, all the best!!!
> Simo
>
> [1] 
> https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
> [2] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>



-- 
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: [CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[Simone Tripodi]

my +1
Simo

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



On Mon, Sep 5, 2011 at 5:13 PM, Simone Tripodi  wrote:
> Hi all guys,
> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
> group of Commons committers started working on that component in a
> branch 2.0[1] to experiment updates and study improvements in order to
> push a next release soon.
> We are in the middle of discussing about the current/improved design,
> maintaining - or not - the retro-compatibility, better modularization
> - splitting the chain in submodules - and so on, so as you maybe
> noticed latest ML activity looks like there is a renewed interest from
> both committers and users that came back to submit contributions.
> You would be maybe interested on see which level of
> retro-compatibility we maintained after the update, by reading the
> Clirr report[2] published on my personal ASF space.
> So we are interested on releasing that code and our proposal is to
> move the current trunk in a 1.x branch and move the 2.0 work in trunk,
> please cast your vote:
>
> [+1]    let's make the branch the code we want to see released as new chain
> [+/- 0] feel free to express opinions
> [-1]     because...
>
> Feedbacks are, obviously, welcome.
> Many thanks in advance, all the best!!!
> Simo
>
> [1] 
> https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
> [2] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>

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

[CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[Simone Tripodi]

Hi all guys,
thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
group of Commons committers started working on that component in a
branch 2.0[1] to experiment updates and study improvements in order to
push a next release soon.
We are in the middle of discussing about the current/improved design,
maintaining - or not - the retro-compatibility, better modularization
- splitting the chain in submodules - and so on, so as you maybe
noticed latest ML activity looks like there is a renewed interest from
both committers and users that came back to submit contributions.
You would be maybe interested on see which level of
retro-compatibility we maintained after the update, by reading the
Clirr report[2] published on my personal ASF space.
So we are interested on releasing that code and our proposal is to
move the current trunk in a 1.x branch and move the 2.0 work in trunk,
please cast your vote:

[+1]let's make the branch the code we want to see released as new chain
[+/- 0] feel free to express opinions
[-1] because...

Feedbacks are, obviously, welcome.
Many thanks in advance, all the best!!!
Simo

[1] 
https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
[2] http://people.apache.org/~simonetripodi/chain/clirr-report.html

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

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

Re: [Math] Merging unique "...Impl" classes with their interface?

[Sébastien Brisard]

Gilles,
if you're going to do that soon, I'll stop removing methods
solve(double[]) from DecompositionSolvers (I've only done Cholesky so
far), so that our modifications do not conflict.
Sébastien


2011/9/5 Phil Steitz :
> On 9/5/11 3:43 AM, Gilles Sadowski wrote:
>> Hi.
>>
>> The "...Decomposition" interfaces in package "linear" have a unique
>> implementation. Should the "...Impl" classes be renamed (removing the
>> interfaces)?
>
> +1
>
> Phil
>>
>>
>> Regards,
>> 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
>
>

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

Re: [Math] Merging unique "...Impl" classes with their interface?

[Phil Steitz]

On 9/5/11 3:43 AM, Gilles Sadowski wrote:
> Hi.
>
> The "...Decomposition" interfaces in package "linear" have a unique
> implementation. Should the "...Impl" classes be renamed (removing the
> interfaces)?

+1

Phil
>
>
> Regards,
> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Ralph Goers]

If you are making changes that affect the site I'd appreciate you also testing 
vfs as it is a multi-module build.

Ralph

On Sep 5, 2011, at 6:52 AM, sebb wrote:

> 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.
> 
>> 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
>> 
>> 
>>   org.apache.maven.plugins
>>   maven-gpg-plugin
>> -1.3
>> +1.4
>> 
>> 
>>   org.apache.maven.plugins
>> @@ -179,7 +179,7 @@
>> 
>>   org.apache.maven.plugins
>>   maven-jar-plugin
>> -2.3
>> +2.3.2
>> 
>> 
>>   org.apache.maven.plugins
>> @@ -227,7 +227,7 @@
>> 
>>   org.apache.maven.plugins
>>   maven-site-plugin
>> -2.2
>> +3.0
>> 
>> 
>>   org.apache.maven.plugins
>> @@ -259,8 +259,7 @@
>> 
>>   org.apache.felix
>>   maven-bundle-plugin
>> -
>> -1.4.3
>> +2.3.5
>>   true
>> 
>>   
>> 
>> 
>> 
> 
> -
> 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

[Gilles Sadowski]

On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
> To make things clear here some octave (matlab as well) calculation with
> complex:
> 
> octave:1> a = Inf + sqrt(-Inf)
> a = Inf + Infi
> octave:2> a * a
> ans = NaN + Infi
> octave:3> a = Inf + sqrt(-1)
> a = Inf +   1i
> octave:4> a * a
> ans = Inf + Infi
> octave:5> a = 1 + sqrt(-Inf)
> a =1 + Infi
> octave:6> a * a
> ans = -Inf + Infi
> octave:7> a = 1 - sqrt(-Inf)
> a =1 - Infi
> octave:8> a * a
> ans = -Inf - Infi
> 
> Maybe Im wrong but I thought that was the result I could expect from
> commons math too.

It seems that the above outputs result from a direct application of the
computational formula (whereas.
As I suggested on JIRA, a complete set of comparisons, as a unit test, would
be most helpful to check where the discrepancies occur.

> In electrical engineering there is a difference if you have + or - 90
> degree phase shift, the tan will be +infinity or -infinity...
> If you math guys tell me that there is really no difference with complex
> numbers - I can live with it (Even if I dont understand why ;-)). 

What would be really interesting is to know when the final result of the
DSP algorithm differ between Octave and the Java translation using CM.


Regards,
Gilles

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

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

[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.

> 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
>         
>         
>           org.apache.maven.plugins
>           maven-gpg-plugin
> -1.3
> +1.4
>         
>         
>           org.apache.maven.plugins
> @@ -179,7 +179,7 @@
>         
>           org.apache.maven.plugins
>           maven-jar-plugin
> -2.3
> +2.3.2
>         
>         
>           org.apache.maven.plugins
> @@ -227,7 +227,7 @@
>         
>           org.apache.maven.plugins
>           maven-site-plugin
> -2.2
> +3.0
>         
>         
>           org.apache.maven.plugins
> @@ -259,8 +259,7 @@
>         
>           org.apache.felix
>           maven-bundle-plugin
> -
> -1.4.3
> +2.3.5
>           true
>         
>       
>
>
>

 -
 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

Default threshold in "LUDecompositionImpl"

[Gilles Sadowski]

Hello.

There might be a typo in the value for the default singularity threshold
value in class "LUDecompositionImpl" (at line 37): Was
 10E-12
the intended value, or was it
 1e-12
?


Gilles

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

Re: [chain][v2] clever context

[James Carman]

Well, if you're going to a 2.x, then I say break it and do it the
right way.  Consider that my +1.

On Mon, Sep 5, 2011 at 8:51 AM, Simone Tripodi  wrote:
> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion worths a vote call at that point, WDYT?
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 5, 2011 at 1: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.
>>
>> 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: svn commit: r1165033 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java

[Dennis Hendriks]

Hi Luc,

The FirstOrderDifferentialEquations interface has a method 
computeDerivatives, which also still throws the MathUserException. Did you 
forget that one as well, or did you intentionally leave it in?


Best regards,
Dennis


luc.maison...@free.fr wrote:

Hi Dennis,

- Mail original -

Hi Luc,

question: is there a reason you applied this to StepHandler, but not
FixedStepHandler?


No, I simply forgot it. I'll fix that. Thanks for reminding me about it.

The proper way to propagate exception (discussed a while ago), is to have user
set up an unchecked exception of his own. This way, he is certain [math] will
not catch it.

best regards

Luc


Best regards,
Dennis



l...@apache.org wrote:

Author: luc
Date: Sun Sep  4 14:36:48 2011
New Revision: 1165033

URL: http://svn.apache.org/viewvc?rev=1165033&view=rev
Log:
removed MathUserException from StepHandler interface

JIRA: MATH-488

Modified:

commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java

Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java?rev=1165033&r1=1165032&r2=1165033&view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
Sun Sep  4 14:36:48 2011
@@ -17,7 +17,6 @@
 
 package org.apache.commons.math.ode.sampling;
 
-import org.apache.commons.math.exception.MathUserException;
 
 /**

  * This interface represents a handler that should be called after
@@ -60,9 +59,7 @@ public interface StepHandler {
* Keeping only a reference to the interpolator and reusing it
will
* result in unpredictable behavior (potentially crashing the
application).
* @param isLast true if the step is the last one
-   * @exception MathUserException if user code called from step
interpolator
-   * finalization triggers one
*/
-  void handleStep(StepInterpolator interpolator, boolean isLast)
throws MathUserException;
+  void handleStep(StepInterpolator interpolator, boolean isLast);
 
 }





-
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

[Simone Tripodi]

I totally agree with you James, what is needed is just to understand
if break the 1.X compatibility or not...
I think that the discussion worths a vote call at that point, WDYT?
Many thanks in advance, have a nice day!
Simo

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



On Mon, Sep 5, 2011 at 1: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.
>
> 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

Re: [math] Complex division WASRe [jira] [Commented] (MATH-657) Division by zero

[Arne Ploese]

To make things clear here some octave (matlab as well) calculation with
complex:

octave:1> a = Inf + sqrt(-Inf)
a = Inf + Infi
octave:2> a * a
ans = NaN + Infi
octave:3> a = Inf + sqrt(-1)
a = Inf +   1i
octave:4> a * a
ans = Inf + Infi
octave:5> a = 1 + sqrt(-Inf)
a =1 + Infi
octave:6> a * a
ans = -Inf + Infi
octave:7> a = 1 - sqrt(-Inf)
a =1 - Infi
octave:8> a * a
ans = -Inf - Infi

Maybe Im wrong but I thought that was the result I could expect from
commons math too.
In electrical engineering there is a difference if you have + or - 90
degree phase shift, the tan will be +infinity or -infinity...
If you math guys tell me that there is really no difference with complex
numbers - I can live with it (Even if I dont understand why ;-)). 

Am Montag, den 05.09.2011, 12:45 +0200 schrieb Arne Ploese: 
> Sorry answering that late, but I was busy...
> 
> So simply I try to write a lib that doing some DSP stuff. I took some
> *.m files from the octave signaling package ant converted them to java
> (digital filters aka. Butterworth ...) there is a litte bit calculation
> needed.   
> 
> So my problem is: if the commans.math.Complec behaves differently from
> the octave implementation, I dont know what I get. Currently it looks to
> me that I will have to implement a separate Complex class - I cant see a
> clean way to enhance Complex without side effects.
> 
> For All-Pole filters I need some matrix arithmetic, which is currently
> only in the jama packages (solve a non symmetric matrix).
> For others I need FFT. So currently I have to use at least two
> implementations of Complex (octave and commons jama and FFT). 
> 
> Thats my problem, plain and simple...
> 
> Arne
> 
> Am Samstag, den 03.09.2011, 08:10 -0700 schrieb Phil Steitz: 
> > On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> > > [ 
> > > https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
> > >  ] 
> > >
> > > Gilles commented on MATH-657:
> > > -
> > >
> > > I've just posted a mail on "dev".
> > 
> > Should be discussed on the dev list.  We should not be trying to
> > have discussions on API changes on JIRA tickets.  That is not what
> > JIRA is for.  It is an unwritten (well, probably is actually written
> > down somewhere by now) rule @apache that if a decision "did not
> > happen on the dev list, then it did not happen."   We should be
> > talking about API design issues on this list, not opening JIRAs each
> > time we think an API should be changed and trying to have the
> > discussion on the JIRA ticket.
> > >
> > > IMO, the main argument is consistency. Also with how reals (i.e. 
> > > {{double}}) work; IIUC, MATH-164 triggered a change for that same reason.
> > >
> > > Arne Plöse is a user and [reported|MATH-620] that the previous behaviour 
> > > was not fine for him.
> > 
> > What exactly was the practical problem?  Arne, care to elaborate?
> > >
> > > I don't think that this one change can have a discernible performance 
> > > impact.
> > > It might not be necessary to map all {{Complex}} instances that have an 
> > > infinite component to a single object. I pointed it as a convenient 
> > > justification for fixing a bug
> > 
> > Not so clear it is a "bug" - the only way to characterize it as such
> > is to model the space as compactified.
> > 
> > I notice now that multiply sort of behaves this way, and as I said
> > on the ticket, we have already defined "INF" so an argument could be
> > made that we are partly there already.  I would like to understand
> > the practical arguments pro and con - and by "practical" I mean
> > examples of how the proposed change and any others impact actual
> > uses of the class in applications.  I have reviewed my own
> > applications and for those, there is no immediate impact (other than
> > performance hit in division and complex construction), but I worry a
> > little about losing the ability to represent directed infinities if
> > we decide to really aim for "consistency" here.  I guess we could
> > retain directed infinities by adding a directed INF with an argument
> > attribute, but that would again add overhead to several operations.
> > 
> > At this point, I would like to see r1164756 reverted until we have
> > agreed on this change.
> > 
> > Phil
> > >  (and for not fixing the other two points reported by Arne in MATH-620).
> > >
> > >
> > >> Division by zero
> > >> 
> > >>
> > >> Key: MATH-657
> > >> URL: https://issues.apache.org/jira/browse/MATH-657
> > >> Project: Commons Math
> > >>  Issue Type: Bug
> > >>Reporter: Gilles
> > >>Assignee: Gilles
> > >>Priority: Minor
> > >> Fix For: 3.0
> > >>
> > >>
> > >> In class {{Complex}}, division by zero always returns NaN. I think that 
> > >> it should return NaN only when the numerator is also {{

Re: [chain][v2] clever context

[James Carman]

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.

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

Re: [compress] Pack200

[Stefan Bodewig]

On 2011-09-05, Emmanuel Bourg wrote:

> That looks interesting. Does it provide a repack mode suitable for
> signing compressed jars?

I assume you mean

,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of classfiles in the JAR. This means that packing and unpacking
| will in general invalidate any digital signatures which rely on bytewise
| images of JAR elements. In order both to sign and to pack a JAR, you
| must first pack and unpack the JAR to "normalize" it, then compute
| signatures on the unpacked JAR elements, and finally repack the signed
| JAR. Both packing steps should use precisely the same options, and the
| segment limit may also need to be set to "-1", to prevent accidental
| variation of segment boundaries as class file sizes change slightly. 
`

as in


I think the "normalization" step could be part of a util class inside
the package.  Some utility method that takes a JAR, packs it and unpacks
it again to a new jar that would then need to get signed.  Signing
itself seems outside of compress' scope to me.

Stefan

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

Re: [compress] Pack200

[Stefan Bodewig]

On 2011-09-04, sebb wrote:

> You must have put a lot of thought into this

Well, I was without network access for almost two weeks 8-)

> it would be useful to record these design decisions and investigations
> in the code somewhere.  e.g. as package Javadoc.

The current package.html already contains the "how" but not the "why",
I'll make sure the rest is persisted soemwhere as well.

Stefan

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

Re: [Math] Merging unique "...Impl" classes with their interface?

[Sébastien Brisard]

I was going to ask the same question! (I learn from you, Gilles!).
Sébastien

2011/9/5 Gilles Sadowski :
> Hi.
>
> The "...Decomposition" interfaces in package "linear" have a unique
> implementation. Should the "...Impl" classes be renamed (removing the
> interfaces)?
>
>
> Regards,
> 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: [math] Complex division WASRe [jira] [Commented] (MATH-657) Division by zero

[Arne Ploese]

Sorry answering that late, but I was busy...

So simply I try to write a lib that doing some DSP stuff. I took some
*.m files from the octave signaling package ant converted them to java
(digital filters aka. Butterworth ...) there is a litte bit calculation
needed.   

So my problem is: if the commans.math.Complec behaves differently from
the octave implementation, I dont know what I get. Currently it looks to
me that I will have to implement a separate Complex class - I cant see a
clean way to enhance Complex without side effects.

For All-Pole filters I need some matrix arithmetic, which is currently
only in the jama packages (solve a non symmetric matrix).
For others I need FFT. So currently I have to use at least two
implementations of Complex (octave and commons jama and FFT). 

Thats my problem, plain and simple...

Arne

Am Samstag, den 03.09.2011, 08:10 -0700 schrieb Phil Steitz: 
> On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> > [ 
> > https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
> >  ] 
> >
> > Gilles commented on MATH-657:
> > -
> >
> > I've just posted a mail on "dev".
> 
> Should be discussed on the dev list.  We should not be trying to
> have discussions on API changes on JIRA tickets.  That is not what
> JIRA is for.  It is an unwritten (well, probably is actually written
> down somewhere by now) rule @apache that if a decision "did not
> happen on the dev list, then it did not happen."   We should be
> talking about API design issues on this list, not opening JIRAs each
> time we think an API should be changed and trying to have the
> discussion on the JIRA ticket.
> >
> > IMO, the main argument is consistency. Also with how reals (i.e. 
> > {{double}}) work; IIUC, MATH-164 triggered a change for that same reason.
> >
> > Arne Plöse is a user and [reported|MATH-620] that the previous behaviour 
> > was not fine for him.
> 
> What exactly was the practical problem?  Arne, care to elaborate?
> >
> > I don't think that this one change can have a discernible performance 
> > impact.
> > It might not be necessary to map all {{Complex}} instances that have an 
> > infinite component to a single object. I pointed it as a convenient 
> > justification for fixing a bug
> 
> Not so clear it is a "bug" - the only way to characterize it as such
> is to model the space as compactified.
> 
> I notice now that multiply sort of behaves this way, and as I said
> on the ticket, we have already defined "INF" so an argument could be
> made that we are partly there already.  I would like to understand
> the practical arguments pro and con - and by "practical" I mean
> examples of how the proposed change and any others impact actual
> uses of the class in applications.  I have reviewed my own
> applications and for those, there is no immediate impact (other than
> performance hit in division and complex construction), but I worry a
> little about losing the ability to represent directed infinities if
> we decide to really aim for "consistency" here.  I guess we could
> retain directed infinities by adding a directed INF with an argument
> attribute, but that would again add overhead to several operations.
> 
> At this point, I would like to see r1164756 reverted until we have
> agreed on this change.
> 
> Phil
> >  (and for not fixing the other two points reported by Arne in MATH-620).
> >
> >
> >> Division by zero
> >> 
> >>
> >> Key: MATH-657
> >> URL: https://issues.apache.org/jira/browse/MATH-657
> >> Project: Commons Math
> >>  Issue Type: Bug
> >>Reporter: Gilles
> >>Assignee: Gilles
> >>Priority: Minor
> >> Fix For: 3.0
> >>
> >>
> >> In class {{Complex}}, division by zero always returns NaN. I think that it 
> >> should return NaN only when the numerator is also {{ZERO}}, otherwise the 
> >> result should be {{INF}}. See 
> >> [here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
> > --
> > This message is automatically generated by JIRA.
> > For more information on JIRA, see: http://www.atlassian.com/software/jira
> >
> >
> >
> 
> 
> -
> 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] Merging unique "...Impl" classes with their interface?

[Gilles Sadowski]

Hi.

The "...Decomposition" interfaces in package "linear" have a unique
implementation. Should the "...Impl" classes be renamed (removing the
interfaces)?


Regards,
Gilles

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

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

[Gary Gregory]

FYI: 22-SNAPSHOT works with [codec].

Gary

On Mon, Sep 5, 2011 at 5:59 AM, sebb  wrote:

> On 5 September 2011 08:50, Jörg Schaible 
> wrote:
> > Hi Oliver,
> >
> > 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.
> >
> > src/site/site.xml does not have an entry to inherit the reports from the
> > parent in its body section e.g. something like:
> >
> >  
> >
> > Required for "newer" site plugin versions.
>
> The commons parent site.xml already includes that (and has done for some
> while)
>
> Or do the current site plugin versions require the component to repeat
> the entry in their own site.xml files?
>
> Where is this documented?
>
> > - Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://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

[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 80 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.002 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.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 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.01 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.161 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 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.018 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: Mon Sep 05 10:08:25 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.or

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

[sebb]

On 5 September 2011 08:50, Jörg Schaible  wrote:
> Hi Oliver,
>
> 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.
>
> src/site/site.xml does not have an entry to inherit the reports from the
> parent in its body section e.g. something like:
>
>  
>
> Required for "newer" site plugin versions.

The commons parent site.xml already includes that (and has done for some while)

Or do the current site plugin versions require the component to repeat
the entry in their own site.xml files?

Where is this documented?

> - Jörg
>
>
> -
> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Oliver Heger]

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.

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
 
 
   org.apache.maven.plugins
   maven-gpg-plugin
-1.3
+1.4
 
 
   org.apache.maven.plugins
@@ -179,7 +179,7 @@
 
   org.apache.maven.plugins
   maven-jar-plugin
-2.3
+2.3.2
 
 
   org.apache.maven.plugins
@@ -227,7 +227,7 @@
 
   org.apache.maven.plugins
   maven-site-plugin
-2.2
+3.0
 
 
   org.apache.maven.plugins
@@ -259,8 +259,7 @@
 
   org.apache.felix
   maven-bundle-plugin
-
-1.4.3
+2.3.5
   true
 
   





-
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: [compress] Pack200

[Emmanuel Bourg]

That looks interesting. Does it provide a repack mode suitable for 
signing compressed jars?


Emmanuel Bourg


Le 04/09/2011 08:04, Stefan Bodewig a écrit :

Hi,

I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.

First of all it will (by design of the format) only work on compressing
valid jar files.  Actually the result isn't likely to be compressed (in
the sense of "smaller than the original") at all but expects another
step of GZip compression in most cases.

The second difference to the other compressors is that the API provided
by the Java classlib doesn't lend itself to streaming at all.  There is
a Packer/Unpacker that expects an InputStream and an OutputStream and
converts from one to the other in a single blocking operation (even
closing the input side when done).

I have experimented with Piped*Streams as well as Ant/commons-exec-like
stream pumping in order to provide a streaming experience but always ran
into some edge cases where things broke down.  I'll give one example
below.

The current implementation of Pack200CompressorInputStream will
pass the wrapped input and an OutputStream writing to a cache to the
Unpacker synchronously inside the constructor, consuming the input
completely.  It will then defer all read-operations to the cache.

Likewise the Pack200CompressorOutputStream will buffer up all write
operations in a cache and once finish() or close() is called the cache
is converted to an InputStream that is then passed together with the
originally wrapped output to the Packer and written synchronously.

Caches can be in-memory (using ByteArray*Stream) or temporary files
controlled by a constructor option with in-memory as the default and
temp-files for cases where the archives are expected to be big.

Because of this design the byte-count methods don't make any sense (do
we count when data is written-to/read-from the cache or while the
(Un)Packer is doing its work?) and haven't been implemented at all.

The class names StreamMode and StreamSwitcher result from my attempts of
using real streams and should be changed unless anybody else comes up
with a working streaming solution.

The biggest hurdle for any streaming solution is that there is always
going to be some sort of intermediate buffer.  Something picks up data
written to the output stream and makes it available to the input stream
side.  Once the buffer is full, nothing can be written unless anybody
reads input in a timely manner.

In the case of a Pack200CompressorInputStream you don't have any control
over when the user code is going to read the data and whether it is
going to consume all of it at all.  For example if the stream is wrapped
in a ZipArchiveInputStream (it represents a JAR, after all), it is never
going to be consumed completely because the archive contains ZIP data at
the end that is ignored by the input stream implementation.

There are more cases where the Pack/Unpack operation would end up
blocked so I decided to only code the more robust indirect solution for
now.

Stefan

[1] http://download.oracle.com/javase/1.5.0/docs/api/java/util/jar/Pack200.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: [chain][v2] clever context

[Simone Tripodi]

Hi Paul,
I tend to agree with you since I don't like the Map extension too, the
only concern is just to understand how strict backward compatibility
we want to keep, or if we want almost "redesign" the public APIs.
It is an important choose we have to made in a VOTE, I suggest to
promote first the branch in trunk and then understanding if breaking
the compatibility or not.
Thanks for your hints, much more than appreciated!
Have a nice day, all the best!
Simo

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



On Mon, Sep 5, 2011 at 5:54 AM, 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

Re: [chain][v2] updated clirr report

[Simone Tripodi]

Hi Seb,
thanks a lot for your feedbacks!!!

All Clirr errors you can see on the report - except the `retrieve`
added method in the Context interface - are strictly related to
internal data structures/class fields, that were initially made as
protected so, as checkstyle suggested, I reduced the visibility and
added the accessor methods - I forgot to mark some with the @since
tag, going to add as soon as I get a spare time slot.

So, I join Matt on asserting that these modifications are minor and
could be considered backward compatible in
spirit, I would call a vote to move the current trunk in a 1_X branch
and move the current 2.0-work branch in trunk, and evolving the
component directly from there.
We also estimated junit test update and better component
modularization, that IMHO could be applied directly on trunk...

WDYT?
Many thanks in advance, have a nice day!
Simo

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



On Mon, Sep 5, 2011 at 5:52 AM, Matt Benson  wrote:
> On Sun, Sep 4, 2011 at 7:02 PM, sebb  wrote:
>> On 4 September 2011 20:04, Simone Tripodi  wrote:
>>> Hi all guys,
>>> the clirr report has just been updated on my personal ASF space[1],
>>> can you review please?
>>
>> As it stands, 2.0 is not strictly binary compatible with 1.2.
>>
>> However, it depends whether the changes affect the published API, or
>> are internal changes that should not affect external code.
>>
>> For example, the "commands" field - is there a use case for external
>> code? Or is just an implementation detail?
>>
>> I don't know the code or how it is used, so it is difficult to say,
>> but IMO there are some binary incompatibilities that can be ignored.
>> e.g. the old code defined a string field that was supposed to be
>> constant, but failed to use final. If there is no valid use case for
>> changing the value of the constant, then I think there is a case for
>> allowing that, even though it is not strictly compatible - if code
>> does write to the field then that code is broken anyway.
>
> I'm not sure if any active Commons developers know the code from a
> user perspective--at least, no one has spoken up to that effect.  From
> my own outsider's perspective, the apparent relative lack of
> popularity of the component, in addtition to the nature of the
> component and the nature of the changes made thus far, indicates that
> these are minor and could be considered backward compatible *in
> spirit*.  I don't think there should be any dispute over whether the
> branch code can become the basis of [chain]'s trunk (so my implicit +1
> on that score); only whether repackaging, etc., are necessary.  On the
> one hand, there is something to be said for consistency, which would
> suggest that a report of incompatibility by clirr automatically
> triggers repacking/GAV .  However, AIUI we have *not* required such a
> hard-and-fast rule for all components, and given that fact the
> proposed changes would seem to me minor enough to justify a major
> version bump only.
>
> Matt
>
>>
>>> I think it's time to call a vote to accept the current branch as the
>>> trunk, WDYT?
>>> Many thanks in advance, have  anice day!
>>> Simo
>>>
>>> [1] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Jörg Schaible]

Hi Oliver,

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.

src/site/site.xml does not have an entry to inherit the reports from the 
parent in its body section e.g. something like:

  

Required for "newer" site plugin versions.

- Jörg


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

Re: svn commit: r1165033 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java

[luc . maisonobe]

Hi Dennis,

- Mail original -
> Hi Luc,
> 
> question: is there a reason you applied this to StepHandler, but not
> FixedStepHandler?

No, I simply forgot it. I'll fix that. Thanks for reminding me about it.

The proper way to propagate exception (discussed a while ago), is to have user
set up an unchecked exception of his own. This way, he is certain [math] will
not catch it.

best regards

Luc

> 
> Best regards,
> Dennis
> 
> 
> 
> l...@apache.org wrote:
> > Author: luc
> > Date: Sun Sep  4 14:36:48 2011
> > New Revision: 1165033
> > 
> > URL: http://svn.apache.org/viewvc?rev=1165033&view=rev
> > Log:
> > removed MathUserException from StepHandler interface
> > 
> > JIRA: MATH-488
> > 
> > Modified:
> > 
> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> > 
> > Modified:
> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> > URL:
> > http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java?rev=1165033&r1=1165032&r2=1165033&view=diff
> > ==
> > ---
> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> > (original)
> > +++
> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/sampling/StepHandler.java
> > Sun Sep  4 14:36:48 2011
> > @@ -17,7 +17,6 @@
> >  
> >  package org.apache.commons.math.ode.sampling;
> >  
> > -import org.apache.commons.math.exception.MathUserException;
> >  
> >  /**
> >   * This interface represents a handler that should be called after
> > @@ -60,9 +59,7 @@ public interface StepHandler {
> > * Keeping only a reference to the interpolator and reusing it
> > will
> > * result in unpredictable behavior (potentially crashing the
> > application).
> > * @param isLast true if the step is the last one
> > -   * @exception MathUserException if user code called from step
> > interpolator
> > -   * finalization triggers one
> > */
> > -  void handleStep(StepInterpolator interpolator, boolean isLast)
> > throws MathUserException;
> > +  void handleStep(StepInterpolator interpolator, boolean isLast);
> >  
> >  }
> > 
> > 
> 
> 
> -
> 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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

[Jörg Schaible]

sebb wrote:

> On 4 September 2011 11:23, sebb  wrote:
>> On 4 September 2011 10:53, Luc Maisonobe  wrote:
>>> Le 04/09/2011 04:57, Phil Steitz a écrit :

 Same problem under Linux for parent 21.
>>>
>>> Isn't it related to a problem that arose some weeks ago about the
>>> resource not being copied from source tree to classpath ? I think it
>>> appeared first in Gump and someone updated the configuration to match
>>> what maven did automatically. Perhaps these new plugins do not behave
>>> like the previous one with respect to copying data files for tests ?
>>
>> Yes, I think that may be it.
>>
>> Just run another test using "mvn clean" first, and that now causes the
>> error on Windows too.
>> Sorry, I thought I had done that previously.
>>
>> I propose to update the test case to replace the NPE with a more
>> useful message if possible.
>>
>> And I'll have a look at which plugin is causing the problem.
> 
> Problem solved.
> 
> It was not a plugin version issue. The problem was caused by the
> change in parent from 20->21 which added the following:
> 
> 
> 
>   
> ${basedir}
> META-INF
> 
>   NOTICE.txt
>   LICENSE.txt
> 
>   
> 
> 
> This replaced the default testResources definition in the super-Pom, which
> is:
> 
> 
>   
> src/test/resources
>   
> 
> 
> The parent POM also redefines :
> 
> 
>   
> ${basedir}
> META-INF
> 
>   NOTICE.txt
>   LICENSE.txt
> 
>   
> 
> 
> This has been there since version 3. This replaces:
> 
> 
>   
> src/main/resources
>   
> 
> 
> which is presumably why the MATH pom has to define its own 
> entry to include the localisation directory.
> 
> I think we have two ways forward here:
> 1) ensure that the parent resources and testResources entries include
> the default provided by the super-pom
> 2) find a different way to include the N&L files which does not
> require overriding the super-pom
>
> The second approach would be safer, as it would not rely on knowing
> what the super-pom does, but the first is trivial to do, so I'll start
> with that.

I'd like to find definitely a solution following 2. The maven-eclipse-plugin 
always produces invalid entries in the .classpath for those two resource 
definitions.

- Jörg


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

Re: [math] commit 1165155 results in error

[Dennis Hendriks]

Hi Sébastien,

thanks for the quick response/commit.

Dennis


Sébastien Brisard wrote:

Thanks Dennis for that! I forgot to commit the changes made to the
DecompositionSolver interface (which explains what it compiled
locally...).
Hope it is now fixed in rev. 1165188.
Sébastien

2011/9/5 Dennis Hendriks :

Hi all,

commit 1165155 removed method "solve(double[] b)" from class Solver in
org/apache/commons/math/linear/CholeskyDecompositionImpl.java, but it is
still in the DecompositionSolver interface that the Solver class implements,
thus resulting in an error, as the Solver class now no longer implements
that method. As a result, trunk no longer compiles on my machine...

Best regards,
Dennis

-
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] commit 1165155 results in error

[Sébastien Brisard]

Thanks Dennis for that! I forgot to commit the changes made to the
DecompositionSolver interface (which explains what it compiled
locally...).
Hope it is now fixed in rev. 1165188.
Sébastien

2011/9/5 Dennis Hendriks :
> Hi all,
>
> commit 1165155 removed method "solve(double[] b)" from class Solver in
> org/apache/commons/math/linear/CholeskyDecompositionImpl.java, but it is
> still in the DecompositionSolver interface that the Solver class implements,
> thus resulting in an error, as the Solver class now no longer implements
> that method. As a result, trunk no longer compiles on my machine...
>
> Best regards,
> Dennis
>
> -
> 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