[jira] [Work logged] (LANG-1495) Add Overloading Methods To EnumUtils

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1495?focusedWorklogId=334775&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334775
 ]

ASF GitHub Bot logged work on LANG-1495:


Author: ASF GitHub Bot
Created on: 28/Oct/19 05:57
Start Date: 28/Oct/19 05:57
Worklog Time Spent: 10m 
  Work Description: vlcheong commented on pull request #475: LANG-1495 
Update EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#discussion_r339410238
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/EnumUtils.java
 ##
 @@ -119,13 +119,29 @@ public EnumUtils() {
  * @return the enum, null if not found
  */
 public static > E getEnum(final Class enumClass, 
final String enumName) {
+return getEnum(enumClass, enumName, null);
+}
+
+/**
+ * Gets the enum for the class, returning {@code defaultEnum} if not 
found.
+ *
+ * This method differs from {@link Enum#valueOf} in that it does not 
throw an exception
+ * for an invalid enum name.
+ *
+ * @param  the type of the enumeration
+ * @param enumClass   the class of the enum to query, not null
+ * @param enumNamethe enum name, null returns default enum
+ * @param defaultEnum the default enum
+ * @return the enum, default enum if not found
 
 Review comment:
   @Stzx, may I know what version number should I put ?
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334775)
Time Spent: 40m  (was: 0.5h)

> Add Overloading Methods To EnumUtils
> 
>
> Key: LANG-1495
> URL: https://issues.apache.org/jira/browse/LANG-1495
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Cheong Voon Leong
>Priority: Trivial
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I would like to add 2 overloading methods to EnumUtils, getEnum and 
> getEnumIgnoreCase.
> Instead of returning null, if not found. In my opinion I think allowing user 
> to set a default result is a better approach or return an Optional.
>   
> {noformat}
> public static > E getEnum(final Class enumClass, final 
> String enumName) {
>  return getEnum(enumClass, enumName, null);
>  }
> public static > E getEnum(final Class enumClass, final 
> String enumName, E defaultEnum) {
>  if (enumName == null) {
>  return defaultEnum;
>  }
>  try {
>  return Enum.valueOf(enumClass, enumName);
>  } catch (final IllegalArgumentException ex) {
>  return defaultEnum;
>  }
>  }
> {noformat}
>   
>  
> {code:java}
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName) {
>  return getEnumIgnoreCase(enumClass, enumName, null);
>  }
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName, E defaultEnum) {
>  if (enumName == null || !enumClass.isEnum()) {
>  return defaultEnum;
>  }
>  for (final E each : enumClass.getEnumConstants()) {
>  if (each.name().equalsIgnoreCase(enumName)) {
>  return each;
>  }
>  }
>  return defaultEnum;
>  }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] vlcheong commented on a change in pull request #475: LANG-1495 Update EnumUtils.java

[GitBox]

vlcheong commented on a change in pull request #475: LANG-1495 Update 
EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#discussion_r339410238
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/EnumUtils.java
 ##
 @@ -119,13 +119,29 @@ public EnumUtils() {
  * @return the enum, null if not found
  */
 public static > E getEnum(final Class enumClass, 
final String enumName) {
+return getEnum(enumClass, enumName, null);
+}
+
+/**
+ * Gets the enum for the class, returning {@code defaultEnum} if not 
found.
+ *
+ * This method differs from {@link Enum#valueOf} in that it does not 
throw an exception
+ * for an invalid enum name.
+ *
+ * @param  the type of the enumeration
+ * @param enumClass   the class of the enum to query, not null
+ * @param enumNamethe enum name, null returns default enum
+ * @param defaultEnum the default enum
+ * @return the enum, default enum if not found
 
 Review comment:
   @Stzx, may I know what version number should I put ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Work logged] (LANG-1495) Add Overloading Methods To EnumUtils

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1495?focusedWorklogId=334769&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334769
 ]

ASF GitHub Bot logged work on LANG-1495:


Author: ASF GitHub Bot
Created on: 28/Oct/19 05:35
Start Date: 28/Oct/19 05:35
Worklog Time Spent: 10m 
  Work Description: Stzx commented on pull request #475: LANG-1495 Update 
EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#discussion_r339407030
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/EnumUtils.java
 ##
 @@ -119,13 +119,29 @@ public EnumUtils() {
  * @return the enum, null if not found
  */
 public static > E getEnum(final Class enumClass, 
final String enumName) {
+return getEnum(enumClass, enumName, null);
+}
+
+/**
+ * Gets the enum for the class, returning {@code defaultEnum} if not 
found.
+ *
+ * This method differs from {@link Enum#valueOf} in that it does not 
throw an exception
+ * for an invalid enum name.
+ *
+ * @param  the type of the enumeration
+ * @param enumClass   the class of the enum to query, not null
+ * @param enumNamethe enum name, null returns default enum
+ * @param defaultEnum the default enum
+ * @return the enum, default enum if not found
 
 Review comment:
   Provide a `@since` tag for the new method.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334769)
Time Spent: 0.5h  (was: 20m)

> Add Overloading Methods To EnumUtils
> 
>
> Key: LANG-1495
> URL: https://issues.apache.org/jira/browse/LANG-1495
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Cheong Voon Leong
>Priority: Trivial
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I would like to add 2 overloading methods to EnumUtils, getEnum and 
> getEnumIgnoreCase.
> Instead of returning null, if not found. In my opinion I think allowing user 
> to set a default result is a better approach or return an Optional.
>   
> {noformat}
> public static > E getEnum(final Class enumClass, final 
> String enumName) {
>  return getEnum(enumClass, enumName, null);
>  }
> public static > E getEnum(final Class enumClass, final 
> String enumName, E defaultEnum) {
>  if (enumName == null) {
>  return defaultEnum;
>  }
>  try {
>  return Enum.valueOf(enumClass, enumName);
>  } catch (final IllegalArgumentException ex) {
>  return defaultEnum;
>  }
>  }
> {noformat}
>   
>  
> {code:java}
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName) {
>  return getEnumIgnoreCase(enumClass, enumName, null);
>  }
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName, E defaultEnum) {
>  if (enumName == null || !enumClass.isEnum()) {
>  return defaultEnum;
>  }
>  for (final E each : enumClass.getEnumConstants()) {
>  if (each.name().equalsIgnoreCase(enumName)) {
>  return each;
>  }
>  }
>  return defaultEnum;
>  }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] Stzx commented on a change in pull request #475: LANG-1495 Update EnumUtils.java

[GitBox]

Stzx commented on a change in pull request #475: LANG-1495 Update EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#discussion_r339407030
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/EnumUtils.java
 ##
 @@ -119,13 +119,29 @@ public EnumUtils() {
  * @return the enum, null if not found
  */
 public static > E getEnum(final Class enumClass, 
final String enumName) {
+return getEnum(enumClass, enumName, null);
+}
+
+/**
+ * Gets the enum for the class, returning {@code defaultEnum} if not 
found.
+ *
+ * This method differs from {@link Enum#valueOf} in that it does not 
throw an exception
+ * for an invalid enum name.
+ *
+ * @param  the type of the enumeration
+ * @param enumClass   the class of the enum to query, not null
+ * @param enumNamethe enum name, null returns default enum
+ * @param defaultEnum the default enum
+ * @return the enum, default enum if not found
 
 Review comment:
   Provide a `@since` tag for the new method.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-vfs] woonsan commented on issue #74: VFS-687: adding http5 and http5s providers

[GitBox]

woonsan commented on issue #74: VFS-687: adding http5 and http5s providers
URL: https://github.com/apache/commons-vfs/pull/74#issuecomment-546783902
 
 
   I have assumed that Commons VFS would implement http/s providers using HC 
libraries. Unless we want to use other libraries than HC, http3, http4 and 
http5 do not seem confusing to me. At the moment, 'http3' is aliased as 'http', 
but we may deprecate that and give 'http' alias to http4 someday, and so forth.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-vfs] woonsan commented on a change in pull request #74: VFS-687: adding http5 and http5s providers

[GitBox]

woonsan commented on a change in pull request #74: VFS-687: adding http5 and 
http5s providers
URL: https://github.com/apache/commons-vfs/pull/74#discussion_r339396733
 
 

 ##
 File path: 
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/http5/Http5FileContentInfoFactory.java
 ##
 @@ -0,0 +1,63 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.vfs2.provider.http5;
+
+import java.io.IOException;
+
+import org.apache.commons.vfs2.FileContent;
+import org.apache.commons.vfs2.FileContentInfo;
+import org.apache.commons.vfs2.FileContentInfoFactory;
+import org.apache.commons.vfs2.FileSystemException;
+import org.apache.commons.vfs2.impl.DefaultFileContentInfo;
+import org.apache.commons.vfs2.util.FileObjectUtils;
+import org.apache.hc.core5.http.ContentType;
+import org.apache.hc.core5.http.Header;
+import org.apache.hc.core5.http.HttpHeaders;
+import org.apache.hc.core5.http.HttpResponse;
+
+/**
+ * Creates FileContentInfoFactory instances for http5 provider.
+ */
 
 Review comment:
   Done. Thanks!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-lang] coveralls commented on issue #475: LANG-1495 Update EnumUtils.java

