[jira] [Commented] (MATH-445) Replace "package.html" by "package-info.java"

2011-10-01 Thread Gilles (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118946#comment-13118946
 ] 

Gilles commented on MATH-445:
-

Also: Isn't the script missing the generation of one space after the "*" 
character?

E.g.
{noformat}
/**
 *Decimal floating point library for Java
 *
{noformat}
should have been
{noformat}
/**
 * Decimal floating point library for Java
 *
{noformat}


> Replace "package.html" by "package-info.java"
> -
>
> Key: MATH-445
> URL: https://issues.apache.org/jira/browse/MATH-445
> Project: Commons Math
>  Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> The newest (and recommended, I think) way of documenting packages is through 
> "package-info.java" files.
> CM still uses "package.html" files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Reopened] (MATH-445) Replace "package.html" by "package-info.java"

2011-10-01 Thread Gilles (Reopened) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles reopened MATH-445:
-


Missing "package.html" now trigger a CheckStyle complaint.

I tried to replace the old rule with
{noformat}
  
{noformat}
(as documented [here|http://checkstyle.sourceforge.net/config_javadoc.html]), 
but this prevents the plugin to work correctly:
{noformat}
[INFO] Generating "Checkstyle" report.
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error during page generation

Embedded error: Error rendering Maven report: Failed during checkstyle 
configuration
Unable to instantiate JavadocPackageCheck
{noformat}
Maybe that the plugin version is too old (?).

> Replace "package.html" by "package-info.java"
> -
>
> Key: MATH-445
> URL: https://issues.apache.org/jira/browse/MATH-445
> Project: Commons Math
>  Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> The newest (and recommended, I think) way of documenting packages is through 
> "package-info.java" files.
> CM still uses "package.html" files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (MATH-445) Replace "package.html" by "package-info.java"

2011-10-01 Thread Phil Steitz (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118901#comment-13118901
 ] 

Phil Steitz commented on MATH-445:
--

Might be good to commit the script somewhere, like committers/tools for other 
projects that may want to do this. 

> Replace "package.html" by "package-info.java"
> -
>
> Key: MATH-445
> URL: https://issues.apache.org/jira/browse/MATH-445
> Project: Commons Math
>  Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> The newest (and recommended, I think) way of documenting packages is through 
> "package-info.java" files.
> CM still uses "package.html" files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-445) Replace "package.html" by "package-info.java"

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-445.


Resolution: Fixed

Fixed in subversion repository as of r1178067.

A shell+sed script has been created for this conversion, it can be found here: 
[http://people.apache.org/~luc/convert-to-package-info.sh]

> Replace "package.html" by "package-info.java"
> -
>
> Key: MATH-445
> URL: https://issues.apache.org/jira/browse/MATH-445
> Project: Commons Math
>  Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Fix For: 3.0
>
>
> The newest (and recommended, I think) way of documenting packages is through 
> "package-info.java" files.
> CM still uses "package.html" files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (CONFIGURATION-464) Download URL incorrect.

2011-10-01 Thread Oliver Heger (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-464.


   Resolution: Fixed
Fix Version/s: 1.8

Properties in pom.xml have been updated. The corrected download page has been 
re-deployed.

> Download URL incorrect.
> ---
>
> Key: CONFIGURATION-464
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-464
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 1.7
> Environment: N/A
>Reporter: Silas Jones
>Priority: Minor
> Fix For: 1.8
>
>
> This is a website issue, so apologies if I'm reporting in the wrong place.
> The link provided on the downloads page is 
> {mirror}/commons/configuration/binaries/commons-configuration-1.7.zip whereas 
> the actual filename has a '-bin' suffix: 
> {mirror}/commons/configuration/binaries/commons-configuration-1.7-bin.zip .  
> Can be worked around by amending the URL in the browser.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-284) Avoid ArrayStoreException

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-284.


Resolution: Fixed

Fixed in subversion repository as of r1178009.

Thanks for the report and the fix suggestion.

> Avoid ArrayStoreException
> -
>
> Key: MATH-284
> URL: https://issues.apache.org/jira/browse/MATH-284
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Klaus
>Priority: Minor
> Fix For: 3.0
>
> Attachments: math-284.patch
>
>
> Add a new method
> org.apache.commons.math,Field#getRuntimeClass():
> ...
> /**
>  * Returns the runtime class of the FieldElement. 
>  * 
>  * @return The {@code Class} object that represents the runtime
>  * class of this object.
>  */
> Class getRuntimeClass();
> ...
> and replace all occurrences of 
>   Array.newInstance(field.getZero().getClass(),)
> with
>   Array.newInstance(field.getRuntimeClass(),)
> to avoid the throwing of ArrayStoreException in the case you have a type 
> hierachy of Fields with a common interface
> and the array should have the interface type at runtime.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-457) Remove usage of "OptimizationException"

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-457.


