[jira] [Comment Edited] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939125#comment-16939125
]
Peter Verhas edited comment on LANG-1491 at 9/27/19 5:02 AM:
-
Here you are. Welcome.
https://github.com/apache/commons-lang/pull/461
was (Author: pe...@verhas.com):
Here you are. Welcome.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939125#comment-16939125
]
Peter Verhas commented on LANG-1491:
Here you are. Welcome.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas opened a new pull request #461: Lang 1491
verhas opened a new pull request #461: Lang 1491 URL: https://github.com/apache/commons-lang/pull/461 Removing all public modifiers that are not needed anymore when we are using JUnit 5 and not JUnit 4. 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-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319313=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319313
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:48
Start Date: 27/Sep/19 01:48
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535749533
> > > Please merge it instead of nitpicking.
> > > That's not the best attitude IMO.
>
> I said please. Btw: I opened a ticket
https://issues.apache.org/jira/browse/LANG-1491 to fix this issue.
It's rather simple IMO: this patch should be consistent with the current
code base as it is now. IOW, tests are `public`.
If someone wants to do the busy work of changing all of Commons Lang, more
power to them, then the community can decide what to do, but this PR is not the
place to do it.
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: 319313)
Remaining Estimate: 16h 40m (was: 16h 50m)
Time Spent: 7h 20m (was: 7h 10m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 7h 20m
> Remaining Estimate: 16h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535749533 > > > Please merge it instead of nitpicking. > > > That's not the best attitude IMO. > > I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this issue. It's rather simple IMO: this patch should be consistent with the current code base as it is now. IOW, tests are `public`. If someone wants to do the busy work of changing all of Commons Lang, more power to them, then the community can decide what to do, but this PR is not the place to do it. 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-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939063#comment-16939063
]
Gary D. Gregory commented on LANG-1491:
---
Hi [~pe...@verhas.com],
PRs are welcome on GitHub.
Gary
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319311=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319311
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:45
Start Date: 27/Sep/19 01:45
Worklog Time Spent: 10m
Work Description: verhas commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535748891
>>Please merge it instead of nitpicking.
>That's not the best attitude IMO.
I said please. Btw: I opened a ticket
https://issues.apache.org/jira/browse/LANG-1491 to fix this issue.
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: 319311)
Remaining Estimate: 16h 50m (was: 17h)
Time Spent: 7h 10m (was: 7h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 7h 10m
> Remaining Estimate: 16h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319310=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319310
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:44
Start Date: 27/Sep/19 01:44
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664
> Please merge it instead of nitpicking.
That's not the best attitude IMO.
If you want to follow JUnit 5 conventions, please provide a patch that is
consistent over all classes and methods. Having a mix and public and package
private will just be confusing to others who will not know which convention to
follow.
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: 319310)
Remaining Estimate: 17h (was: 17h 10m)
Time Spent: 7h (was: 6h 50m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 7h
> Remaining Estimate: 17h
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535748891 >>Please merge it instead of nitpicking. >That's not the best attitude IMO. I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this issue. 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] garydgregory edited a comment on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory edited a comment on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. If you want to follow JUnit 5 conventions, please provide a patch that is consistent over all classes and methods. Having a mix and public and package private will just be confusing to others who will not know which convention to follow. 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-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319308=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319308
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:40
Start Date: 27/Sep/19 01:40
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664
> Please merge it instead of nitpicking.
That's not the best attitude IMO.
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: 319308)
Remaining Estimate: 17h 10m (was: 17h 20m)
Time Spent: 6h 50m (was: 6h 40m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6h 50m
> Remaining Estimate: 17h 10m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. 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] [Updated] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1491:
---
Description:
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted. Otherwise, the code becomes inconsistent as the new and modified tests
will be package protected as per required by the test library and the old tests
remain public unnecessarily.
was:
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
Peter Verhas created LANG-1491:
--
Summary: Unit tests visibility is non-conforming with JUnit 5
Key: LANG-1491
URL: https://issues.apache.org/jira/browse/LANG-1491
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.9
Reporter: Peter Verhas
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319303=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319303
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:15
Start Date: 27/Sep/19 01:15
Worklog Time Spent: 10m
Work Description: verhas commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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
Issue Time Tracking
---
Worklog Id: (was: 319303)
Remaining Estimate: 17h 20m (was: 17.5h)
Time Spent: 6h 40m (was: 6.5h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6h 40m
> Remaining Estimate: 17h 20m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName
refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319302=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319302
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:08
Start Date: 27/Sep/19 01:08
Worklog Time Spent: 10m
Work Description: verhas commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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
Issue Time Tracking
---
Worklog Id: (was: 319302)
Remaining Estimate: 17.5h (was: 17h 40m)
Time Spent: 6.5h (was: 6h 20m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6.5h
> Remaining Estimate: 17.5h
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName
refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319300=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319300
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 27/Sep/19 01:07
Start Date: 27/Sep/19 01:07
Worklog Time Spent: 10m
Work Description: verhas commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881421
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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
Issue Time Tracking
---
Worklog Id: (was: 319300)
Remaining Estimate: 17h 40m (was: 17h 50m)
Time Spent: 6h 20m (was: 6h 10m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6h 20m
> Remaining Estimate: 17h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName
refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881421
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
Review comment:
Sorry, but wrong addressee. This is not me, who has changed the visibility,
but JUnit 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-imaging] kinow commented on issue #49: Add support for EXIF 2.32
kinow commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-535682893 Hi @GITNE >I have added terminal newlines where applicable but Travis CI still fails for some unrelated reason. You have to rebase your branch on master. I've fixed the Javadoc error on JVM 13. So once rebased, this PR should pass Travis with no issues 爛 . Do you intend to modify anything else in the PR? Add any feature/code? >Btw, personally I consider tools which require you to put a terminal newline in your files to be broken or to have a badly implemented parser. That pseudo argument for terminal newlines where stream processing concatenated files my lead to undesired behavior is dumb. It is naive to assume that processing concatenated files and processing files separately will or should always produce identical results. It is the file format that governs parsing not the mode of processing. Just to clarify, the newline here is for git. I believe it came from unix where it was good practice to have the newline. Not sure if there's a practical reason for that. 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-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319195=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319195
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 26/Sep/19 20:14
Start Date: 26/Sep/19 20:14
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535668589
Because all other tests are public. IOW, consistency.
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: 319195)
Remaining Estimate: 17h 50m (was: 18h)
Time Spent: 6h 10m (was: 6h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6h 10m
> Remaining Estimate: 17h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535668589 Because all other tests are public. IOW, consistency. 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-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319139=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319139
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 26/Sep/19 18:54
Start Date: 26/Sep/19 18:54
Worklog Time Spent: 10m
Work Description: verhas commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328774255
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Why?
Since the project uses JUnit 5 the required visibility is package private.
Any access modifier is noise.
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: 319139)
Remaining Estimate: 18h (was: 18h 10m)
Time Spent: 6h (was: 5h 50m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 6h
> Remaining Estimate: 18h
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName
refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r328774255
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() {
assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
1));
assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class,
5));
+assertEquals("o.a.c.l.ClassUtils",
ClassUtils.getAbbreviatedName(ClassUtils.class, 18));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 13));
assertEquals("j.lang.String",
ClassUtils.getAbbreviatedName(String.class, 15));
assertEquals("java.lang.String",
ClassUtils.getAbbreviatedName(String.class, 20));
}
+/**
+ * Test that in case the required length is larger than the name and thus
there is no need for any shortening
+ * then the returned string object is the same as the one passed as
argument. Note, however, that this is
+ * tested as an internal implementation detail, but it is not a guaranteed
feature of the implementation.
+ */
@Test
-public void test_getAbbreviatedName_Class_NegativeLen() {
+@DisplayName("When the length hint is longer than the actual length then
the same String object is returned")
+void test_getAbbreviatedName_TooLongHint(){
+final String className = "java.lang.String";
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()+1));
+Assertions.assertSame(className,
ClassUtils.getAbbreviatedName(className, className.length()));
+}
+
+@Test
+@DisplayName("When the desired length is negative then exception is
thrown")
+void test_getAbbreviatedName_Class_NegativeLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, -10));
}
@Test
-public void test_getAbbreviatedName_Class_ZeroLen() {
+@DisplayName("When the desired length is zero then exception is thrown")
+void test_getAbbreviatedName_Class_ZeroLen() {
assertThrows(IllegalArgumentException.class, () ->
ClassUtils.getAbbreviatedName(String.class, 0));
}
@Test
-public void test_getAbbreviatedName_String() {
Review comment:
Why?
Since the project uses JUnit 5 the required visibility is package private.
Any access modifier is noise.
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-csv] garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-535624098 @macsharker6 I think a week or maybe two. I have two other releases to do first. 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-cli] garydgregory merged pull request #31: Switch from Oracle JDK 8 to Open JDK 8
garydgregory merged pull request #31: Switch from Oracle JDK 8 to Open JDK 8 URL: https://github.com/apache/commons-cli/pull/31 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] [Resolved] (RNG-119) Add LongJumpable support to XorShiRo generators
[
https://issues.apache.org/jira/browse/RNG-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved RNG-119.
--
Fix Version/s: 1.3
Resolution: Implemented
In git master.
> Add LongJumpable support to XorShiRo generators
> ---
>
> Key: RNG-119
> URL: https://issues.apache.org/jira/browse/RNG-119
> Project: Commons RNG
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.3
>Reporter: Alex Herbert
>Priority: Major
> Fix For: 1.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The following generators now have a long jump function:
> {noformat}
> XoShiRo128Plus
> XoShiRo128StarStar
> XoShiRo512Plus
> XoShiRo512StarStar
> {noformat}
> This has been added to the original source since the generators were added to
> the commons RNG library.
> See [xoshiro / xoroshiro generators|http://prng.di.unimi.it/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-rng] asfgit merged pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators.
asfgit merged pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69 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-rng] coveralls commented on issue #69: RNG-119: Add LongJumpable support to XoShiRo generators.
coveralls commented on issue #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69#issuecomment-535596703 [](https://coveralls.io/builds/25953368) Coverage increased (+0.001%) to 99.455% when pulling **8449aa64871180bf1fb2be78264b8c3974b94c99 on aherbert:improvement-RNG-119** into **4774ada3ec6eb0fb21455f3975fc5df1d697cbc9 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] [Commented] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938804#comment-16938804 ] Danish Kamaal commented on NET-642: --- I am writing a fix for this. This issue has been open for too long and I think there should be a fix. > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (RNG-117) RandomSource to support creating byte[] seed for implementing class.
[
https://issues.apache.org/jira/browse/RNG-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved RNG-117.
--
Fix Version/s: 1.3
Resolution: Implemented
In git master.
> RandomSource to support creating byte[] seed for implementing class.
>
>
> Key: RNG-117
> URL: https://issues.apache.org/jira/browse/RNG-117
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
> Fix For: 1.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Each implementing class represented by {{RandomSource}} has a defined seed
> type. The internal package knows the type and can create appropriate seeds.
> This occurs when a {{null}} seed is passed to the factory method
> {{create(RandomSource, ...)}}.
> Notably the seed generation functionality satisfies any extra requirements of
> the generator such as avoiding all zero bytes and, for example, low
> complexity bytes for the MiddleSquareWeylSequence class.
> The seed generation functionality can be exposed to allow:
> # Generation of a seed that exactly matches that generated in the factory
> create method
> # Generation of a seed using a user defined source of randomness
> This requires 2 new methods in RandomSource:
> {code:java}
> // To use the factory source of randomness
> public byte[] createSeed();
> // To use a user-defined source of randomness
> public byte[] createSeed(UniformRandomProvider rng);
> {code}
> This would allow separation of seed generation from RNG construction:
> {code:java}
> RandomSource source = ...;
> UniformRandomProvider rng = RandomSource.create(source);
> {code}
> Becomes
> {code:java}
> RandomSource source = ...;
> byte[] seed = source.createSeed();
> // Some later point
> UniformRandomProvider rng = RandomSource.create(source, seed);
> {code}
> An example of a user-defined source of randomness:
> {code:java}
> RandomSource source = ...;
> UniformRandomProvider seedRng = new JDKRandomWrapper(new SecureRandom());
> byte[] seed = source.createSeed(seedRng);
> UniformRandomProvider rng = RandomSource.create(source, seed);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] GITNE commented on issue #49: Add support for EXIF 2.32
GITNE commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-535581417 I have added terminal newlines where applicable but Travis CI still fails for some unrelated reason. Btw, personally I consider tools which require you to put a terminal newline in your files to be broken or to have a badly implemented parser. That pseudo argument for terminal newlines where stream processing concatenated files my lead to undesired behavior is dumb. It is naive to assume that processing concatenated files and processing files separately will or should always produce identical results. It is the file format that governs parsing not the mode of processing. 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-rng] asfgit merged pull request #70: Changed samplers parametric test failure probability.
asfgit merged pull request #70: Changed samplers parametric test failure probability. URL: https://github.com/apache/commons-rng/pull/70 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-rng] aherbert opened a new pull request #70: Changed samplers parametric test failure probability.
aherbert opened a new pull request #70: Changed samplers parametric test failure probability. URL: https://github.com/apache/commons-rng/pull/70 Only 1 re-run is allowed and the number of samplers is high enough that spurious failures are realistic for the samplers. Changed the Continuous samplers failure rate from p=0.0138 to p=0.0016. This is an effective change of numFailures(n=50, p=0.01) > 2 to numFailures(n=50, p=0.01) > 3. Changed the Discrete samplers failure rate from p=0.189 to p=0.0016 to match the continuous samplers test. Each test is now assessed at the p=0.01 level not the p=0.001 level. This is an effective change of numFailures(n=50, p=0.001) > 2 to numFailures(n=50, p=0.01) > 3. 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-rng] aherbert opened a new pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators.
aherbert opened a new pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69 This adds the long jump function to those generators previously supporting only a jump function. 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] (RNG-119) Add LongJumpable support to XorShiRo generators
Alex Herbert created RNG-119:
Summary: Add LongJumpable support to XorShiRo generators
Key: RNG-119
URL: https://issues.apache.org/jira/browse/RNG-119
Project: Commons RNG
Issue Type: New Feature
Components: core
Affects Versions: 1.3
Reporter: Alex Herbert
The following generators now have a long jump function:
{noformat}
XoShiRo128Plus
XoShiRo128StarStar
XoShiRo512Plus
XoShiRo512StarStar
{noformat}
This has been added to the original source since the generators were added to
the commons RNG library.
See [xoshiro / xoroshiro generators|http://prng.di.unimi.it/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-cli] mincong-h opened a new pull request #31: Switch from Oracle JDK 8 to Open JDK 8
mincong-h opened a new pull request #31: Switch from Oracle JDK 8 to Open JDK 8 URL: https://github.com/apache/commons-cli/pull/31 Fix broken build [589473088](https://travis-ci.org/apache/commons-cli/builds/589473088) (triggered by https://github.com/apache/commons-cli/commit/684b3c9eb54aa7d5328d1a4e2583c3dbdfe64465) by switching from Oracle JDK 8 to Open JDK 8. Open JDK 8 has already been used by other repositories of Apache Commons, such as [commons-math](https://github.com/apache/commons-math/blob/master/.travis.yml#L20), [commons-io](https://github.com/apache/commons-io/blob/master/.travis.yml#L20), and [commons-lang](https://github.com/apache/commons-lang/blob/master/.travis.yml#L18). 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] (GEOMETRY-30) VectorBuilder?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938701#comment-16938701
]
Gilles Sadowski commented on GEOMETRY-30:
-
In order to figure what is actually necessary, perhaps start with a "minimal"
implementation:
{code}
public class Vector2D {
// ...
public static class Builder {
private double x;
private double y;
private Builder(double x, double y) {
this.x = x;
this.y = y;
}
public Builder create() {
return new Builder(0, 0);
}
public Builder add(double x, double y) {
this.x += x;
this.y += y;
}
public Vector2D build();
}
}
{code}
Then we should benchmark alternative implementations ("Builder" vs vector
addition) in order to e.g. compute a barycenter.
> VectorBuilder?D Classes
> ---
>
> Key: GEOMETRY-30
> URL: https://issues.apache.org/jira/browse/GEOMETRY-30
> Project: Apache Commons Geometry
> Issue Type: Wish
>Reporter: Matt Juntunen
>Priority: Major
>
> We should add a {{VectorBuilder?D}} class for each dimension. These classes
> would have the same coordinate properties as their corresponding {{Vector}}
> classes but would be mutable. They would be used to build {{Vector}}
> instances from a number of input values without requiring a new instance to
> be created for each step. The primary API should look something like this:
> {code:java}
> public class VectorBuilder2D {
> double getX();
> VectorBuilder2D setX(double);
> double getY();
> VectorBuilder2D setY(double);
> VectorBuilder2D add(Vector2D);
> VectorBuilder2D subtract(Vector2D);
> VectorBuilder2D multiply(double);
> Vector2D toVector();
> }
> {code}
> A good use case for this is computing a centroid:
> {code:java}
> VectorBuilder2D builder = new VectorBuilder2D();
> for (Vector2D pt : points) {
> builder.add(pt);
> }
> builder.multiply(1.0 / points.size());
> Vector2D centroid = builder.toVector();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FILEUPLOAD-301) Problems uploading files greater than 100kb using HTTPS
Andrea created FILEUPLOAD-301:
-
Summary: Problems uploading files greater than 100kb using HTTPS
Key: FILEUPLOAD-301
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-301
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.2, 1.4
Environment:
Apache Tomcat 8.5
java 9.0.4
Windows Server 2016 Datacenter
Reporter: Andrea
I'have a java web app that uses Apache Commons FileUpload for uploading files
using servlets.
My base code worked perfectly for years on a plain http environment (Apache
Tomcat 8.5).
I've changed my environment to work with HTTPS, using a Let's Encrypt
certificate using connector configured with
org.apache.coyote.http11.Http11AprProtocol.
My uploads now suddenly fail if files are greater than 100kb. Same files
uploaded successfully using plain HTTP environment.
This is the exception logged:
{{org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. java.io.IOException: The
socket [925,024,592] associated with this connection has been closed.}}
this is the code fragment i use for manage request:
{{DiskFileItemFactory factory = new DiskFileItemFactory(); }}
{{File repository = (File)
request.getServletContext().getAttribute("javax.servlet.context.tempdir");
factory.setRepository(repository); }}
{{ServletFileUpload upload = new ServletFileUpload(factory);
upload.setHeaderEncoding(encoding); }}
{{multipartItems = upload.parseRequest(request);}}
Tomcat settings:
{{}}
{{}}
{{ }}
{{
}}
{{ }}
{{ }}
{{}}
Thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-rng] asfgit merged pull request #68: RNG-117: RandomSource to support creating byte[] seed for implementing class.
asfgit merged pull request #68: RNG-117: RandomSource to support creating byte[] seed for implementing class. URL: https://github.com/apache/commons-rng/pull/68 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] (GEOMETRY-30) VectorBuilder?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938578#comment-16938578
]
Gilles Sadowski commented on GEOMETRY-30:
-
bq. avoid unnecessary vector creation.
At some point, it would be useful to create benchmarks (using
[JMH|https://openjdk.java.net/projects/code-tools/jmh/]) so that we can assess
when "unnecessary" equals "costly".
bq. computing the region barycenter.
Isn't that a case for a stream operation?
> VectorBuilder?D Classes
> ---
>
> Key: GEOMETRY-30
> URL: https://issues.apache.org/jira/browse/GEOMETRY-30
> Project: Apache Commons Geometry
> Issue Type: Wish
>Reporter: Matt Juntunen
>Priority: Major
>
> We should add a {{VectorBuilder?D}} class for each dimension. These classes
> would have the same coordinate properties as their corresponding {{Vector}}
> classes but would be mutable. They would be used to build {{Vector}}
> instances from a number of input values without requiring a new instance to
> be created for each step. The primary API should look something like this:
> {code:java}
> public class VectorBuilder2D {
> double getX();
> VectorBuilder2D setX(double);
> double getY();
> VectorBuilder2D setY(double);
> VectorBuilder2D add(Vector2D);
> VectorBuilder2D subtract(Vector2D);
> VectorBuilder2D multiply(double);
> Vector2D toVector();
> }
> {code}
> A good use case for this is computing a centroid:
> {code:java}
> VectorBuilder2D builder = new VectorBuilder2D();
> for (Vector2D pt : points) {
> builder.add(pt);
> }
> builder.multiply(1.0 / points.size());
> Vector2D centroid = builder.toVector();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] asfgit closed pull request #39: GEOMETRY-46: Add additional UnitVector methods
asfgit closed pull request #39: GEOMETRY-46: Add additional UnitVector methods URL: https://github.com/apache/commons-geometry/pull/39 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] (RNG-118) XoRoShiRo PlusPlus generators
Alex Herbert created RNG-118:
Summary: XoRoShiRo PlusPlus generators
Key: RNG-118
URL: https://issues.apache.org/jira/browse/RNG-118
Project: Commons RNG
Issue Type: New Feature
Components: core
Affects Versions: 1.3
Reporter: Alex Herbert
New variants of the XoRoShiRo generators have been written by Blackman and
Vigna (2019):
These are variants of the StarStar all purpose generators and should be faster
on architectures where long multiplication (the star operation) is slow:
{noformat}
32-bit
XoShiRo128PlusPlus
64-bit
XoRoShiRo128PlusPlus
XoShiRo256PlusPlus
XoShiRo512PlusPlus
{noformat}
These are new 1024-bit footprint generators to replace the XorShift1024
generator:
{noformat}
64-bit
XoRoShiRo1024Star
XoRoShiRo1024PlusPlus
XoRoShiRo1024StarStar
{noformat}
Reference [xoshiro / xoroshiro generators|http://prng.di.unimi.it/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEOMETRY-62) Fix "CheckStyle" errors
Gilles Sadowski created GEOMETRY-62: --- Summary: Fix "CheckStyle" errors Key: GEOMETRY-62 URL: https://issues.apache.org/jira/browse/GEOMETRY-62 Project: Apache Commons Geometry Issue Type: Task Reporter: Gilles Sadowski Fix For: 1.0 CheckStyle currently reports: * "commons-geometry-core": 50 errors * "commons-geometry-euclidean": 136 errors * "commons-geometry-spherical": 9 errors * "commons-geometry-hull": 3 errors * "commons-geometry-enclosing": 3 errors When the report is clean, the "validate" phase could reinstate the check (see POM) in order to fail the build in the presence of any error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-30) VectorBuilder?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938549#comment-16938549
]
Matt Juntunen commented on GEOMETRY-30:
---
[Here|https://github.com/darkma773r/commons-geometry/blob/geometry-32-working/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/RegionBSPTree3D.java#L654]
is an actual example from my geometry-32 working branch where I'm computing
the region barycenter. I use separate doubles for each component to avoid
unnecessary vector creation. This same type of construct is repeated in all of
the other {{RegionBSPTreeXD}} classes.
> VectorBuilder?D Classes
> ---
>
> Key: GEOMETRY-30
> URL: https://issues.apache.org/jira/browse/GEOMETRY-30
> Project: Apache Commons Geometry
> Issue Type: Wish
>Reporter: Matt Juntunen
>Priority: Major
>
> We should add a {{VectorBuilder?D}} class for each dimension. These classes
> would have the same coordinate properties as their corresponding {{Vector}}
> classes but would be mutable. They would be used to build {{Vector}}
> instances from a number of input values without requiring a new instance to
> be created for each step. The primary API should look something like this:
> {code:java}
> public class VectorBuilder2D {
> double getX();
> VectorBuilder2D setX(double);
> double getY();
> VectorBuilder2D setY(double);
> VectorBuilder2D add(Vector2D);
> VectorBuilder2D subtract(Vector2D);
> VectorBuilder2D multiply(double);
> Vector2D toVector();
> }
> {code}
> A good use case for this is computing a centroid:
> {code:java}
> VectorBuilder2D builder = new VectorBuilder2D();
> for (Vector2D pt : points) {
> builder.add(pt);
> }
> builder.multiply(1.0 / points.size());
> Vector2D centroid = builder.toVector();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-54) Cleanup Checkstyle Reported issues
[
https://issues.apache.org/jira/browse/GEOMETRY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938542#comment-16938542
]
Matt Juntunen commented on GEOMETRY-54:
---
Is there a pull request for this? It seems like we should be able to merge this
is and close this issue.
> Cleanup Checkstyle Reported issues
> --
>
> Key: GEOMETRY-54
> URL: https://issues.apache.org/jira/browse/GEOMETRY-54
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core, Euclidean 1D, Euclidean 2D, Euclidean 3D
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: checkstyle
> Fix For: 1.0
>
>
> *Problem*
> * Currently several Checkstyle based ERRORs/WARNINGs are reported
> ** {{geometry-core}}:
> *** {{DoublePrecisionContextTest.java}} usage of {{new Double(...)}} is
> deprecated marked with JDK 9 which can simply being replaced by using
> {{Double.valueOf(..)}}.
> ** {{geometry-euclidian}}, {{geometry-core}}
> *** {{Vector.java}} messages like {{Vector.java:99:8: Unable to get class
> information for @throws tag 'IllegalNormException'. [JavadocMethod]}}
> *** {{AffineTransformMatrix3D.java}}, {{AffineTransformMatrix1D.java}} and
> {{AffineTransformMatrix1D.java}} messages like {{Unable to get class
> information for @throws tag 'NonInvertibleTransformException'.}}.
> ** This is related to that the methods do not add the throwing to the method
> signature and using a wrong JavaDoc Tag like {{exception}}.
> *Goal*
> * Remove the ERRORs/WARNINGs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-46) Additional UnitVector methods
[
https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938541#comment-16938541
]
Matt Juntunen commented on GEOMETRY-46:
---
Sounds good to me!
> Additional UnitVector methods
> -
>
> Key: GEOMETRY-46
> URL: https://issues.apache.org/jira/browse/GEOMETRY-46
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: easyfix, pull-request-available, starter
> Attachments: GEOMETRY-46.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following methods should be overridden in the {{UnitVector}} private
> subclasses of the {{Vector?D}} classes:
> * {{normSq}} -- should return {{1}} for consistency with {{norm}}
> * {{negate}} -- should be overridden to also return a {{UnitVector}} instance
> instead of a regular {{Vector?D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEOMETRY-61) Provide "unit" vector concept
Gilles Sadowski created GEOMETRY-61: --- Summary: Provide "unit" vector concept Key: GEOMETRY-61 URL: https://issues.apache.org/jira/browse/GEOMETRY-61 Project: Apache Commons Geometry Issue Type: Improvement Components: Euclidean 1D, Euclidean 2D, Euclidean 3D Reporter: Gilles Sadowski Assignee: Gilles Sadowski The concept of unit vector exists in geometry; hence it would make sense to allow it to be represented in code (possibly allowing more efficient implementations of some algorithms). Discussion on this feature was started in GEOMETRY-46. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CODEC-263) Base64.decodeBase64 throw exception
xie tao created CODEC-263:
-
Summary: Base64.decodeBase64 throw exception
Key: CODEC-263
URL: https://issues.apache.org/jira/browse/CODEC-263
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.13
Environment: JDK 7/JDK 8
commons-codec 1.13
Reporter: xie tao
Codec upgrade to 1.13, code throw exception as follows：
{code:java}
@Test
public void test(){
Base64.decodeBase64("publishMessage");
}
{code}
exception like：
{code:java}
java.lang.IllegalArgumentException: Last encoded character (before the paddings
if any) is a valid base 64 alphabet but not a possible value
at
org.apache.commons.codec.binary.Base64.validateCharacter(Base64.java:798)
at org.apache.commons.codec.binary.Base64.decode(Base64.java:472)
at
org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:412)
at
org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:395)
at org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:694)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] michael-o commented on issue #460: Lang-1465: Fix the ZZ time zone format
michael-o commented on issue #460: Lang-1465: Fix the ZZ time zone format URL: https://github.com/apache/commons-lang/pull/460#issuecomment-535423035 The `Z` modifier here is not the same as within Java itself. Therefore, rejecting it. Moreover, your usecase is nonsense because the format is not valid according to ISO 8601. 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-csv] macsharker6 edited a comment on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
macsharker6 edited a comment on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-533182150 Hi @garydgregory, any update for the release 1.8? Thanks in advance. macsharker6 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] [Comment Edited] (COLLECTIONS-674) Add Collections Drain Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938352#comment-16938352
]
Chen edited comment on COLLECTIONS-674 at 9/26/19 7:06 AM:
---
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The collection
can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
was (Author: guoping1):
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The Collection of
Input can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
> Add Collections Drain Method
>
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.1
>Reporter: David Mollitor
>Priority: Major
>
> Add a {{Collections.drain()}} method which removes the first N elements from
> the collection and returns them. This method would have the side-effect of
> modifying the input collections (due to removal).
>
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-674) Add Collections Drain Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938352#comment-16938352
]
Chen commented on COLLECTIONS-674:
--
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The Collection of
Input can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
> Add Collections Drain Method
>
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.1
>Reporter: David Mollitor
>Priority: Major
>
> Add a {{Collections.drain()}} method which removes the first N elements from
> the collection and returns them. This method would have the side-effect of
> modifying the input collections (due to removal).
>
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