[GitBox]

coveralls commented on issue #475: LANG-1495 Update EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#issuecomment-546774618
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26581425/badge)](https://coveralls.io/builds/26581425)
   
   Coverage increased (+0.0006%) to 95.364% when pulling 
**b8339538e9845496d4959ba640efbf988ea328d4 on vlcheong:master** into 
**54afdb303535a62fe00e49e3ad5100ca9fc55d1e on apache:master**.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Work logged] (LANG-1495) Add Overloading Methods To EnumUtils

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1495?focusedWorklogId=334728&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334728
 ]

ASF GitHub Bot logged work on LANG-1495:


Author: ASF GitHub Bot
Created on: 28/Oct/19 03:11
Start Date: 28/Oct/19 03:11
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #475: LANG-1495 Update 
EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475#issuecomment-546774618
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26581425/badge)](https://coveralls.io/builds/26581425)
   
   Coverage increased (+0.0006%) to 95.364% when pulling 
**b8339538e9845496d4959ba640efbf988ea328d4 on vlcheong:master** into 
**54afdb303535a62fe00e49e3ad5100ca9fc55d1e on apache:master**.
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334728)
Time Spent: 20m  (was: 10m)

> Add Overloading Methods To EnumUtils
> 
>
> Key: LANG-1495
> URL: https://issues.apache.org/jira/browse/LANG-1495
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Cheong Voon Leong
>Priority: Trivial
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I would like to add 2 overloading methods to EnumUtils, getEnum and 
> getEnumIgnoreCase.
> Instead of returning null, if not found. In my opinion I think allowing user 
> to set a default result is a better approach or return an Optional.
>   
> {noformat}
> public static > E getEnum(final Class enumClass, final 
> String enumName) {
>  return getEnum(enumClass, enumName, null);
>  }
> public static > E getEnum(final Class enumClass, final 
> String enumName, E defaultEnum) {
>  if (enumName == null) {
>  return defaultEnum;
>  }
>  try {
>  return Enum.valueOf(enumClass, enumName);
>  } catch (final IllegalArgumentException ex) {
>  return defaultEnum;
>  }
>  }
> {noformat}
>   
>  
> {code:java}
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName) {
>  return getEnumIgnoreCase(enumClass, enumName, null);
>  }
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName, E defaultEnum) {
>  if (enumName == null || !enumClass.isEnum()) {
>  return defaultEnum;
>  }
>  for (final E each : enumClass.getEnumConstants()) {
>  if (each.name().equalsIgnoreCase(enumName)) {
>  return each;
>  }
>  }
>  return defaultEnum;
>  }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (LANG-1495) Add Overloading Methods To EnumUtils

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1495?focusedWorklogId=334719&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334719
 ]