Resolution: Fixed

Fixed in subversion repository as of r1178006.

> Remove usage of "OptimizationException"
> ---
>
> Key: MATH-457
> URL: https://issues.apache.org/jira/browse/MATH-457
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> {{OptimizationException}} (defined in package {{optimization}}) is still used 
> in classes of packages {{optimization.linear}} and {{optimization.fitting}}.
> Its occurrences must be removed, or replaced by the corresponding exception 
> from the {{exception}} package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-569) Add more operators to FieldElement

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-569.


Resolution: Won't Fix

Setting to Won't Fix as per comments above.

> Add more operators to FieldElement
> -
>
> Key: MATH-569
> URL: https://issues.apache.org/jira/browse/MATH-569
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Arne Plöse
>Priority: Minor
>
> it would be nice to have some additional operators in FieldElement i.e.
> T negate();
> T pow(T x);
> T sqrt();
> maybe the double variant i.e.
> T pow(double x);
> as well.
> This would be affect FieldVector | Matrix, BigReal, ... as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-571) make FieldVector generic

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-571.


Resolution: Won't Fix

Setting to Won't Fix as per comments above.

> make FieldVector generic
> 
>
> Key: MATH-571
> URL: https://issues.apache.org/jira/browse/MATH-571
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Arne Plöse
>Priority: Minor
> Fix For: 3.0
>
>
> make FieldVector generic, so one can extend i.e. ArrayVieldVector to 
> ArrayComplexVector an introduce new methoids (getReal())...
> if one has an equation complexvector.copy the original type 
> ArrayComplexVector is lost thus access to getReal() is not possible.
> solution:
> public class InheritationTest {
> public static interface FieldVector, R extends 
> FieldVector> {
> R copy();
> }
> public abstract static class ArrayFieldVectorExtendable FieldElement, R extends FieldVector> implements FieldVector, 
> Serializable {
> protected T[] data;
> @Override
> public R copy() {
> return createVector(data);
> }
> abstract protected R createVector(T[] data);
> }
> public static class ArrayFieldVector> extends 
> ArrayFieldVectorExtendable {
> @Override
> protected ArrayFieldVector createVector(T[] data) {
> ArrayFieldVector result = new ArrayFieldVector();
> result.data = data;
> return result;
> }
> }
> public static class ArrayComplexVector extends 
> ArrayFieldVectorExtendable {
> @Override
> protected ArrayComplexVector createVector(Complex[] data) {
> ArrayComplexVector result = new ArrayComplexVector();
> result.data = data;
> return result;
> }
> public double[] getReal() {
> return null;
> }
> public double[] getImaginary() {
> return null;
> }
> }
> public void test() {
> ArrayComplexVector v = new ArrayComplexVector();
> ArrayComplexVector v1 = v.copy();  // FiledVector type survives ...
> }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-487) Deprecate "ConvergenceException" in MATH_2_X and remove it in trunk

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-487.


   Resolution: Fixed
Fix Version/s: (was: 2.2)

Fixed in subversion repository as of r1177986.

The checked exception has been replaced by the unchecked one that lies in the 
exception package.

