Is one upshot of this is that we should base the version number based on
this OSGi report tool?
Gary
On Jun 11, 2017 1:58 PM, "Simon Spero" wrote:
> On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory
> wrote:
>
> > My POV is that I only see a possible use cases for this in multi-module
> > componen
GitHub user sesuncedu opened a pull request:
https://github.com/apache/commons-compress/pull/30
COMPRESS-407 - Validate Block and Record Sizes and use 512 blocks if none
given.
This PR includes the commits for COMPRESS-405 and COMPRESS-406.
The new content is
https://g
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-text/pull/41
Let's merge this!
---
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
On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory
wrote:
> My POV is that I only see a possible use cases for this in multi-module
> components where one module defines an API and others different
> implementation. Our release process is enough of a pain. Asking everyone
> to consider if a change war
Le 11/06/2017 à 21:16, Gary Gregory a écrit :
> Can you show us a real problem that this would have solved?
+1, I don't understand what actual issue it would solve with
commons-compress.
Emmanuel Bourg
-
To unsubscribe, e-mail:
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/42
Will look over this again tomorrow early.
---
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 fea
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/46
Will look this over in the morning.
---
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
e
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/45
Agreed. Will pull this in tonight or in the morning (UTC-4)
---
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
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/47
Cool. I'll get to this point n the morning.
---
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 f
Github user britter commented on a diff in the pull request:
https://github.com/apache/commons-cli/pull/12#discussion_r121290023
--- Diff:
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
Github user britter commented on a diff in the pull request:
https://github.com/apache/commons-cli/pull/12#discussion_r121290023
--- Diff:
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
My POV is that I only see a possible use cases for this in multi-module
components where one module defines an API and others different
implementation. Our release process is enough of a pain. Asking everyone to
consider if a change warrants a package version change is a pain. I still
do not see wh
Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/45
@chtompki, I think we are good to merge this.
---
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 thi
Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.
+1
Oliver
Am 09.06.2017 um 11:56 schrieb Benedikt Ritter:
> Hello,
>
> we have fixed quite a few bugs and added some nice new features since Commons
> Lang 3.5 was released, so I would like to release Commons L
Hi Gilles,
On Thursday 08 June 2017 03:22 AM, Gilles wrote:
> Hello.
>
> On Wed, 7 Jun 2017 23:52:59 +0530, Amey Jadiye wrote:
>> Hi,
>>
>> I was trying to run all checks on commons-number and found findbug is
>> failing in Precision.java[544] FE_FLOATING_POINT_EQUALITY
>>
>> {code}
>> case BigDec
So what's the current thinking on using compatibility-verified package
versioning (for commons-* in general, but COMPRESS-399 in particular?)
It doesn't take much work, and incorrect package versions cause real
problems.
*You added the headers and here I am. You tell 'em I'M coming... and Jar
H
Github user arunvinudss commented on the issue:
https://github.com/apache/commons-text/pull/47
@chtompki Added test cases to improve line coverage .
---
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
Github user sesuncedu commented on the issue:
https://github.com/apache/commons-compress/pull/29
Pleasing the rat has awakened the coveralls.
---
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
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/47
[![Coverage
Status](https://coveralls.io/builds/11922169/badge)](https://coveralls.io/builds/11922169)
Coverage increased (+0.3%) to 96.924% when pulling
**65f5889f501f784264606f
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/47
[![Coverage
Status](https://coveralls.io/builds/11922169/badge)](https://coveralls.io/builds/11922169)
Coverage increased (+0.3%) to 96.924% when pulling
**65f5889f501f784264606f
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/47
[![Coverage
Status](https://coveralls.io/builds/11922169/badge)](https://coveralls.io/builds/11922169)
Coverage increased (+0.3%) to 96.924% when pulling
**65f5889f501f784264606f
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/29
[![Coverage
Status](https://coveralls.io/builds/11922155/badge)](https://coveralls.io/builds/11922155)
Changes Unknown when pulling **135b0b7743633427b09c6c7c90d7809749c9a2fa
GitHub user arunvinudss opened a pull request:
https://github.com/apache/commons-text/pull/47
Improved test coverage for StrTokenizer
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/arunvinudss/commons-text improveTestCoverage
A
GitHub user sesuncedu opened a pull request:
https://github.com/apache/commons-compress/pull/29
COMPRESS-406 BUILDING.md is missing license header
Signed-off-by: Simon Spero
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sesunce
GitHub user sesuncedu opened a pull request:
https://github.com/apache/commons-compress/pull/28
COMPRESS-405 Create Fixed Length Block OutputStream / WriteableByteChannel
This PR provides a new class that is an OutputStream and
WritableByteChannel, and which supports writing to
Github user sebbASF commented on the issue:
https://github.com/apache/commons-text/pull/46
I've just realised: this issue is about adding CaseUtils.toCamelCase.
Problems with WordUtils belong in a separate issue or JIRA
---
If your project is set up for it, you can reply to this e
Github user arunvinudss commented on the issue:
https://github.com/apache/commons-text/pull/46
@sebbASF Nope the first letter is not capitalized and I expected the same
. It seems to happen if the specified delimiters are not available on the input
though .
---
If your project is s
Github user sebbASF commented on the issue:
https://github.com/apache/commons-text/pull/46
An empty delimiter array means the caller does not want any delimiters to
be used.
But I would expect the output to capitalise the first letter:
WordUtils.capitalizeFully("i am fine"
Github user arunvinudss commented on the issue:
https://github.com/apache/commons-text/pull/46
@chtompki Just wondering why space is added as a default delimiter for null
delimiter arrays but not for empty delimiter array in WordUtils.capitalizeFully
.
WordUtils.capitalizeFul
Github user arunvinudss commented on the issue:
https://github.com/apache/commons-text/pull/46
@chtompki The current implementation is based on these assumptions.
- All delimiters are stripped off .
- Space(32) is added as the default delimiter for all scenarios including
Github user arunvinudss commented on the issue:
https://github.com/apache/commons-text/pull/46
@chtompki Using HashSets for checking delimiters it reduces the time
complexity from O(nk) to O(n) . I feel it's more efficient .
---
If your project is set up for it, you can reply to thi
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/46
[![Coverage
Status](https://coveralls.io/builds/11920859/badge)](https://coveralls.io/builds/11920859)
Coverage increased (+0.04%) to 96.691% when pulling
**2de01ba6a343ffcce6737
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/46
[![Coverage
Status](https://coveralls.io/builds/11920859/badge)](https://coveralls.io/builds/11920859)
Coverage increased (+0.04%) to 96.691% when pulling
**2de01ba6a343ffcce6737
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/46
[![Coverage
Status](https://coveralls.io/builds/11920859/badge)](https://coveralls.io/builds/11920859)
Coverage increased (+0.04%) to 96.691% when pulling
**2de01ba6a343ffcce6737
GitHub user arunvinudss opened a pull request:
https://github.com/apache/commons-text/pull/46
TEXT-85:Added CaseUtils class with camel case conversion support
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/arunvinudss/commons-te
35 matches
Mail list logo