ASF GitHub Bot logged work on LANG-1495:


Author: ASF GitHub Bot
Created on: 28/Oct/19 02:58
Start Date: 28/Oct/19 02:58
Worklog Time Spent: 10m 
  Work Description: vlcheong commented on pull request #475: LANG-1495 
Update EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475
 
 
   Add Overloading Methods getEnum and getEnumIgnoreCase To EnumUtils
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334719)
Remaining Estimate: 0h
Time Spent: 10m

> Add Overloading Methods To EnumUtils
> 
>
> Key: LANG-1495
> URL: https://issues.apache.org/jira/browse/LANG-1495
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Cheong Voon Leong
>Priority: Trivial
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I would like to add 2 overloading methods to EnumUtils, getEnum and 
> getEnumIgnoreCase.
> Instead of returning null, if not found. In my opinion I think allowing user 
> to set a default result is a better approach or return an Optional.
>   
> {noformat}
> public static > E getEnum(final Class enumClass, final 
> String enumName) {
>  return getEnum(enumClass, enumName, null);
>  }
> public static > E getEnum(final Class enumClass, final 
> String enumName, E defaultEnum) {
>  if (enumName == null) {
>  return defaultEnum;
>  }
>  try {
>  return Enum.valueOf(enumClass, enumName);
>  } catch (final IllegalArgumentException ex) {
>  return defaultEnum;
>  }
>  }
> {noformat}
>   
>  
> {code:java}
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName) {
>  return getEnumIgnoreCase(enumClass, enumName, null);
>  }
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName, E defaultEnum) {
>  if (enumName == null || !enumClass.isEnum()) {
>  return defaultEnum;
>  }
>  for (final E each : enumClass.getEnumConstants()) {
>  if (each.name().equalsIgnoreCase(enumName)) {
>  return each;
>  }
>  }
>  return defaultEnum;
>  }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] vlcheong opened a new pull request #475: LANG-1495 Update EnumUtils.java

[GitBox]

vlcheong opened a new pull request #475: LANG-1495 Update EnumUtils.java
URL: https://github.com/apache/commons-lang/pull/475
 
 
   Add Overloading Methods getEnum and getEnumIgnoreCase To EnumUtils


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (MATH-1501) Alternative implementations of "FieldLUDecomposition"

[Gilles Sadowski (Jira)]

Gilles Sadowski created MATH-1501:
-

 Summary: Alternative implementations of "FieldLUDecomposition"
 Key: MATH-1501
 URL: https://issues.apache.org/jira/browse/MATH-1501
 Project: Commons Math
  Issue Type: Bug
Reporter: Gilles Sadowski


Replace usage of 
[o.a.c.m.linear.FieldLUDecomposition|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/linear/FieldLUDecomposition.java]
 with 
[o.a.c.m.field.linalg.FieldLUDecomposition|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/field/linalg/FieldLUDecomposition.java].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MATH-1499) Implement (basic) matrix functionality

[Gilles Sadowski (Jira)]

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

Gilles Sadowski resolved MATH-1499.
---
Resolution: Implemented

commit 128523112bdbad85b6b5c925004c0e975be5d553

> Implement (basic) matrix functionality
> --
>
> Key: MATH-1499
> URL: https://issues.apache.org/jira/browse/MATH-1499
> Project: Commons Math
>  Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 4.0
>
>
> Matrix class whose entries are elements of a 
> [field|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-field/src/main/java/org/apache/commons/numbers/field].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MATH-1500) Implement "FieldLUDecomposition"

[Gilles Sadowski (Jira)]

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

Gilles Sadowski resolved MATH-1500.
---
Resolution: Implemented

commit ec77f54bef7e60de920307bd75ce44a2fa104670

> Implement "FieldLUDecomposition"
> 
>
> Key: MATH-1500
> URL: https://issues.apache.org/jira/browse/MATH-1500
> Project: Commons Math
>  Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
>  Labels: api
> Fix For: 4.0
>
>
> Implement the algorithm using the matrix functionality provided in MATH-1499.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (COMPRESS-477) Support for splitted zip files

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=334674&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334674
 ]

ASF GitHub Bot logged work on COMPRESS-477:
---

Author: ASF GitHub Bot
Created on: 28/Oct/19 01:35
Start Date: 28/Oct/19 01:35
Worklog Time Spent: 10m 
  Work Description: PeterAlfreadLee commented on issue #84: COMPRESS-477 
Add support for extracting splitted zip files
URL: https://github.com/apache/commons-compress/pull/84#issuecomment-546759238
 
 
   @bodewig Thank you. Please take your time.
   
   > We could either allow people using ZipArchiveInputStream to signal it 
should skip the marker or provide a "collecting stream" that skipped the first 
four bytes if necessary.
   
   I prefer with the previous implemention by skipping the marker. I tested 
with the the second implemention of providing a "collecting stream" that 
skipped the first four bytes if necessary, and it doesn't work well and got 
garbled content when dealing with files that is located in 2 split segments. I 
don't know why it's like this, but I believe it's the `Inflater` in JVM has 
taken the marker into consideration.
   
   I will push the part of `ZipArchiveInputStream` and corresponding testcases 
in my branch today.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334674)
Time Spent: 1h  (was: 50m)

> Support for splitted zip files
> --
>
> Key: COMPRESS-477
> URL: https://issues.apache.org/jira/browse/COMPRESS-477
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Affects Versions: 1.18
>Reporter: Luís Filipe Nassif
>Priority: Major
>  Labels: zip
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> It would be very useful to support splitted zip files. I've read 
> [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood 
> that simply concatenating the segments and removing the split signature 
> 0x08074b50 from first segment would be sufficient, but it is not that simple 
> because compress fails with exception below:
> {code}
> Caused by: java.util.zip.ZipException: archive's ZIP64 end of central 
> directory locator is corrupt.
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) 
> ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) 
> ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) 
> ~[commons-compress-1.18.jar:1.18]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-compress] PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files