> Deprecate "ConvergenceException" in MATH_2_X and remove it in trunk
> ---
>
> Key: MATH-487
> URL: https://issues.apache.org/jira/browse/MATH-487
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The checked "ConvergenceException" should be deprecated.
> An example usage is in class {{ContinuedFraction}} (package {{util}}), at 
> line 153:
> {noformat}
>   if (scale <= 0) {  // Can't scale
> throw new 
> ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE, 
> x);
>   }
> {noformat}
> I think that it should be replaced by a more specific (and unchecked) 
> exception that reflects the exact low-level problem:
> {noformat}
>   if (scale <= 0) {  // Can't scale
> throw new NotStrictlypositiveException(scale);
>   }
> {noformat}
> A few lines below that, there is:
> {noformat}
>   if (infinite) {
> // Scaling failed
> throw new 
> ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE, 
> x);
>   }
> {noformat}
> So it seems that it is not necessary to throw an exception at the place where 
> the test on "scale" fails; instead we could have:
> {noformat}
>   infinite = true;
>   if (scale <= 0) {  // Can't scale
> break;
>   }
> {noformat}
> and let the check on "infinite" throw the exception:
> {noformat}
>   if (infinite) {
> // Scaling failed
> throw new 
> NotFiniteNumberException(LocalizedFormats.CONTINUED_FRACTION_DIVERGENCE,
>  Double.POSITIVE_INFINITY, x);
>   }
> {noformat}
> As shown in the above excerpt, we could also replace two {{enum}}:
> * CONTINUED_FRACTION_INFINITY_DIVERGENCE
> * CONTINUED_FRACTION_NAN_DIVERGENCE
> with a single one:
> * CONTINUED_FRACTION_DIVERGENCE
> because the other bit of information (infinity vs NaN) is already given by 
> the first parameter of the message.
> What do you think of these changes?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-424) FTPSClient.isConnected() does not return false after server shutdown

2011-10-01 Thread Bogdan Drozdowski (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118819#comment-13118819
 ] 

Bogdan Drozdowski commented on NET-424:
---

This has been discussed in one of the issues in Commons-Net (I can't find it 
now). The problem is that the state of the Socket doesn't change when the 
connection is closed. It stays open even though many things could already have 
happened. The only way you can check if the connection is still open is to use 
it. You can send commands, send NOOPs or anything else and if get an exception, 
you know that the connection is down. You can enable keepalives, if you want, 
but FTPClient or FTPSClient won't do anything for you, because it could break 
something.

> FTPSClient.isConnected() does not return false after server shutdown
> 
>
> Key: NET-424
> URL: https://issues.apache.org/jira/browse/NET-424
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.0.1
> Environment: Apache Lib:
> commons-net-3.0.1.jar
> Specification-Title: Commons Net
> Specification-Vendor: The Apache Software Foundation
> Specification-Version: 3.0.1
> Bundle-Version: 3.0.1
> Bundle-Name: Commons Net
> Java Version:
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> Platform: 
> Windows XP Professional x64 Edition Version 2003 Service Pack 2
>Reporter: Sean MacLellan
>
> 1. Using the FTPSClient
> 2. connect to a remote server
> 3. begin sending files
> 4. manually shut down the server
> 5. Code catches error for the file that is being sent.
> 6. Code tests to see if the connection is still good (using 
> FTPSClient.isConnected()), this returns true.
> 7. Try to send next file, all kinds of failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-381) inconsistency for methods names within StepInterpolator and StepInterpolatorWithJacobians

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-381.


Resolution: Fixed

Fixed in subversion repository as of r1176745

> inconsistency for methods names within StepInterpolator and 
> StepInterpolatorWithJacobians
> -
>
> Key: MATH-381
> URL: https://issues.apache.org/jira/browse/MATH-381
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Pascal Parraud
>Priority: Trivial
> Fix For: 3.0
>
>
> There is some inconstency in methods naming :
> getInterpolatedY and getInterpolatedYDot in StepInterpolatorWithJacobians do 
> the same as getInterpolatedState and getInterpolatedDerivatives in 
> StepInterpolator, so it will be better if they would have the same name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (MATH-380) Need to (re)initialize dYdY0 for multiple integrate with FirstOrderIntegratorWithJacobians

2011-10-01 Thread Luc Maisonobe (Resolved) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-380.


Resolution: Fixed

fixed in subversion repository as of r1176745.

> Need to (re)initialize dYdY0 for multiple integrate with 
> FirstOrderIntegratorWithJacobians
> --
>
> Key: MATH-380
> URL: https://issues.apache.org/jira/browse/MATH-380
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Pascal Parraud
>Assignee: Luc Maisonobe
>Priority: Minor
> Fix For: 3.0
>
>
> There is a lack in the method integrate of FirstOrderIntegratorWithJacobians. 
> The jacobian DYDY0 can't be initialized by the user, unlike DFDP with DF0DP.
> So, for several successive integrations, the matrix is reinitialized to 
> identity and that is not what we might want.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira