fair enough not to remove keys ;) , Thanks.
Regards,
Amey
On Wed, Jul 19, 2017, 1:32 AM Stefan Bodewig wrote:
> On 2017-07-18, Amey Jadiye wrote:
>
> > I observed we have lot of keys in
> https://www.apache.org/dist/commons/KEYS,
> > even keys of developers who might have
>
> Yes, of course, that's one way to go and also create a bunch of methods to
> delegate to the wrapped Properties... BUT I cannot pass this object to a
> method typed with "Properties".
>
Oh, that's a fair point. You've convinced me. :)
On 18 July 2017 at 23:44, Gary Gregory
Hi All,
A comment more than anything:
In our DBCP 1.7 RC2 VOTE email thread in progress now, you can read:
=
On Tue, Jul 18, 2017 at 1:13 PM, Oliver Heger
wrote:
> Build works fine with Java 1.6 and 1.8 on Windows 10. Artifacts and site
> look good.
On Tue, Jul 18, 2017 at 1:13 PM, Oliver Heger
wrote:
> Build works fine with Java 1.6 and 1.8 on Windows 10. Artifacts and site
> look good.
>
> There is a bunch of checkstyle errors, especially in
> BaseResultSetHandler.java; but I assume they have been in there
On Tue, Jul 18, 2017 at 1:16 PM, Oliver Heger
wrote:
>
>
> Am 18.07.2017 um 20:39 schrieb Gary Gregory:
> > On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins
> wrote:
> >
> >>
> >>
> >>> On Jul 18, 2017, at 4:43 AM, Jörg Schaible
On Tue, Jul 18, 2017 at 1:02 PM, Stefan Bodewig wrote:
> On 2017-07-18, Amey Jadiye wrote:
>
> > I observed we have lot of keys in https://www.apache.org/dist/
> commons/KEYS,
> > even keys of developers who might have resigned from commons, can we just
> > review and remove
GitHub user Xaerxess opened a pull request:
https://github.com/apache/commons-collections/pull/25
COLLECTIONS-575: Add synchronized queue wrapper
Added QueueUtils#synchronizedQueue(Queue) wrapper and SynchronizedQueue
with tests. Please check if I used proper conventions as it's my
Am 18.07.2017 um 20:39 schrieb Gary Gregory:
> On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins wrote:
>
>>
>>
>>> On Jul 18, 2017, at 4:43 AM, Jörg Schaible > com> wrote:
>>>
>>> Hi Gary,
>>>
>>> Gary Gregory wrote:
>>>
Hi,
I'd to
Build works fine with Java 1.6 and 1.8 on Windows 10. Artifacts and site
look good.
There is a bunch of checkstyle errors, especially in
BaseResultSetHandler.java; but I assume they have been in there before,
so not a blocker.
+1, good work!
Oliver
Am 17.07.2017 um 00:41 schrieb Carl Hall:
>
On 2017-07-18, Amey Jadiye wrote:
> I observed we have lot of keys in https://www.apache.org/dist/commons/KEYS,
> even keys of developers who might have resigned from commons, can we just
> review and remove keys of developers who resigned or no more active ?
We shouldn't remove any key that
Github user asfgit closed the pull request at:
https://github.com/apache/commons-text/pull/49
---
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
On Jul 18, 2017 2:25 PM, "Rob Tompkins" wrote:
I'm stuck in the in-between here with the following thought: HashTable
certainly feels like a collection of objects, but it clearly extends
Dictionary and isn't in the collections family. But we are in java.util
here and not in
Github user marko-bekhta commented on the issue:
https://github.com/apache/commons-collections/pull/18
Hi @chtompki there seems nothing to rebase now. The patch was copied and
applied here
On Tue, Jul 18, 2017 at 11:25 AM, Rob Tompkins wrote:
>
>
> > On Jul 18, 2017, at 4:43 AM, Jörg Schaible com> wrote:
> >
> > Hi Gary,
> >
> > Gary Gregory wrote:
> >
> >> Hi,
> >>
> >> I'd to have a new class called SortedProperties that extends
Github user jbduncan commented on the issue:
https://github.com/apache/commons-text/pull/56
@TheRealHaui Yes, precisely. :)
(With hindsight, I should have used the word "violations" instead of
"cases"; it would have been clearer that I was referring to the errors that
How about developers who resigned ? It means whoever sent mail that they
are not willing to be the part of community.?
I think keeping keys of non-active developers of Ok.
Ex.
James have resigned http://commons.markmail.org/message/i2davy3nf4fr7xqp
But I can see his key.
pub 1024D/9EEDB2D5
> On Jul 18, 2017, at 2:25 PM, Gary Gregory wrote:
>
> There is no criteria for "not active"; either you are a committer or you
> are not per: https://people.apache.org/phonebook.html?unix=commons
>
It feels like a bad idea because we may have very old releases that
I would strongly discourage subclassing `Properties` and instead I'd
encourage composing it into the proposed `SortedProperties` class, as
subclassing classes which weren't designed for inheritance is risky
according to Effective Java 2nd Edition, Items 16 and 17.
So for example:
```
public final
Also, the KEYS list can include ANY Apache Committer, not just members
Apache Commons.
IOW, I think the only people to remove are people that no longer are Apache
Committers.
Gary
On Tue, Jul 18, 2017 at 11:25 AM, Gary Gregory
wrote:
> There is no criteria for "not
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/49
Cool. Will look at this in just a bit.
---
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
There is no criteria for "not active"; either you are a committer or you
are not per: https://people.apache.org/phonebook.html?unix=commons
Gary
On Tue, Jul 18, 2017 at 11:21 AM, Amey Jadiye wrote:
> I observed we have lot of keys in
> On Jul 18, 2017, at 4:43 AM, Jörg Schaible
> wrote:
>
> Hi Gary,
>
> Gary Gregory wrote:
>
>> Hi,
>>
>> I'd to have a new class called SortedProperties that extends
>> java.util.Properties.
>>
>> Should that go in [lang] or [collections]?
>>
>> I first
I observed we have lot of keys in https://www.apache.org/dist/commons/KEYS,
even keys of developers who might have resigned from commons, can we just
review and remove keys of developers who resigned or no more active ?
Regards,
Amey
Github user TheRealHaui commented on the issue:
https://github.com/apache/commons-text/pull/56
You mean the cases reported by the checkstyle plugin?
---
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 TheRealHaui commented on a diff in the pull request:
https://github.com/apache/commons-collections/pull/24#discussion_r128054680
--- Diff:
src/test/java/org/apache/commons/collections4/iterators/CollatingIteratorTest.java
---
@@ -16,12 +16,14 @@
*/
package
Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/49
@chtompki , @PascalSchumacher this seems good to me for merge.
---
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
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/56
[![Coverage
Status](https://coveralls.io/builds/12445709/badge)](https://coveralls.io/builds/12445709)
Coverage increased (+1.04%) to 98.34% when pulling
On Tue, Jul 18, 2017 at 11:12 AM, Amey Jadiye wrote:
> Checked RC2, and here is my +1 (non-binding).
>
> 1. Build and Tests are passing clean
> 2. Clirr and Rat looks good.
> 3. Findbug show two DM_DEFAULT_ENCODING warning but non-blocker to release.
> 3. There are few of
Checked RC2, and here is my +1 (non-binding).
1. Build and Tests are passing clean
2. Clirr and Rat looks good.
3. Findbug show two DM_DEFAULT_ENCODING warning but non-blocker to release.
3. There are few of bugs in Checkstyle report but they are non-blocker to
release.
4. Hashes given in files
Nope. All that I want is to write a Properties object with sorted lines.
Simple as that. I do not even need to read a properties file into a
SortedProperties but we can do that as well of course.
This works:
Github user jbduncan commented on the issue:
https://github.com/apache/commons-text/pull/56
Thanks @TheRealHaui!
I think handling the rest of the cases reported by Checkstyle should be
done in a separate PR (or series of PRs if needed) by whoever feels up to it.
---
If your
On Jul 18, 2017 11:39 AM, "Gary Gregory" wrote:
My use case is to write a Properties object in sorted key order, nothing
fancy. The simplest way is to subclass Properties and override keys().
Loading a SortedProperties with a Map is not on my to-do list.
Would your
Github user TheRealHaui commented on the issue:
https://github.com/apache/commons-text/pull/56
Reformatted requested code artifacts.
---
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
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-text/pull/56
@ameyjadiye Try adding the same suppression as commons-lang:
```
```
That should reduce the errors. Maybe their are other checks which can be
reasonably
Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/56
@PascalSchumacher I just enabled in my local, seems very cumbersome task to
me at this point.
```
[INFO] There are 2551 checkstyle errors.
.
.
.
[INFO]
My use case is to write a Properties object in sorted key order, nothing
fancy. The simplest way is to subclass Properties and override keys().
Loading a SortedProperties with a Map is not on my to-do list.
Gary
On Jul 18, 2017 00:41, "Javen O'Neal" wrote:
> +1 for Lang.
>
Yeah, I was confused. Persistent collections have a meaning (e.g., see <
https://pcollections.org/> for a Java library implementation) a bit
different from persistent entities.
On 18 July 2017 at 05:18, Jonathan Bluett-Duncan
wrote:
> Javen,
>
> Just for clarity, by
Github user lamrongol commented on the issue:
https://github.com/apache/commons-collections/pull/15
@chtompki Honestly, I didn't think the effect to other class and can't
predict the effect. I hope experts of this repository decide.
---
If your project is set up for it, you can
Github user chtompki commented on a diff in the pull request:
https://github.com/apache/commons-collections/pull/24#discussion_r127966801
--- Diff:
src/test/java/org/apache/commons/collections4/iterators/CollatingIteratorTest.java
---
@@ -16,12 +16,14 @@
*/
package
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/5
@huseyincelik - Do you mind rebasing this work onto the `master` branch and
opening a new pull request?
---
If your project is set up for it, you can reply to this email and have your
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/9
@gonmarques - Do you mind rebasing this work onto the `master` branch and
opening a new pull request?
---
If your project is set up for it, you can reply to this email and have your
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/10
@AndersDJohnson - Do you mind rebasing this work on the `master` branch and
opening a new pull request?
---
If your project is set up for it, you can reply to this email and have your
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/13
@kaching88 - Do you mind rebasing to the `master` branch and re-opening
this pull request?
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/15
@lamrongol - Do you mind rebasing to the `master` branch, and re-opening
this pull request?
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/18
@marko-bekhta - Do you mind rebasing to the `master` branch, and re-opening
this pull request?
---
If your project is set up for it, you can reply to this email and have your
reply
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/19
@Xaerxess - As posted in the [Jira
Issue](https://issues.apache.org/jira/browse/COLLECTIONS-575), do you mind
rebasing to master and re-opening this pull request?
---
If your project
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/21
@mureinik - Do you mind rebasing to master and re-opening this pull request?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/22
@jonasholtkamp - Do you mind rebasing to master and re-opening this pull
request?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/3
@geoffschoeman - Do you mind rebasing to master and re-opening this pull
request?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user chtompki commented on the issue:
https://github.com/apache/commons-collections/pull/12
Do you mind rebasing to master and re-opening this pull request?
---
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
+1
Checked ASC/SHA1 for all artifacts. All ok.
RAT and CLIRR check OK
New issues found:
- Reported in previous email, typographic error on SHA1 on jar file (namely
commons-dbutils-1.7.jar). But, all is correct in nexus, so no worries to me.
-Rob
> On Jul 16, 2017, at 6:41 PM, Carl Hall
Note:
The SHA1 listed in the email below for "commons-dbutils-1.7.jar” does not match
the SHA1 "a2d6e515aa87e5d38f6b3003e70b13c1b1f19ca0” of the artifact in the
Apache Nexus instance. However, the commons-dbutils-1.7.jar.sha1 does contain
the correct SHA1, so it seems to be a typographic error
Javen,
Just for clarity, by persistent collections, are you talking about
_functional_ persistent collections (a la Scala, Clojure and Haskell),
_disk_-persisted collections, or some other definition of "persistent"?
Jonathan
On 18 Jul 2017 08:41, "Javen O'Neal" wrote:
+1
Hi Gary,
Gary Gregory wrote:
> Hi,
>
> I'd to have a new class called SortedProperties that extends
> java.util.Properties.
>
> Should that go in [lang] or [collections]?
>
> I first thought [lang], but it _is_ a collection after all.
>
> Gary
for me it's [collections]. [collections] is
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-text/pull/56
@jbduncan Check-style for commons-text does is currently not applied to
tests. I think we should look into enabling it.
@TheRealHaui Please fix the things @jbduncan suggested.
+1 for Lang.
There aren't any persistent data structures in Collections, nor would I
think to look in Collections to find one.
Properties is a persistent hashtable. SortedProperties is a persistent
TreeMap.
Unless you're thinking about a new family of SortedProperties. Were you
thinking about
My opinion is this should go to *lang* because the fact is it's extended
utility and not exactly as data structures though it looks like one. It's
main purpose is to hold properties and not the data. Commons collection
aims to provide utlilities and extension to data structures and not to
Hi,
I'd to have a new class called SortedProperties that extends
java.util.Properties.
Should that go in [lang] or [collections]?
I first thought [lang], but it _is_ a collection after all.
Gary
58 matches
Mail list logo