[GitBox]

PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting 
splitted zip files
URL: https://github.com/apache/commons-compress/pull/84#issuecomment-546759238
 
 
   @bodewig Thank you. Please take your time.
   
   > We could either allow people using ZipArchiveInputStream to signal it 
should skip the marker or provide a "collecting stream" that skipped the first 
four bytes if necessary.
   
   I prefer with the previous implemention by skipping the marker. I tested 
with the the second implemention of providing a "collecting stream" that 
skipped the first four bytes if necessary, and it doesn't work well and got 
garbled content when dealing with files that is located in 2 split segments. I 
don't know why it's like this, but I believe it's the `Inflater` in JVM has 
taken the marker into consideration.
   
   I will push the part of `ZipArchiveInputStream` and corresponding testcases 
in my branch today.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (LANG-1495) Add Overloading Methods To EnumUtils

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on LANG-1495:
---

You should fork the GitHub repository, create a branch from the master branch 
for your code, and then create a pull request on GitHub.

> Add Overloading Methods To EnumUtils
> 
>
> Key: LANG-1495
> URL: https://issues.apache.org/jira/browse/LANG-1495
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Cheong Voon Leong
>Priority: Trivial
>
> I would like to add 2 overloading methods to EnumUtils, getEnum and 
> getEnumIgnoreCase.
> Instead of returning null, if not found. In my opinion I think allowing user 
> to set a default result is a better approach or return an Optional.
>   
> {noformat}
> public static > E getEnum(final Class enumClass, final 
> String enumName) {
>  return getEnum(enumClass, enumName, null);
>  }
> public static > E getEnum(final Class enumClass, final 
> String enumName, E defaultEnum) {
>  if (enumName == null) {
>  return defaultEnum;
>  }
>  try {
>  return Enum.valueOf(enumClass, enumName);
>  } catch (final IllegalArgumentException ex) {
>  return defaultEnum;
>  }
>  }
> {noformat}
>   
>  
> {code:java}
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName) {
>  return getEnumIgnoreCase(enumClass, enumName, null);
>  }
> public static > E getEnumIgnoreCase(final Class 
> enumClass, final String enumName, E defaultEnum) {
>  if (enumName == null || !enumClass.isEnum()) {
>  return defaultEnum;
>  }
>  for (final E each : enumClass.getEnumConstants()) {
>  if (each.name().equalsIgnoreCase(enumName)) {
>  return each;
>  }
>  }
>  return defaultEnum;
>  }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-vfs] michael-o commented on issue #74: VFS-687: adding http5 and http5s providers

[GitBox]

michael-o commented on issue #74: VFS-687: adding http5 and http5s providers
URL: https://github.com/apache/commons-vfs/pull/74#issuecomment-546722014
 
 
   Yes, people could simply confuse with HTTP, version 4 or 5.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-compress] garydgregory commented on issue #82: Made some variable names more consistent with the other parts.

[GitBox]

garydgregory commented on issue #82: Made some variable names more consistent 
with the other parts.
URL: https://github.com/apache/commons-compress/pull/82#issuecomment-546721796
 
 
   I don't care that the changes come from a tool, I am just looking to see if 
the code is easier to read, which admittedly is subjective of course. But yeah, 
I can bring in the PR at some point. But if this is just a PR where the poster 
does not come back and update the code or comment, then it will go nowhere.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-vfs] garydgregory commented on issue #74: VFS-687: adding http5 and http5s providers

[GitBox]

garydgregory commented on issue #74: VFS-687: adding http5 and http5s providers
URL: https://github.com/apache/commons-vfs/pull/74#issuecomment-546720319
 
 
   Would you rename version 4 to hc4 as well?
   
   On Sun, Oct 27, 2019, 06:50 Michael Osipov  wrote:
   
   > The name is confusing. Shouldn't this be hc5 and hc5s at most?
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (BCEL-331) Enforce contribution guidelines when committing

[Alex Herbert (Jira)]

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

Alex Herbert commented on BCEL-331:
---

The problems of line endings can be solved using 
[.gitattributes|https://git-scm.com/docs/gitattributes] with the {{text}} key.

When I run the following on BCEL (these commands are provided on the Git 
documentation referenced above):

{noformat}
$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status# Show files that will be normalized
{noformat}

It identifies the following files for line ending changes:

{noformat}
modified:   .travis.yml
modified:   CONTRIBUTING.md
modified:   NOTICE.txt
modified:   README.md
modified:   docs/eps/classloader.fig
modified:   docs/verifier/V_API_SD.eps
modified:   pom.xml
modified:   src/changes/changes.xml
modified:   src/conf/checkstyle.xml
modified:   
src/main/java/org/apache/bcel/classfile/DescendingVisitor.java
modified:   src/main/java/org/apache/bcel/classfile/FieldOrMethod.java
modified:   src/main/java/org/apache/bcel/generic/INVOKEDYNAMIC.java
modified:   src/main/java/org/apache/bcel/generic/InstructionHandle.java
modified:   src/main/java/org/apache/bcel/util/ModularRuntimeImage.java
modified:   src/site/xdoc/download_bcel.xml
modified:   src/site/xdoc/index.xml
modified:   src/site/xdoc/issue-tracking.xml
modified:   src/site/xdoc/mail-lists.xml
modified:   src/test/java/org/apache/bcel/HandleTestCase.java
modified:   src/test/java/org/apache/bcel/data/PLSETestClass2.java
modified:   src/test/java/org/apache/bcel/util/ClassPathTestCase.java
modified:   
src/test/java/org/apache/bcel/util/ModularRuntimeImageTestCase.java
{noformat}

So there are a few offending java source files and a few other in there too. I 
do not think that any files identified are not text files. The EPS files are 
human readable and editable.


> Enforce contribution guidelines when committing
> ---
>
> Key: BCEL-331
> URL: https://issues.apache.org/jira/browse/BCEL-331
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.4.1
>Reporter: Michael Ernst
>Priority: Major
>
> Two of the contribution guidelines at 
> https://github.com/apache/commons-bcel#contributing are:
> * Respect the code style.
>  * Create minimal diffs - disable on save actions like reformat source code 
> or organize imports.
> These guidelines are not being respected in the BCEL codebase.
> As an example, conisder this commit:
> https://github.com/apache/commons-bcel/commit/d7292a3d9f2939f785ec74057d255e5df95846bf
> The commit ought to be just a few lines long, but instead it changed every 
> line in two files by changing the line endings from Unix style to DOS style.
> This makes the commit history not helpful for understanding the changes, and 
> it is extremely disruptive for people who are maintaining forks.
> This is not an isolated incident -- there have been many other commits with 
> the same problem.
> Could you please put a mechanism in place to encourage developers to follow 
> the guidelines? Developers should set up their editor to maintain line 
> endings, but that is not currently happening.
> Here are some suggestions:
>  * add a pre-commit hook that prevents commits that change line endings
>  * add a pre-commit hook that enforces a uniform line ending style (I don't 
> care whether it is Unix or DOS, so long as no future commits change it).
>  * lock the master branch and require code reviews, to catch problems when a 
> developer carelessly changes line endings
> Maybe you have other ideas for enforcing the guidelines; anything that 
> prevents these disruptive commits from polluting the history would be fine 
> with me.
> Thanks!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-compress] bodewig commented on issue #82: Made some variable names more consistent with the other parts.

