[jira] [Commented] (TEXT-82) Bring WordUtils back in to the code base
[
https://issues.apache.org/jira/browse/TEXT-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989650#comment-15989650
]
Rob Tompkins commented on TEXT-82:
--
Note that this directly relates to TEXT-55
> Bring WordUtils back in to the code base
>
>
> Key: TEXT-82
> URL: https://issues.apache.org/jira/browse/TEXT-82
> Project: Commons Text
> Issue Type: Task
>Reporter: Rob Tompkins
> Fix For: 1.1
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I would like to get {{WordUtils}}, either from commons-lang, or from the
> branch "TEXT-55" specifically viewable here:
> https://github.com/apache/commons-text/blob/TEXT-55/src/main/java/org/apache/commons/text/WordUtils.java
> Also insert any tests that go along with it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TEXT-82) Bring WordUtils back in to the code base
Rob Tompkins created TEXT-82:
Summary: Bring WordUtils back in to the code base
Key: TEXT-82
URL: https://issues.apache.org/jira/browse/TEXT-82
Project: Commons Text
Issue Type: Task
Reporter: Rob Tompkins
Fix For: 1.1
I would like to get {{WordUtils}}, either from commons-lang, or from the branch
"TEXT-55" specifically viewable here:
https://github.com/apache/commons-text/blob/TEXT-55/src/main/java/org/apache/commons/text/WordUtils.java
Also insert any tests that go along with it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[ https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed TEXT-45. Resolution: Won't Fix Fix Version/s: (was: 1.1) I believe the request leads to counter intuitive method signatures. However, if folks wish to re-open this, I am not opposed and will welcome the discussion. > WordUtils delimiters should be strings, not char varargs > > > Key: TEXT-45 > URL: https://issues.apache.org/jira/browse/TEXT-45 > Project: Commons Text > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Minor > Labels: api,, interface,ease,of,use,, robustness, > > Strings behave like char varargs of arbitrary length, but are much easier to > use. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[ https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989646#comment-15989646 ] Rob Tompkins commented on TEXT-45: -- I'm going to close this as "won't fix" for now. We can revisit later if we wish. > WordUtils delimiters should be strings, not char varargs > > > Key: TEXT-45 > URL: https://issues.apache.org/jira/browse/TEXT-45 > Project: Commons Text > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Minor > Labels: api,, interface,ease,of,use,, robustness, > Fix For: 1.1 > > > Strings behave like char varargs of arbitrary length, but are much easier to > use. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (LANG-1256) Add JMH maven dependencies.
[ https://issues.apache.org/jira/browse/LANG-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1256. - Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 3.6 Thanks! > Add JMH maven dependencies. > --- > > Key: LANG-1256 > URL: https://issues.apache.org/jira/browse/LANG-1256 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Artem Barger >Assignee: Pascal Schumacher > Fix For: 3.6 > > > In order to provide patch for LANG-1110 and make distinction between > introducing actual JMH dependency and the benchmark implementation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1110) Implement HashSetvBitSetTest using JMH
[ https://issues.apache.org/jira/browse/LANG-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989025#comment-15989025 ] Pascal Schumacher commented on LANG-1110: - Thanks everybody! > Implement HashSetvBitSetTest using JMH > -- > > Key: LANG-1110 > URL: https://issues.apache.org/jira/browse/LANG-1110 > Project: Commons Lang > Issue Type: Test > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Pascal Schumacher > Fix For: 3.6 > > Attachments: HashSetvBitSetTest.java > > > HashSetvBitSetTest currently writes to Std out, which is bad practice for > unit tests. Since HashSetvBitSetTest is really a performance test and not a > unit test, we should reimplement it using OpenJMH. The results could then be > published on our website. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (LANG-1110) Implement HashSetvBitSetTest using JMH
[ https://issues.apache.org/jira/browse/LANG-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1110. - Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: (was: Patch Needed) 3.6 > Implement HashSetvBitSetTest using JMH > -- > > Key: LANG-1110 > URL: https://issues.apache.org/jira/browse/LANG-1110 > Project: Commons Lang > Issue Type: Test > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Pascal Schumacher > Fix For: 3.6 > > Attachments: HashSetvBitSetTest.java > > > HashSetvBitSetTest currently writes to Std out, which is bad practice for > unit tests. Since HashSetvBitSetTest is really a performance test and not a > unit test, we should reimplement it using OpenJMH. The results could then be > published on our website. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1110) Implement HashSetvBitSetTest using JMH
[ https://issues.apache.org/jira/browse/LANG-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989021#comment-15989021 ] ASF GitHub Bot commented on LANG-1110: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/182 > Implement HashSetvBitSetTest using JMH > -- > > Key: LANG-1110 > URL: https://issues.apache.org/jira/browse/LANG-1110 > Project: Commons Lang > Issue Type: Test > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Patch Needed > > Attachments: HashSetvBitSetTest.java > > > HashSetvBitSetTest currently writes to Std out, which is bad practice for > unit tests. Since HashSetvBitSetTest is really a performance test and not a > unit test, we should reimplement it using OpenJMH. The results could then be > published on our website. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #182: Add maven dependency for JMH framework.
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/182 Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #182: Add maven dependency for JMH framework.
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/182 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #253: Added a restart method for convenience
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/253 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #191: ToStringExcludeNullValue
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/191 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1256) Add JMH maven dependencies.
[ https://issues.apache.org/jira/browse/LANG-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-1256: Issue Type: Task (was: Bug) > Add JMH maven dependencies. > --- > > Key: LANG-1256 > URL: https://issues.apache.org/jira/browse/LANG-1256 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Artem Barger > > In order to provide patch for LANG-1110 and make distinction between > introducing actual JMH dependency and the benchmark implementation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #191: ToStringExcludeNullValue
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/191 Support for excluding `null` values was added in https://github.com/apache/commons-lang/commit/8147cc5b3de5fa7a3a3e8116355efa44367dc3c5 @gabriel-amaral Thanks for the pull request and sorry that it was not merged. Can you please close it? Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (TEXT-36) RandomStringGenerator: allow users to provide source of randomness
[
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved TEXT-36.
---
Resolution: Fixed
Assignee: Pascal Schumacher
> RandomStringGenerator: allow users to provide source of randomness
> --
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Pascal Schumacher
> Labels: api
> Fix For: 1.1
>
>
> This is a follow-up of a
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
> held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api"
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
> of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project
> as a whole) to not advertize or use other Commons components, despite the
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and
> define TEXT's own interface to random numbers, with bridges to it from
> {{UniformRandomProvider}} and from {{java.util.Random}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (TEXT-81) Add RandomStringGenerator
[ https://issues.apache.org/jira/browse/TEXT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved TEXT-81. --- Resolution: Fixed Assignee: Pascal Schumacher > Add RandomStringGenerator > - > > Key: TEXT-81 > URL: https://issues.apache.org/jira/browse/TEXT-81 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
[
https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15988447#comment-15988447
]
Stefan Bodewig commented on COMPRESS-390:
-
I'd also prefer a completely separate interface implemented by those
ArchiveEntries that support the offset.
Not sure but maybe even something like
{code}
interface OffsetType { }
interface WithOffsets {
static long UNKNOWN_OFFSET = -1;
long getOffset(OffsetType type);
}
enum ZipOffsetType implements OffsetType {
DATA, LOCAL_FILE_HEADER, CENTRAL_DIRECTORY
}
{code}
but that may be too much. I don't see why anybody would want to read the
headers, we should rather expose all information contained inside the headers
via the {{*ArchiveEntry}}.
I'm not convinced people will need this for the stream only cases, but if so
then I'd prefer
{code}
class StreamScanner {
StreamScanner(InputStream s) throws IOException;
long getOffset(ArchiveEntry entry);
}
{code}
over adding the offset to {{ArchiveEntry}} itself. I'd find it far to
cumbersome to explain that the entries offset will be unknown unless you have
obtained it in a special way. Maybe extract the {{getOffset}} from my fictional
{{StreamScanner}} into an interface an make {{ZipFile}} and {{SevenZFile}}
implement that?
> Expose zip stream offset and size via API
> -
>
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
>Affects Versions: 1.13
>Reporter: Zbynek Vyskovsky
> Labels: features, github-import, patch
> Fix For: 1.14
>
>
> In certain cases it may be useful to get information about where in the
> archive the stream starts and ends. Typically when zip is used as resource
> container and the resources are then mapped directly into memory, but not
> only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make
> sense to put this into basic interface - ArchiveEntry. But not necessarily
> all of them have to support it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
[
https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15988277#comment-15988277
]
Gary Gregory commented on COMPRESS-390:
---
IMO you have a new interface called {{Offsets}} (or {{OffsetInfo}}, or
{{OffestData}}) that has {{getThatOffset()}} and {{getThisOffset()}}. I do not
think that a {{ArchiveEntryWithOffset}} should extend {{ArchiveEntry}}. This
would lock us into extending that new interface with a third one if we needed
more functionality later.
This seems cleaner to me, YMMV.
> Expose zip stream offset and size via API
> -
>
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
>Affects Versions: 1.13
>Reporter: Zbynek Vyskovsky
> Labels: features, github-import, patch
> Fix For: 1.14
>
>
> In certain cases it may be useful to get information about where in the
> archive the stream starts and ends. Typically when zip is used as resource
> container and the resources are then mapped directly into memory, but not
> only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make
> sense to put this into basic interface - ArchiveEntry. But not necessarily
> all of them have to support it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
