[jira] [Commented] (SANDBOX-458) Implementation of algorithms available in other libraries
[ https://issues.apache.org/jira/browse/SANDBOX-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078956#comment-16078956 ] Bruno P. Kinoshita commented on SANDBOX-458: Besides external libraries, there are now quite a few projects within ASF that also use graph algorithms or provide a graph API. A few examples: * [Apache Jena|https://github.com/apache/jena/tree/f30ac0f89d7657a5cd2a65b4f6a11b18b58c9cd4/jena-core/src/main/java/org/apache/jena/graph] * [Apache Commons RDF|https://github.com/apache/commons-rdf/blob/482b83138a742e54f60d2c2a9003867929ece4c5/api/src/main/java/org/apache/commons/rdf/api/Graph.java] * [Apache Spark|https://github.com/apache/spark/tree/a0fe32a219253f0abe9d67cf178c73daf5f6fcc1/graphx/src/main/scala/org/apache/spark/graphx] * [Apache TinkerPop|https://github.com/apache/tinkerpop/blob/22e2d9d9037fdfc0218a0e6e4d81bdf250fa7160/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/Graph.java] * [Apache S2Graph|https://s2graph.incubator.apache.org/] * [Apache Taverna|https://github.com/apache/incubator-taverna-workbench/tree/4e3849dd91fa0444dc6db97f2f3a24e689d5f683/taverna-graph-model/src/main/java/org/apache/taverna/workbench/models/graph] * [Apache Clerezza|https://github.com/apache/clerezza/blob/14575ea321a737f68732783e8248221b3efcef1c/rdf/utils/src/main/java/org/apache/clerezza/rdf/utils/GraphNode.java] * [Apache OODT|https://github.com/apache/oodt/blob/1ae92425ec3e7e0d0f026cbcc142ab17988cd071/workflow/src/main/java/org/apache/oodt/cas/workflow/structs/Graph.java] * [Apache Atlas|https://github.com/apache/incubator-atlas/blob/ee8c81df45801fa3798c19f3999b635140e835f7/graphdb/api/src/main/java/org/apache/atlas/repository/graphdb/AtlasGraph.java] * [Apache Geode|https://github.com/apache/geode/blob/3b90f9f9beca0ec5f9cb5c2ad19e2cc97926b569/geode-core/src/main/java/org/apache/geode/internal/sequencelog/model/Graph.java] * [Apache Giraph|http://giraph.apache.org/] * [Apache Tajo|https://github.com/apache/tajo/blob/4f35c28e8e0281beed0a457244fbb9144e791fee/tajo-common/src/main/java/org/apache/tajo/util/graph/Graph.java] * [Apache Struts|https://github.com/apache/struts/blob/cf7bfe63e25589edf2cb1a7ed23bb134348a90e4/plugins/sitegraph/src/main/java/org/apache/struts2/sitegraph/model/Graph.java] * [Apache Cayenne|https://github.com/apache/cayenne/blob/f7ef3e40911055e22464de700fa454483085aab5/cayenne-di/src/main/java/org/apache/cayenne/di/spi/DIGraph.java] * [Apache Calcite|https://github.com/apache/calcite/blob/dac513ab446ad7cfed4be7858721659591134a00/core/src/main/java/org/apache/calcite/util/graph/Graphs.java] * [Apache Stanbol|https://github.com/apache/stanbol/blob/d1500ffba507dce0e43f228342aad97cae7cb0e3/commons/indexedgraph/src/main/java/org/apache/stanbol/commons/indexedgraph/IndexedGraph.java] * [Apache Maven|https://github.com/apache/maven/tree/a1fe42199565f76007a97f47cd4a848fd9b63482/maven-core/src/main/java/org/apache/maven/graph] * [Apache Flink|https://github.com/apache/flink/tree/709f23e742b094a5337c9333a17de7dbdc924891/flink-libraries/flink-gelly/src/main/java/org/apache/flink/graph] It may be easier to design the library for a few of these cases within ASF, and perhaps contact the projects to see if there would be interest in using the commons library. I am involved with Apache Jena, and would be happy to look at [graph] again in a few months, see if it would be a good idea to use it in the project, and suggest it to the other devs to review the idea. Someday I would like to try writing a De Bruijn graph with [text] (lyndon words) + [graph] (graph API and algorithms). This would have a practical application in bioinformatics, for de novo sequence analysis with short reads/shotgun sequencing. Cheers Bruno > Implementation of algorithms available in other libraries > - > > Key: SANDBOX-458 > URL: https://issues.apache.org/jira/browse/SANDBOX-458 > Project: Commons Sandbox > Issue Type: Wish > Components: Graph >Reporter: Oliver Kopp >Priority: Minor > Attachments: Implemented Algorithms.csv, Implemented Algorithms.pdf > > > I made a quick analysis of existing algorithms in other OSS graph libraries. > When these algorithms are also implemented in Apache Commons Graph, this > should make switching libraries easier. Attached a CSV and a PDF showing the > results. > The analyzed libraries are: > jBPT > * License: LGPL > * Homepage: https://code.google.com/p/jbpt/ > * Repo: http://jbpt.googlecode.com/svn/trunk/ > JGraphT > * License: LGPL (possibly soon EPL, too) > * Homepage: http://jgrapht.org/ > * Repo: git://github.com/jgrapht/jgrapht.git > JUNG2 > * License: BSD (1 lib: LGPL) >* http://jung.sourceforge.net/faq.html#license >* packages hep.aida.* are LGPL, imported via the COLT
[jira] [Closed] (DAEMON-368) Add DEBUG and ERROR logging to help diagnose problems when starting a Windows Service
[ https://issues.apache.org/jira/browse/DAEMON-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed DAEMON-368. --- Resolution: Fixed Fix Version/s: 1.1 In svn trunk. > Add DEBUG and ERROR logging to help diagnose problems when starting a Windows > Service > - > > Key: DAEMON-368 > URL: https://issues.apache.org/jira/browse/DAEMON-368 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun > Environment: java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.1 > > > Add DEBUG and ERROR logging to help diagnose problems when starting a service. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DAEMON-368) Add DEBUG and ERROR logging to help diagnose problems when starting a Windows Service
[ https://issues.apache.org/jira/browse/DAEMON-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated DAEMON-368: Summary: Add DEBUG and ERROR logging to help diagnose problems when starting a Windows Service (was: Add DEBUG and ERROR logging to help diagnose problems when starting a service) > Add DEBUG and ERROR logging to help diagnose problems when starting a Windows > Service > - > > Key: DAEMON-368 > URL: https://issues.apache.org/jira/browse/DAEMON-368 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun > Environment: java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) >Reporter: Gary Gregory >Assignee: Gary Gregory > > Add DEBUG and ERROR logging to help diagnose problems when starting a service. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DAEMON-368) Add DEBUG and ERROR logging to help diagnose problems when starting a service
Gary Gregory created DAEMON-368: --- Summary: Add DEBUG and ERROR logging to help diagnose problems when starting a service Key: DAEMON-368 URL: https://issues.apache.org/jira/browse/DAEMON-368 Project: Commons Daemon Issue Type: Improvement Components: Procrun Environment: java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) Reporter: Gary Gregory Assignee: Gary Gregory Add DEBUG and ERROR logging to help diagnose problems when starting a service. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-544) Should FileUtils.copyFile be flushed and synced before comparing file sizes?
[
https://issues.apache.org/jira/browse/IO-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078710#comment-16078710
]
Sean Poulter commented on IO-544:
-
Well, your hunch was right Bernd and I'm confused. Instead of a 0 length file,
Files.copy is reporting that the destination file is in use:
{{java.nio.file.FileSystemException: C:\...\file -> \\Machine2\...\file: The
process cannot access the file because it is being used by another process.}}
> Should FileUtils.copyFile be flushed and synced before comparing file sizes?
>
>
> Key: IO-544
> URL: https://issues.apache.org/jira/browse/IO-544
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.5
> Environment: Win Server 2008, x86
>Reporter: Sean Poulter
>
> I've been struggling to troubleshoot intermittent {{IOExceptions}} thrown
> from {{FileUtils.doCopyFile}} when copying 2-4KB files from a local temporary
> file to a network drive. Despite the error, the file appears on the network
> drive when I check. Should the output channel/buffer be forced/flushed before
> closing, and synchronized before comparing the file lengths? It's a rather
> intermittent issue on a relatively high throughput PC so I'd expect there to
> be more IO latency than normal.
> I found myself referencing:
> * [The source code for FileUtils
> v2.5|https://commons.apache.org/proper/commons-io/javadocs/api-2.5/src-html/org/apache/commons/io/FileUtils.html]
> *
> [FileChannel#force(boolean)|https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileChannel.html#force-boolean-]
> * [IO-443 - FileUtils.copyFile methods throw an unnecessary "Failed to copy
> full contents from" exception|https://issues.apache.org/jira/browse/IO-443]
> Thanks,
> Sean
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IO-544) Should FileUtils.copyFile be flushed and synced before comparing file sizes?
[
https://issues.apache.org/jira/browse/IO-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075759#comment-16075759
]
Sean Poulter edited comment on IO-544 at 7/7/17 9:20 PM:
-
I'm good to mark this resolved.
We've got a paper trail if anyone else happens upon this edge case and the two
workaround - polling to update the stale cache or the
[java.nio.file.*Files.copy(Path, Path,
...)*|https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html].
was (Author: seanpltr):
I'm good to mark this resolved.
We've got a paper trail if anyone else happens upon this edge case and the two
workaround - polling to update the stale cache or the
[java.nio.file.Files#copy(Path, Path,
...)|https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html].
> Should FileUtils.copyFile be flushed and synced before comparing file sizes?
>
>
> Key: IO-544
> URL: https://issues.apache.org/jira/browse/IO-544
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.5
> Environment: Win Server 2008, x86
>Reporter: Sean Poulter
>
> I've been struggling to troubleshoot intermittent {{IOExceptions}} thrown
> from {{FileUtils.doCopyFile}} when copying 2-4KB files from a local temporary
> file to a network drive. Despite the error, the file appears on the network
> drive when I check. Should the output channel/buffer be forced/flushed before
> closing, and synchronized before comparing the file lengths? It's a rather
> intermittent issue on a relatively high throughput PC so I'd expect there to
> be more IO latency than normal.
> I found myself referencing:
> * [The source code for FileUtils
> v2.5|https://commons.apache.org/proper/commons-io/javadocs/api-2.5/src-html/org/apache/commons/io/FileUtils.html]
> *
> [FileChannel#force(boolean)|https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileChannel.html#force-boolean-]
> * [IO-443 - FileUtils.copyFile methods throw an unnecessary "Failed to copy
> full contents from" exception|https://issues.apache.org/jira/browse/IO-443]
> Thanks,
> Sean
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078527#comment-16078527
]
Amey Jadiye commented on TEXT-97:
-
In that case we have {{.selectFrom()}} API, All I'm expecting is to have
different API available in different situations, I understand that only
{{.selectFrom()}} is enough but others provide more flexibility to existing API.
Few and selected characters : {{.selectFrom(char ... chars)}} // like "I need
just few special chars"
Single range : {{.withinRange(int min , int max)}} //like "I want only numeric"
Multiple ranges : {{.withinRange(final char[] ... pairs)}} //like "I want
alphanumeric"
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-638) FileObject.hasChildren()
[ https://issues.apache.org/jira/browse/VFS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078342#comment-16078342 ] Gary Gregory commented on VFS-638: -- We welcome patches, with unit tests of course ;-) > FileObject.hasChildren() > > > Key: VFS-638 > URL: https://issues.apache.org/jira/browse/VFS-638 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Guido Schnepp >Priority: Minor > > It would be great to get new fail-fast hasChildren() method to dertmine if a > FileObject really has Children or not. You often only need to know if a > FileObject has minimum one child but don't need to know how many. > I've tried to simulate this in different ways: > # fo.getChildren().size() > 0 returns the whole list first and therefore > takes some time to get the basic information. Too long for only this > information > # fo.iterator().next() != fo; (iterator returns the original fo as last child > again so you need to check if there are other file objects in folder) doesn't > work either, because the iterator also collects all children before, many > also these from the subfolders. > # fo.getType().hasChildren() is nothing more than a static flag in an > enumeration of types with no real life information > Many thanks in advance > Guido -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078079#comment-16078079
]
Gilles commented on TEXT-97:
What if the wanted selection of characters is not represented by range(s)?
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1344) exclude empty parts in DurationFormatUtils
[
https://issues.apache.org/jira/browse/LANG-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregor B. Rosenauer updated LANG-1344:
--
Description:
{{DurationFormatUtils}} only allow to exclude leading or trailing zeroes, but
not empty parts alltogether, e.g. when a position is 0 (0 days or hours).
This would improve readability and look better in most cases where the duration
can vary between seconds or days and I don't want to special case, e.g. having
it print
{{2s}} instead of {{0d 0h 00m 02s}}.
was:
}}DurationFormatUtils only allow to exclude leading or trailing zeroes, but not
empty parts alltogether, e.g. when a position is 0 (0 days or hours).
This would improve readability and look better in most cases where the duration
can vary between seconds or days and I don't want to special case, e.g. having
it print
{{2s}} instead of {{0d 0h 00m 02s}}.
> exclude empty parts in DurationFormatUtils
> --
>
> Key: LANG-1344
> URL: https://issues.apache.org/jira/browse/LANG-1344
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
>Affects Versions: 3.6
>Reporter: Gregor B. Rosenauer
>Priority: Minor
>
> {{DurationFormatUtils}} only allow to exclude leading or trailing zeroes, but
> not empty parts alltogether, e.g. when a position is 0 (0 days or hours).
> This would improve readability and look better in most cases where the
> duration can vary between seconds or days and I don't want to special case,
> e.g. having it print
> {{2s}} instead of {{0d 0h 00m 02s}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078058#comment-16078058
]
Rob Tompkins commented on TEXT-97:
--
Ohno strong opinions here...the input validation is the only point to keep
in mind, I think. If we do go with the current pull request design, we'd
probably want more input validation and accompanying documentation.
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078054#comment-16078054
]
Rob Tompkins commented on TEXT-97:
--
Based on what [~erans] said above, it almost makes sense to have
{code:java}
addRangeToAlphabet(char rangeMin, char rangeMax)
{code}
to avoid the need for input validation. I also quite like the
{code:java}
RandomStringGenerator randAlphaNum = new RandomStringGenerator.Builder()
.selectFrom(lowerCaseAscii(),
upperCaseAscii(),
decimalDigits()).build();
{code}
idea. Is there an argument against:
{code:java}
RandomStringGenerator randAlphaNum = new RandomStringGenerator.Builder()
. addRangeToAlphabet('a','z')
. addRangeToAlphabet('A','Z')
. addRangeToAlphabet('0','9').build();
{code}
aside from the single line bit?
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078039#comment-16078039 ] ASF GitHub Bot commented on CLI-217: Github user rubin55 commented on the issue: https://github.com/apache/commons-cli/pull/15 Yes, I did see that PosixParser was also a part of the patch, but I thought not to touch it since it's marked as Deprecated (I would not expect changes to deprecated classes as a user at least). > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078038#comment-16078038 ] ASF GitHub Bot commented on CLI-217: Github user rubin55 commented on the issue: https://github.com/apache/commons-cli/pull/15 Yes, I did see that PosixParser was also a part of the patch, but I thought not to touch it since it's marked as Deprecated (I would not expect changes to deprecated classes as a user at least). > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078033#comment-16078033
]
ASF GitHub Bot commented on TEXT-97:
Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/55
Yeah, will see if we can simplify API in 2.x .
I need opinion on the method I have given in this PR, According to me it's
good addition to existing API but go through JIRA discussion once.
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078030#comment-16078030
]
ASF GitHub Bot commented on TEXT-97:
Github user jbduncan commented on the issue:
https://github.com/apache/commons-text/pull/55
Revisiting this in 2.x sounds good to me!
The only other thought I have is that I think this should go up as a new
issue on Apache JIRA if it hasn't already.
Other than that, everything LGTM.
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078016#comment-16078016 ] ASF GitHub Bot commented on CLI-217: Github user chtompki commented on the issue: https://github.com/apache/commons-cli/pull/15 Looking at [CLI-217.patch](https://issues.apache.org/jira/secure/attachment/12568952/CLI-217.patch), I was wondering if we shouldn't also include changes to `PosixParser`? The changes would be at https://github.com/apache/commons-cli/blob/master/src/main/java/org/apache/commons/cli/PosixParser.java#L127 and https://github.com/apache/commons-cli/blob/master/src/main/java/org/apache/commons/cli/PosixParser.java#L134 based on the bottom of that patch file. No worries if there is a distinct reason for not including those, just curious if you saw that in the patch. > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078017#comment-16078017 ] ASF GitHub Bot commented on CLI-217: Github user chtompki commented on the issue: https://github.com/apache/commons-cli/pull/15 Looking at [CLI-217.patch](https://issues.apache.org/jira/secure/attachment/12568952/CLI-217.patch), I was wondering if we shouldn't also include changes to `PosixParser`? The changes would be at https://github.com/apache/commons-cli/blob/master/src/main/java/org/apache/commons/cli/PosixParser.java#L127 and https://github.com/apache/commons-cli/blob/master/src/main/java/org/apache/commons/cli/PosixParser.java#L134 based on the bottom of that patch file. No worries if there is a distinct reason for not including those, just curious if you saw that in the patch. > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078009#comment-16078009 ] ASF GitHub Bot commented on CLI-217: Github user chtompki commented on the issue: https://github.com/apache/commons-cli/pull/15 Yes aside from the `.gitignore` changes, this all looks quite reasonable. > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078008#comment-16078008 ] ASF GitHub Bot commented on CLI-217: Github user chtompki commented on the issue: https://github.com/apache/commons-cli/pull/15 Yes aside from the `.gitignore` changes, this all looks quite reasonable. > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Attachments: CLI-217.patch, optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16077995#comment-16077995
]
ASF GitHub Bot commented on TEXT-97:
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/55
@jbduncan has a point here, but the code here does conform to the style of
the existing code. So, I'd lean more towards the changes @ameyjadiye is
proposing mainly because to re-work the code into a static `builder()` method
pattern would require changes that would necessitate a major version change. We
could, though, revisit this in the 2.X version if you with @jbduncan. Thoughts?
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (VFS-638) FileObject.hasChildren()
Guido Schnepp created VFS-638: - Summary: FileObject.hasChildren() Key: VFS-638 URL: https://issues.apache.org/jira/browse/VFS-638 Project: Commons VFS Issue Type: New Feature Affects Versions: 2.1 Reporter: Guido Schnepp Priority: Minor It would be great to get new fail-fast hasChildren() method to dertmine if a FileObject really has Children or not. You often only need to know if a FileObject has minimum one child but don't need to know how many. I've tried to simulate this in different ways: # fo.getChildren().size() > 0 returns the whole list first and therefore takes some time to get the basic information. Too long for only this information # fo.iterator().next() != fo; (iterator returns the original fo as last child again so you need to check if there are other file objects in folder) doesn't work either, because the iterator also collects all children before, many also these from the subfolders. # fo.getType().hasChildren() is nothing more than a static flag in an enumeration of types with no real life information Many thanks in advance Guido -- This message was sent by Atlassian JIRA (v6.4.14#64029)