[GitBox]

bodewig commented on issue #82: Made some variable names more consistent with 
the other parts.
URL: https://github.com/apache/commons-compress/pull/82#issuecomment-546704982
 
 
   I am on the fence with this PR.
   
   Personally I don't see any benefit in consistent naming of local variables 
as long as the local variables have names that can be understood. To me a local 
variable named `length` is in no way clearer than one called `len`.
   
   We will never get a consistency at the level your tool is striving for on a 
project that relies on numerous volunteer contributors. I don't see myself 
frustrating contributors by asking them to rename their local variables on 
patches.
   
   @garydgregory if you see value in this and want to merge the PR after the 
changes you've requested have been made I won't stand in the way but I'll 
otherwise ignore it myself.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MATH-1448) Make RealFieldElement implement Number

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on MATH-1448:
---

bq.  I probably won't use numbers

Do you mean you have re-implemented everything that is now in "Commons Numbers"?

bq. better Commons math implementation

Design improvements, at least, mostly come from externalizing the low-level 
classes to "Commons Numbers".
Unfortunately there is a lot of work just in rewriting the {{Field}}-related 
algorithms... :-(

> Make RealFieldElement implement Number
> --
>
> Key: MATH-1448
> URL: https://issues.apache.org/jira/browse/MATH-1448
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Alexander Nozik
>Priority: Trivial
>
> RealFieldElement in some cases could be used as a substitute for a generic 
> `Number` and it quite easy to make it implement `Number` interface. Perhaps 
> it would be better to inherit it form number to allow universal treatment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MATH-1500) Implement "FieldLUDecomposition"

[Gilles Sadowski (Jira)]

Gilles Sadowski created MATH-1500:
-

 Summary: Implement "FieldLUDecomposition"
 Key: MATH-1500
 URL: https://issues.apache.org/jira/browse/MATH-1500
 Project: Commons Math
  Issue Type: Sub-task
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
 Fix For: 4.0


Implement the algorithm using the matrix functionality provided in MATH-1499.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (JEXL-307) Variable redeclaration option

[Henri Biestro (Jira)]

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

Henri Biestro edited comment on JEXL-307 at 10/27/19 2:03 PM:
--

Changeset: d15901734478efeac605d3dc55c4b25a479c28d4
 Author: henrib 
 Date: 2019-10-27 13:59
 Message: JEXL-307: added lexical and lexical shade option;
 JEXL-307: added lexical feature, controlling var redefinition at parsing time;
 JEXL-307: refactored option (JexlOption) and added feature to deal with 
lexical scope;
 JEXL-307: refactored test code to use new option classes;
 JEXL-307: added lexical scope and frame handling interpreting scripts, 
lambdas, for-loops;
 JEXL-314: changed JexlArithmetic/Interpreter to handle NullOperand exception 
when needed

 

Changes not visible through GitHub (yet): 
https://issues.apache.org/jira/browse/INFRA-19344


was (Author: henrib):
Changeset: d15901734478efeac605d3dc55c4b25a479c28d4
Author:henrib 
Date:  2019-10-27 13:59
Message:   JEXL-307: added lexical and lexical shade option;
JEXL-307: added lexical feature, controlling var redefinition at parsing time;
JEXL-307: refactored option (JexlOption) and added feature to deal with lexical 
scope;
JEXL-307: refactored test code to use new option classes;
JEXL-307: added lexical scope and frame handling interpreting scripts, lambdas, 
for-loops;
JEXL-314: changed JexlArithmetic/Interpreter to handle NullOperand exception 
when needed

> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during 
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed 
> variables. Checking for already defined variable is a common feature of many 
> languages. This feature can be implemented in JEXL as an additional option of 
> JexlFeatures class, enabled by default, thus allowing compatibility with 
> existing code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1448) Make RealFieldElement implement Number

[Alexander Nozik (Jira)]

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

Alexander Nozik commented on MATH-1448:
---

Yes, basically, the better Commons math implementation, the better resulting 
wrapper library will work. So I am quite interested in quality of commons 
libraries. The problem is that it is hard to contribute to both projects 
simultaneously, so I am focused on kotlin side. I probably won't use numbers 
since it is much easier to do them in kotlin-multiplatform using external field 
operations instead of Java class inheritance (and I have already done most of 
it). On the other hand, I will definitely use rng and matrix operations.

> Make RealFieldElement implement Number
> --
>
> Key: MATH-1448
> URL: https://issues.apache.org/jira/browse/MATH-1448
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Alexander Nozik
>Priority: Trivial
>
> RealFieldElement in some cases could be used as a substitute for a generic 
> `Number` and it quite easy to make it implement `Number` interface. Perhaps 
> it would be better to inherit it form number to allow universal treatment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JEXL-314) Comparison NULL values of variables NAME1.NAME2

[Henri Biestro (Jira)]

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

Henri Biestro resolved JEXL-314.

Resolution: Fixed

Changeset: fdda2e292fe7d5d558c6cfa00e56f93367f21764
Author:henrib 
Date:  2019-10-27 14:24
Message:   
JEXL-314: updated test, attempting triggering gitbox/github sync

> Comparison NULL values of variables NAME1.NAME2
> ---
>
> Key: JEXL-314
> URL: https://issues.apache.org/jira/browse/JEXL-314
> Project: Commons JEXL
>  Issue Type: Wish
>Affects Versions: 3.1
>Reporter: Osy
>Priority: Minor
>
> I am adding to my context this NULL variable :
>  
> {code:java}
> jc.set("TVALOGAR.PEPITO", null);
> jexlExp = "TVALOGAR.PEPITO==null?'SIMON':'SIMONAZO'";
> {code}
> After evaluate the jexlExp I get the error:
> *Exception in thread "main" org.apache.commons.jexl3.JexlException$Variable: 
> com.expre.test.TestJexl.main@1:1 null value variable TVALOGAR.PEPITO*
>  
> This is not happening If I am using only a simple variable name:
> {code:java}
> jc.set("TVALOGAR", null);
> jexlExp = "TVALOGAR==null?'SIMON':'SIMONAZO'";
> {code}
> *Expression Value :SIMON*
> Is this the expected behaviour? 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1448) Make RealFieldElement implement Number

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on MATH-1448:
---

bq. I use Commons math/numbers/rng only as a back-end implementation

IIUC, that means that implementing and improving things on the "Commons" side 
would benefit both sets of users (?).

bq.  it is not possible to back-port the most advanced design solutions from 
kotlin in java. 

But, still, the "back-end" could be shared, no?


> Make RealFieldElement implement Number
> --
>
> Key: MATH-1448
> URL: https://issues.apache.org/jira/browse/MATH-1448
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Alexander Nozik
>Priority: Trivial
>
> RealFieldElement in some cases could be used as a substitute for a generic 
> `Number` and it quite easy to make it implement `Number` interface. Perhaps 
> it would be better to inherit it form number to allow universal treatment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JEXL-315) JxltEngine literal string strings ending in \ $ or # throw JxltEngine$Exception

[Henri Biestro (Jira)]

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

Henri Biestro resolved JEXL-315.

Resolution: Fixed

Changeset: c46fb0d5084c17b648088b36cfdf648f67328d5c
Author:henrib 
Date:  2019-10-27 13:37
Message:   JEXL-315: added handling of delimiters at end of lines

> JxltEngine literal string strings ending in \ $ or # throw 
> JxltEngine$Exception
> ---
>
> Key: JEXL-315
> URL: https://issues.apache.org/jira/browse/JEXL-315
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Mike Bartlett
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> When parsing literal strings with the JxltEngine, if the string ends with \ $ 
> or # a JxltEngine$Exception is thrown. Escaping the ending character works, 
> but seems an unnecessary burden on the user.
> Example:
> JxltEngine jxltEngine = (new JexlBuilder()).create().createJxltEngine();
>  Expression exp = jxltEngine.createExpression("Testing$");
>  Object value = exp.evaluate(new MapContext());
> Stack Trace:
> org.apache.commons.jexl3.JxltEngine$Exception: 
> com.openmarket.workflow.el.ElEngineTest.testBug@40 failed to parse 
> 'Testing$'org.apache.commons.jexl3.JxltEngine$Exception: 
> com.openmarket.workflow.el.ElEngineTest.testBug@40 failed to parse 'Testing$' 
> at 
> org.apache.commons.jexl3.internal.TemplateEngine.createExpression(TemplateEngine.java:668)
>  at org.apache.commons.jexl3.JxltEngine.createExpression(JxltEngine.java:217) 
> at com.openmarket.workflow.el.ElEngineTest.testBug(ElEngineTest.java:40) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at 
> org.junit.runners.ParentRunner.run(ParentRunner.java:363) at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>  at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>  at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>  at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>  at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>  at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)Caused
>  by: org.apache.commons.jexl3.JxltEngine$Exception: 
> com.openmarket.workflow.el.ElEngineTest.testBug@40 malformed expression: 
> Testing$ at 
> org.apache.commons.jexl3.internal.TemplateEngine.parseExpression(TemplateEngine.java:886)
>  at 
> org.apache.commons.jexl3.internal.TemplateEngine.createExpression(TemplateEngine.java:664)
>  ... 25 more
>  
> Simple Fix in the code:
> org.apache.commons.jexl3.internal.TemplateEngine
> In method:
> {quote}{{TemplateExpression parseExpression(JexlInfo info, String expr, Scope 
> scope) { // CSOFF: MethodLength}}
>  
> {{for (int column = 0; column < size; ++column) {}}
> {{  ...}}
> {{}}}
> {{// Add this code at the end of the for loop to h}}{{andle strings ending in 
> \, # or $}}
> {{ if (state == ParseState.ESCAPE) {}}
> {{    strb.append('\\');}}
> {{    state = ParseState.CONST;}}
> {{ } else if (state == ParseState.DEFERRED0) {}}
> {{    strb.append(deferredChar);}}
> {{    state = ParseState.CONST;}}
> {{ } else if (state == ParseState.IMMEDIATE0) {}}
> {{    strb.append(immediateChar);}}
> {{    state = ParseState.CONST;}}
> {{ }}}
> {{...}}
> {quote}
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JEXL-307) Variable redeclaration option

[Henri Biestro (Jira)]

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

Henri Biestro resolved JEXL-307.

Resolution: Fixed

Changeset: d15901734478efeac605d3dc55c4b25a479c28d4
Author:henrib 
Date:  2019-10-27 13:59
Message:   JEXL-307: added lexical and lexical shade option;
JEXL-307: added lexical feature, controlling var redefinition at parsing time;
JEXL-307: refactored option (JexlOption) and added feature to deal with lexical 
scope;
JEXL-307: refactored test code to use new option classes;
JEXL-307: added lexical scope and frame handling interpreting scripts, lambdas, 
for-loops;
JEXL-314: changed JexlArithmetic/Interpreter to handle NullOperand exception 
when needed

> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during 
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed 
> variables. Checking for already defined variable is a common feature of many 
> languages. This feature can be implemented in JEXL as an additional option of 
> JexlFeatures class, enabled by default, thus allowing compatibility with 
> existing code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1448) Make RealFieldElement implement Number

[Alexander Nozik (Jira)]

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

Alexander Nozik commented on MATH-1448:
---

Thanks, I've completely moved to Kotlin some time ago, so I use Commons 
math/numbers/rng only as a back-end implementation. Now I develop a numeric 
library for kotlin which uses a lot of design ideas from commons-math (they 
look much better in kotlin because of possibility of context-oriented design). 
Sadly, it is not possible to back-port the most advanced design solutions from 
kotlin in java. 

> Make RealFieldElement implement Number
> --
>
> Key: MATH-1448
> URL: https://issues.apache.org/jira/browse/MATH-1448
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Alexander Nozik
>Priority: Trivial
>
> RealFieldElement in some cases could be used as a substitute for a generic 
> `Number` and it quite easy to make it implement `Number` interface. Perhaps 
> it would be better to inherit it form number to allow universal treatment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MATH-1499) Implement (basic) matrix functionality

[Gilles Sadowski (Jira)]

Gilles Sadowski created MATH-1499:
-

 Summary: Implement (basic) matrix functionality
 Key: MATH-1499
 URL: https://issues.apache.org/jira/browse/MATH-1499
 Project: Commons Math
  Issue Type: Sub-task
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
 Fix For: 4.0


Matrix class whose entries are elements of a 
[field|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-field/src/main/java/org/apache/commons/numbers/field].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1448) Make RealFieldElement implement Number

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on MATH-1448:
---

Please have a look at the 
[Field|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-field/src/main/java/org/apache/commons/numbers/field]
 implementations in "Commons Numbers".  The class that represent field elements 
extends {{Number}}.
Review welcome.

> Make RealFieldElement implement Number
> --
>
> Key: MATH-1448
> URL: https://issues.apache.org/jira/browse/MATH-1448
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Alexander Nozik
>Priority: Trivial
>
> RealFieldElement in some cases could be used as a substitute for a generic 
> `Number` and it quite easy to make it implement `Number` interface. Perhaps 
> it would be better to inherit it form number to allow universal treatment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1462) EmpiricalDistribution:inverseCumulativeProbability return Infinity

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on MATH-1462:
---

If the issue is still present, please attach (or make a PR with) a unit test in 
Java.  Thanks.

> EmpiricalDistribution:inverseCumulativeProbability return Infinity
> --
>
> Key: MATH-1462
> URL: https://issues.apache.org/jira/browse/MATH-1462
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: elyes belarbi
>Priority: Critical
>
> Hi,
> inverseCumulativeProbability(0.5) return "infinity" which is absurd while it 
> return correct values for 0.49 and 0.51, Here is the test :
> {code:java}
> double[] data = {6464.0205, 6449.1328, 6489.4569, 6497.5533, 6251.6487, 
> 6252.6513, 6339.7883,
> 6356.2622, 6222.1251, 6157.3813, 6242.4741, 6332.5347, 6468.0633, 6471.2319, 
> 6473.9929, 6589.1322, 
> 6511.2191, 6339.4349, 6307.7735, 6288.0915, 6354.0572, 6385.8283, 6325.3756, 
> 6433.1699, 6433.6507, 
> 6424.6806, 6380.5268, 6407.6705, 6241.2198, 6230.3681, 6367.5943, 6358.4817, 
> 6272.8039, 6269.0211, 
> 6312.9027, 6349.5926, 6404.0775, 6326.986, 6283.8685, 6309.9021, 6336.8554, 
> 6389.1598, 6281.0372, 
> 6304.8852, 6359.2651, 6426.519, 6400.3926, 6440.6798, 6292.5812, 6398.4911, 
> 6307.0002, 6284.2111, 6271.371, 6368.6377, 6323.3372, 6276.2155, 
> 6335.0117, 6319.2466, 6252.9969, 6445.2074, 6461.3944, 6384.1345};
> EmpiricalDistribution ed = new EmpiricalDistribution(data.length);
> ed.load(data);
> double p50 = ed.inverseCumulativeProbability(0.5);
> double p51 = ed.inverseCumulativeProbability(0.5);
> double p49 = ed.inverseCumulativeProbability(0.4);
> assertTrue(p51<6350);
> assertTrue(p49<6341);
> assertTrue(p50<7000);
> {code}
>  Any clue to fix this ?
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MATH-1487) MathInternalError - Kolmogorov Smirnov Test

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on MATH-1487:
---

Is the problem still present?

> MathInternalError - Kolmogorov Smirnov Test
> ---
>
> Key: MATH-1487
> URL: https://issues.apache.org/jira/browse/MATH-1487
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Paweł Lipiński
>Priority: Critical
> Attachments: alpha.arr, beta.arr
>
>
> Hi,
> I spotted a pesky bug in KolmogorovSmirnovTest class, in the method 
> kolmogorovSmirnovTest.
> In order to reproduce the error use arrays from attachments.
> Stacktrace:
> {noformat}
> org.apache.commons.math3.exception.MathInternalError: illegal state: internal 
> error, please fill a bug report at https://issues.apache.org/jira/browse/MATH
> at 
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.fixTies(KolmogorovSmirnovTest.java:1171)
>  at 
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:263)
>  at 
> org.apache.commons.math3.stat.inference.KolmogorovSmirnovTest.kolmogorovSmirnovTest(KolmogorovSmirnovTest.java:290)
> {noformat}
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MATH-1488) WelzlEncloser throws MathInternalError

[Gilles Sadowski (Jira)]

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

Gilles Sadowski resolved MATH-1488.
---
Resolution: Won't Fix

Fix is in "Commons Geometry".

> WelzlEncloser throws MathInternalError
> --
>
> Key: MATH-1488
> URL: https://issues.apache.org/jira/browse/MATH-1488
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: java 1.8, Windows 10 x64, idea
>Reporter: Benjamin Krogh
>Priority: Critical
>
> The following code snippets throws a MathInternalError when trying to 
> calculate the enclosing ball of the given points.
> {noformat}
> @Test
> public void encloserTest() {
> final List points = Arrays.asList(
> new Vector2D(271.59, 57.282),
> new Vector2D(269.145, 57.063),
> new Vector2D(309.117, 77.187),
> new Vector2D(316.989, 34.835),
> new Vector2D(323.101, 53.972)
> );
> double tolerance = 1;
> WelzlEncloser encloser = new 
> WelzlEncloser<>(tolerance, new DiskGenerator());
> encloser.enclose(points);
> }{noformat}
> Interestingly, if tolerance is set lower than 0.965 or higher than 1.100, it 
> suceeds. I was not able to find any tolerance value between 0.965 and 1.100 
> that succeeds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (NUMBERS-138) Square matrix for "Field" elements

[Gilles Sadowski (Jira)]

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

Gilles Sadowski resolved NUMBERS-138.
-
Resolution: Won't Do

Reverted in commit 4d2129e7a0cd0a0e05177f1d72d16368cd76a3b4.

> Square matrix for "Field" elements
> --
>
> Key: NUMBERS-138
> URL: https://issues.apache.org/jira/browse/NUMBERS-138
> Project: Commons Numbers
>  Issue Type: New Feature
>  Components: field, fraction
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
>  Labels: api
> Fix For: 1.0
>
>
> Use case is in class 
> [KolmogorovSmirnovTest|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/stat/inference/KolmogorovSmirnovTest.java;h=153d1d6c6dada92cbdf1f727ce2cf633b039ecc2;hb=HEAD#l689].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (COMPRESS-477) Support for splitted zip files

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=334620&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-334620
 ]

ASF GitHub Bot logged work on COMPRESS-477:
---

Author: ASF GitHub Bot
Created on: 27/Oct/19 11:38
Start Date: 27/Oct/19 11:38
Worklog Time Spent: 10m 
  Work Description: bodewig commented on issue #84: COMPRESS-477 Add 
support for extracting splitted zip files
URL: https://github.com/apache/commons-compress/pull/84#issuecomment-546686157
 
 
   Many thanks @PeterAlfreadLee I'll need some time to fully review the PR.
   
   As for `ZipArchiveInputStream` I completely agree with you that (virtually) 
concatenating the files into single stream should be almost enough. We'd need a 
way to deal with section 8.5.3 of 
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT as 
`zipArchiveInputStream` currently rejects files with the split marker 
https://github.com/apache/commons-compress/blob/205876d6f9eb60ac31f3ec848b23d025f32995ab/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveInputStream.java#L370
 . We could either allow people using `ZipArchiveInputStream` to signal it 
should skip the marker or provide a "collecting stream" that skipped the first 
four bytes if necessary.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 334620)
Time Spent: 50m  (was: 40m)

> Support for splitted zip files
> --
>
> Key: COMPRESS-477
> URL: https://issues.apache.org/jira/browse/COMPRESS-477
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Affects Versions: 1.18
>Reporter: Luís Filipe Nassif
>Priority: Major
>  Labels: zip
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It would be very useful to support splitted zip files. I've read 
> [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood 
> that simply concatenating the segments and removing the split signature 
> 0x08074b50 from first segment would be sufficient, but it is not that simple 
> because compress fails with exception below:
> {code}
> Caused by: java.util.zip.ZipException: archive's ZIP64 end of central 
> directory locator is corrupt.
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621)
>  ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) 
> ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) 
> ~[commons-compress-1.18.jar:1.18]
>  at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) 
> ~[commons-compress-1.18.jar:1.18]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-compress] bodewig commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files

[GitBox]

bodewig commented on issue #84: COMPRESS-477 Add support for extracting 
splitted zip files
URL: https://github.com/apache/commons-compress/pull/84#issuecomment-546686157
 
 
   Many thanks @PeterAlfreadLee I'll need some time to fully review the PR.
   
   As for `ZipArchiveInputStream` I completely agree with you that (virtually) 
concatenating the files into single stream should be almost enough. We'd need a 
way to deal with section 8.5.3 of 
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT as 
`zipArchiveInputStream` currently rejects files with the split marker 
https://github.com/apache/commons-compress/blob/205876d6f9eb60ac31f3ec848b23d025f32995ab/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveInputStream.java#L370
 . We could either allow people using `ZipArchiveInputStream` to signal it 
should skip the marker or provide a "collecting stream" that skipped the first 
four bytes if necessary.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-vfs] michael-o edited a comment on issue #74: VFS-687: adding http5 and http5s providers

[GitBox]

michael-o edited a comment on issue #74: VFS-687: adding http5 and http5s 
providers
URL: https://github.com/apache/commons-vfs/pull/74#issuecomment-546682883
 
 
   The names are confusing. Shouldn't this be hc5 and hc5s at most?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-vfs] michael-o commented on issue #74: VFS-687: adding http5 and http5s providers

[GitBox]

michael-o commented on issue #74: VFS-687: adding http5 and http5s providers
URL: https://github.com/apache/commons-vfs/pull/74#issuecomment-546682883
 
 
   The name is confusing. Shouldn't this be hc5 and hc5s at most?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services