Re: New Sub-project Proposal.

[Claude Warren]

Actually the code I was thinking of is the multi-filter branch.  It cleans
up some names and simplifies a few things.  The collections and storage
packages might be best added as examples rather than as mainline code.

In this case we just provide the bloom filter implementation,  If we want
to provide the container implementation then I think it should probably be
modified to accept any SortedSet or NavigatableSet in the constructor.

When I return home, next week, I'll take a swipe at moving the packages
over to org.apache.commons.collections4.bloomfilter package (unless there
is a better package name).  We can then look at the entire code donation
and decide what changes need to be made before it is accepted.

Does this sound like a reasonable approach?

Claude

On Thu, Sep 12, 2019 at 2:34 AM Gary Gregory  wrote:

> So is the idea to provide wrappers on Sets or a Set implementation?
>
> Gary
>
> On Wed, Sep 11, 2019 at 3:54 PM Stian Soiland-Reyes 
> wrote:
>
> > I certainly got thinking about streams for those methods using the ancy
> > integrators yes. Commons Collection is already on JDK8, so if that is
> > sufficient, go for it!
> >
> > We would need to do IP clearance to bring in the code formally to ASF. It
> > should be easy if it is just you who made it under Apache license.
> >
> > On Wed, 11 Sep 2019, 18:44 Claude Warren,  wrote:
> >
> > > @stain. You have correctly identified the code in my repository.  The
> > code
> > > could be refactored to use streams or we could bring the jena iterator
> > > extensions into commons.  I had suggested that at one time but there
> were
> > > concerns about conflicts with existing code.  Duplication with of
> > > functionality was the main concern as I recall.
> > >
> > > Claude
> > >
> > > On Wed, Sep 11, 2019, 09:43 Stian Soiland-Reyes 
> > wrote:
> > >
> > > > On Wed, 11 Sep 2019 18:12:24 +0200, Gilles Sadowski <
> > > gillese...@gmail.com>
> > > > wrote:
> > > > > > The long and short of this is that there is no good unencumbered
> > open
> > > > > > source library available at the current time.  Myself and several
> > > > others,
> > > > > > in conversation here at ApacheCon, have expressed interest in
> > > creating
> > > > such
> > > > > > a library.  We have fairly mature code that we are willing to
> > > > contribute
> > > > > > along with code that embodies new thinking in the bloom filter
> > arena
> > > > (like
> > > > > > proto-bloom filters).  We just need a space within the Apache
> > family
> > > to
> > > > > > host it.  The code base seems to small to be a separate project
> and
> > > so
> > > > we
> > > > > > come to Apache Commons seeking a home.
> > > > >
> > > > > IMO, a pretty compelling rationale for hosting it at "Commons".
> > > > > If people think that [Collections] would be the best home, I'd
> > suggest
> > > > > making that component modular; hence unnecessary dependencies
> > > > > would be a non-issue.
> > > >
> > > > Thanks Claude for that brilliant explanation about bloom filter!
> > > > (please blog it!)
> > > >
> > > > At the moment Commons Collections have no runtime dependencies, and
> > only
> > > > 3 test-dependencies.
> > > > <
> > https://github.com/apache/commons-collections/blob/master/pom.xml#L443>
> > > >
> > > > So unless the Bloom filter code comes with any new depdendencies seen
> > to
> > > > "bloat" rest of Commons, it could fit well in there.
> > > >
> > > > It would be a new package "bloom" as it's something to use for
> building
> > > > collections rather than directly being a collection - but Collections
> > > > already have similar packages for balanced trees, etc.
> > > >
> > > >
> > > > Looking at the code which I suspect is
> > > > <
> > > >
> > >
> >
> https://github.com/Claudenw/BloomFilter/tree/master/src/main/java/org/xenei/bloomfilter
> > > > >
> > > > it looks pretty clean, independent and straight forward to read and
> > > > understand.
> > > >
> > > > From Claude's email I see it is it's *use* that needs explanation!
> > > >
> > > > The only dependencies in that code seem to be within the
> > > > org.xenei.bloomfilter.collections package which currently include use
> > of
> > > > Jena's extended iterator classes.
> > > >
> > > > This could probably be refactored, if this package is also to be
> > > > included? (those classes would also fit naturally into Collections)
> > > >
> > > >
> > > > --
> > > > Stian Soiland-Reyes
> > > > The University of Manchester 🐝
> > > > https://www.esciencelab.org.uk/
> > > > https://orcid.org/-0001-9842-9718
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> >
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

[ANNOUNCEMENT] Commons Daemon 1.2.1 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.2.1.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.2.1 is a bugfix release.

A full list of changes can be found at
  https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark, on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Stian Soiland-Reyes]

On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren  wrote:
> Actually the code I was thinking of is the multi-filter branch.  It cleans
> up some names and simplifies a few things.  The collections and storage
> packages might be best added as examples rather than as mainline code.
> 
> In this case we just provide the bloom filter implementation,  If we want
> to provide the container implementation then I think it should probably be
> modified to accept any SortedSet or NavigatableSet in the constructor.
> 
> When I return home, next week, I'll take a swipe at moving the packages
> over to org.apache.commons.collections4.bloomfilter package (unless there
> is a better package name).  We can then look at the entire code donation
> and decide what changes need to be made before it is accepted.
> 
> Does this sound like a reasonable approach?

Sounds reasonable to me - then it's easy to see what will be the code
donation, they could be examples at first that we can link to from
documentation, several commons packages have such example codes.


Perhaps use packagename "commons.collections4.bloomfilter" without
org.apache before it's been IP-cleared? Alternatively add it on a fork
of https://github.com/apache/commons-collections/ so we don't confuse
anyone.


I see on your branch you are using some new dependencies like 
org.xenei.blockstorage and org.xenei.spanbuffer.SpanBuffer - would these
be needed as well if we include the container implementation or are they
more for disk-based collections?

-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Gilles Sadowski]

Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a écrit :
>
> On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren  wrote:
> > Actually the code I was thinking of is the multi-filter branch.  It cleans
> > up some names and simplifies a few things.  The collections and storage
> > packages might be best added as examples rather than as mainline code.
> >
> > In this case we just provide the bloom filter implementation,  If we want
> > to provide the container implementation then I think it should probably be
> > modified to accept any SortedSet or NavigatableSet in the constructor.
> >
> > When I return home, next week, I'll take a swipe at moving the packages
> > over to org.apache.commons.collections4.bloomfilter package (unless there
> > is a better package name).  We can then look at the entire code donation
> > and decide what changes need to be made before it is accepted.
> >
> > Does this sound like a reasonable approach?

Any comment about my suggestion to make [Collections] modular,
starting with that code ([Collections] is nearing 30k LOC...)?

Gilles

> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LAZY][VOTE] Release Commons Parent version 49 from RC2

[Alex Herbert]

+1

Tested again using:

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)

Maven home: /usr/local/apache-maven-3.6.0
Java version: 1.8.0_222, vendor: Private Build, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre

Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-161-generic", arch: "amd64", family: 
"unix"


mvn clean install site

OK


Downloaded source bundles and they build OK. Release notes OK. Verified 
GPG signatures.



Verified GPG signatures on maven artifacts.


The dist repo has one sha512 signature file named with .src512: 
commons-parent-49-src.zip.src512.


The SHA512 signatures are good.


Site looks good (Jira, RAT). But the changes report still has two items 
with an unknown type.


You did not fix the broken attribute tags ("type-" not "type") in 
changes.xml on lines 68 and 69. This is not a blocker as they are simple 
typos.



I tried updating commons-rng to locally a installed parent-49 and it 
still works as expected.



Alex


On 12/09/2019 02:22, Rob Tompkins wrote:

We have fixed quite a few bugs and added some significant enhancements since
Apache Commons Parent 48 was released, so I would like to release Apache Commons
Parent 49.

Apache Commons Parent 49 RC2 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2 (svn
revision 35767)

The Git tag commons-parent-49-RC2 commit for this RC is
379376be9a721deaa7bf4f13b5c4680787004524 which you can browse here:
 
https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=379376be9a721deaa7bf4f13b5c4680787004524

You may checkout this tag using:
 git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch
commons-parent-49-RC2

Maven artifacts are here:
 
https://repository.apache.org/content/repositories/orgapachecommons-1468/org/apache/commons/commons-parent/49/

These are the Maven artifacts:

#Nexus SHA-1s
commons-parent-49-site.xml=29a5e6f8a0f8166e791483703a1baa982b21a8ae
commons-parent-49.pom=b9c55a15d726cb9ddb18c6de138b232fa95289e2

#Release SHA-512s
#Wed Sep 11 18:07:15 PDT 2019
commons-parent-49-src-zip=75a9dec81bb6d3c5d0b1889ef3ee022cbd4a9c36ca21e238f136e927da4f2486742445f798a60a69b11e47c2cf6fdaaf81acf499a07ad33f0256e111b0994ded
commons-parent-49-pom=6ee38558cf5ea3893d7cecd4f569405c11cbc14837519139876adb5060351cb545e0f95f609e3358385d98794f5daa8e7bd9fc724d2e5e32da1b666bca1c57b8
commons-parent-49-src-tar.gz=f5a03ff39f3f6b057965ba9759e96f32d51ea9a5e2bbf2831f7cb55b144674865c158e1aa283112f0d502407094887612cb24a270ff558a989cf82da5d9d03e3

I have tested this with 'mvn clean install site' using:
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 
2019-08-27T08:06:16-07:00)
Maven home: /usr/local/Cellar/maven/3.6.2/libexec
Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime: 
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"


Details of changes since 48 are in the release notes:
 
https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/RELEASE-NOTES.txt
 
https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site/changes-report.html

Site:
 https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site
 (note some *relative* links are broken and the 49 directories are not yet
created - these will be OK once the site is deployed.)

RAT Report:
 
https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Rob Tompkins,
Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC:

git clone https://gitbox.apache.org/repos/asf/commons-parent.git -b
commons-parent-49-RC2
cd commons-parent-49-RC2

2) Check Apache licenses:

mvn apache-rat:check

3) Build the package:

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.

4) Build the site for a single module project:

mvn site
Check the site reports in:
target\site\index.html

4) Build the site for a multi-module project:

mvn site
mvn site:stage
Check the site reports in:
target\site\index.html
-
To unsubscribe, e-mail: dev-...@commons.apache.org
For additional commands,

[REPORT] Apache Commons September 2019

[Gary Gregory]

## Description:
The mission of Apache Commons is the creation and maintenance of Java
focused
reusable libraries and components

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache Commons was founded 2007-06-19 (12 years ago)
The committer count and  Committer-to-PMC ratio offered by the Apache
reporting tool is misleading since Apache Commons is open to all Apache
Committer.

Community changes, past quarter:
- No new PMC members. Last addition was Alex Herbert on 2019-05-09.
- No new committers. Last addition was Alex Herbert on 2019-01-30.

## Project Activity:
The project is healthy and active and released 7 components
in this reporting period:
- BEANUTILS-1.9.4 was released on 2019-08-14.
- BUILD-PLUGIN-1.11 was released on 2019-09
- COMPRESS 1.19 was released on 2019-08-27.
- DAEMON-1.2.1 was released on 2019-09-09.
- RELEASE-PLUGIN-1.7 was released on 2019-09-02.
- TEXT-1.8 was released on 2019-09-02.
- VFS-2.4.1 was released on 2019-08-14.

## Community Health:
We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely
manner.

Gary Gregory,
Apache Commons Chair

Re: [REPORT] Apache Commons September 2019

[Nicolas BD]

Hi Gary,
Thanks
When do you think the next release for Lang 3.10 will be ? Is there a
roadmap or schedule somewhere ?

Best regards,
Nicolas

Le jeu. 12 sept. 2019 à 14:36, Gary Gregory  a
écrit :

> ## Description:
> The mission of Apache Commons is the creation and maintenance of Java
> focused
> reusable libraries and components
>
> ## Issues:
> There are no issues requiring board attention.
>
> ## Membership Data:
> Apache Commons was founded 2007-06-19 (12 years ago)
> The committer count and  Committer-to-PMC ratio offered by the Apache
> reporting tool is misleading since Apache Commons is open to all Apache
> Committer.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Alex Herbert on 2019-05-09.
> - No new committers. Last addition was Alex Herbert on 2019-01-30.
>
> ## Project Activity:
> The project is healthy and active and released 7 components
> in this reporting period:
> - BEANUTILS-1.9.4 was released on 2019-08-14.
> - BUILD-PLUGIN-1.11 was released on 2019-09
> - COMPRESS 1.19 was released on 2019-08-27.
> - DAEMON-1.2.1 was released on 2019-09-09.
> - RELEASE-PLUGIN-1.7 was released on 2019-09-02.
> - TEXT-1.8 was released on 2019-09-02.
> - VFS-2.4.1 was released on 2019-08-14.
>
> ## Community Health:
> We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely
> manner.
>
> Gary Gregory,
> Apache Commons Chair
>

Re: [REPORT] Apache Commons September 2019

[Gary Gregory]

On Thu, Sep 12, 2019 at 8:50 AM Nicolas BD  wrote:

> Hi Gary,
> Thanks
> When do you think the next release for Lang 3.10 will be ? Is there a
> roadmap or schedule somewhere ?
>

Hi Nicola,

There is no roadmap or schedule. We have a smallish set of changes stacked
up so I could see doing a release within a month. I need to get a new
release of Commons Config and BCEL out first though.

Please feel free to review open JIRAs and PRs on GitHub if you want to help
make 3.10 better :-)

Gary


> Best regards,
> Nicolas
>
> Le jeu. 12 sept. 2019 à 14:36, Gary Gregory  a
> écrit :
>
> > ## Description:
> > The mission of Apache Commons is the creation and maintenance of Java
> > focused
> > reusable libraries and components
> >
> > ## Issues:
> > There are no issues requiring board attention.
> >
> > ## Membership Data:
> > Apache Commons was founded 2007-06-19 (12 years ago)
> > The committer count and  Committer-to-PMC ratio offered by the Apache
> > reporting tool is misleading since Apache Commons is open to all Apache
> > Committer.
> >
> > Community changes, past quarter:
> > - No new PMC members. Last addition was Alex Herbert on 2019-05-09.
> > - No new committers. Last addition was Alex Herbert on 2019-01-30.
> >
> > ## Project Activity:
> > The project is healthy and active and released 7 components
> > in this reporting period:
> > - BEANUTILS-1.9.4 was released on 2019-08-14.
> > - BUILD-PLUGIN-1.11 was released on 2019-09
> > - COMPRESS 1.19 was released on 2019-08-27.
> > - DAEMON-1.2.1 was released on 2019-09-09.
> > - RELEASE-PLUGIN-1.7 was released on 2019-09-02.
> > - TEXT-1.8 was released on 2019-09-02.
> > - VFS-2.4.1 was released on 2019-08-14.
> >
> > ## Community Health:
> > We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely
> > manner.
> >
> > Gary Gregory,
> > Apache Commons Chair
> >
>

Re: [REPORT] Apache Commons September 2019

[Nicolas BD]

> When do you think the next release for Lang 3.10 will be ? Is there a
> > roadmap or schedule somewhere ?
> >
>
> Hi Nicola,
>
> There is no roadmap or schedule. We have a smallish set of changes stacked
> up so I could see doing a release within a month. I need to get a new
> release of Commons Config and BCEL out first though.
>
>
Ok thanks Gary,
Will do, and maybe suggest another change after the 3.10 : I created a
DiffResultView and DiffView for my project purpose but I'm not sure how
relevant it is for the lib.
I'll make a WIP PR to discuss it

Best,

Nicolas

Re: [REPORT] Apache Commons September 2019

[Gary Gregory]

On Thu, Sep 12, 2019 at 9:23 AM Nicolas BD  wrote:

>
>
> > When do you think the next release for Lang 3.10 will be ? Is there a
>> > roadmap or schedule somewhere ?
>> >
>>
>> Hi Nicola,
>>
>> There is no roadmap or schedule. We have a smallish set of changes stacked
>> up so I could see doing a release within a month. I need to get a new
>> release of Commons Config and BCEL out first though.
>>
>>
> Ok thanks Gary,
> Will do, and maybe suggest another change after the 3.10 : I created a
> DiffResultView and DiffView for my project purpose but I'm not sure how
> relevant it is for the lib.
> I'll make a WIP PR to discuss it
>

Great, looking f/w to it.

Gary


>
> Best,
>
> Nicolas
>
>
>
>

Re: New Sub-project Proposal.

[Claude Warren]

I have no issues with contributing Span and SpanBuffer.  Span is similar to
commons-lang Range and it might be reasonable to migrate to Range for the
Span part.  The SpanBuffer (possibly renamed to RangeBuffer) is
conceptually a byte buffer with long offset and length so that it can
conceptually be shifted.  A span buffer can be composed of multiple buffers
and you can extract span buffers from other span buffers.  Like the
standard java bytebuffer they do not reallocate the space, just point to
the offsets in the existing allocated space.  It is the composition that
makes them powerful.

So I can create a SpanBuffer from "Hello World", and another from "Goodbye
cruel"  Then I can compose a new one by creating one useing the "Goodbye
cruel" and folloiwng it with the "Hello World".cut( 5 ) [ cut the first 5
bytes off] and have "Goodbye cruel world" as the result.  This structure is
very handy when serializing large objects across kafka and similar systems
where the buffer size may be smaller than the object you want to serialize
as it can be chopped into smaller chunks, and reassembled as a composition
of the smaller chunks without the calling classes knowing.  I also used it
when I built a binary diff routine that handles very large files as it
means that I only need keep the one file and the differences to the other.

But Span and SpanBuffer are both used in the serialization classes that
could form the basis of example code, so accepting them is optional.

Claude

On Thu, Sep 12, 2019 at 9:28 AM Stian Soiland-Reyes 
wrote:

> On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
> wrote:
> > Actually the code I was thinking of is the multi-filter branch.  It
> cleans
> > up some names and simplifies a few things.  The collections and storage
> > packages might be best added as examples rather than as mainline code.
> >
> > In this case we just provide the bloom filter implementation,  If we want
> > to provide the container implementation then I think it should probably
> be
> > modified to accept any SortedSet or NavigatableSet in the constructor.
> >
> > When I return home, next week, I'll take a swipe at moving the packages
> > over to org.apache.commons.collections4.bloomfilter package (unless there
> > is a better package name).  We can then look at the entire code donation
> > and decide what changes need to be made before it is accepted.
> >
> > Does this sound like a reasonable approach?
>
> Sounds reasonable to me - then it's easy to see what will be the code
> donation, they could be examples at first that we can link to from
> documentation, several commons packages have such example codes.
>
>
> Perhaps use packagename "commons.collections4.bloomfilter" without
> org.apache before it's been IP-cleared? Alternatively add it on a fork
> of https://github.com/apache/commons-collections/ so we don't confuse
> anyone.
>
>
> I see on your branch you are using some new dependencies like
> org.xenei.blockstorage and org.xenei.spanbuffer.SpanBuffer - would these
> be needed as well if we include the container implementation or are they
> more for disk-based collections?
>
> --
> Stian Soiland-Reyes
> https://orcid.org/-0001-9842-9718
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: New Sub-project Proposal.

[Claude Warren]

@Gilles

Missed your suggestion about modularity.  Can you point me to the original
message or paraphrase it here?

Claude

On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski 
wrote:

> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a
> écrit :
> >
> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
> wrote:
> > > Actually the code I was thinking of is the multi-filter branch.  It
> cleans
> > > up some names and simplifies a few things.  The collections and storage
> > > packages might be best added as examples rather than as mainline code.
> > >
> > > In this case we just provide the bloom filter implementation,  If we
> want
> > > to provide the container implementation then I think it should
> probably be
> > > modified to accept any SortedSet or NavigatableSet in the constructor.
> > >
> > > When I return home, next week, I'll take a swipe at moving the packages
> > > over to org.apache.commons.collections4.bloomfilter package (unless
> there
> > > is a better package name).  We can then look at the entire code
> donation
> > > and decide what changes need to be made before it is accepted.
> > >
> > > Does this sound like a reasonable approach?
>
> Any comment about my suggestion to make [Collections] modular,
> starting with that code ([Collections] is nearing 30k LOC...)?
>
> Gilles
>
> > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: New Sub-project Proposal.

[Gary Gregory]

Let's talk about modules after the PR comes, I only see that as needed to
avoid bringing in dependencies for all users. IOW I would only see breaking
up Collections into Maven modules if either the PR is giant or it depends
on other artifacts.

Gary

On Thu, Sep 12, 2019, 11:15 Claude Warren  wrote:

> @Gilles
>
> Missed your suggestion about modularity.  Can you point me to the original
> message or paraphrase it here?
>
> Claude
>
> On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski 
> wrote:
>
> > Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a
> > écrit :
> > >
> > > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
> > wrote:
> > > > Actually the code I was thinking of is the multi-filter branch.  It
> > cleans
> > > > up some names and simplifies a few things.  The collections and
> storage
> > > > packages might be best added as examples rather than as mainline
> code.
> > > >
> > > > In this case we just provide the bloom filter implementation,  If we
> > want
> > > > to provide the container implementation then I think it should
> > probably be
> > > > modified to accept any SortedSet or NavigatableSet in the
> constructor.
> > > >
> > > > When I return home, next week, I'll take a swipe at moving the
> packages
> > > > over to org.apache.commons.collections4.bloomfilter package (unless
> > there
> > > > is a better package name).  We can then look at the entire code
> > donation
> > > > and decide what changes need to be made before it is accepted.
> > > >
> > > > Does this sound like a reasonable approach?
> >
> > Any comment about my suggestion to make [Collections] modular,
> > starting with that code ([Collections] is nearing 30k LOC...)?
> >
> > Gilles
> >
> > > [...]
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: New Sub-project Proposal.

[Claude Warren]

The base code depended on commons-lang3 for building hashes.  Is this
acceptable or should the hash generation code from lang3 be cut and pasted
into the classes.  Not sure what the standard is in this project.

On Thu, Sep 12, 2019 at 4:14 PM Claude Warren  wrote:

> @Gilles
>
> Missed your suggestion about modularity.  Can you point me to the original
> message or paraphrase it here?
>
> Claude
>
> On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski 
> wrote:
>
>> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a
>> écrit :
>> >
>> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
>> wrote:
>> > > Actually the code I was thinking of is the multi-filter branch.  It
>> cleans
>> > > up some names and simplifies a few things.  The collections and
>> storage
>> > > packages might be best added as examples rather than as mainline code.
>> > >
>> > > In this case we just provide the bloom filter implementation,  If we
>> want
>> > > to provide the container implementation then I think it should
>> probably be
>> > > modified to accept any SortedSet or NavigatableSet in the constructor.
>> > >
>> > > When I return home, next week, I'll take a swipe at moving the
>> packages
>> > > over to org.apache.commons.collections4.bloomfilter package (unless
>> there
>> > > is a better package name).  We can then look at the entire code
>> donation
>> > > and decide what changes need to be made before it is accepted.
>> > >
>> > > Does this sound like a reasonable approach?
>>
>> Any comment about my suggestion to make [Collections] modular,
>> starting with that code ([Collections] is nearing 30k LOC...)?
>>
>> Gilles
>>
>> > [...]
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: New Sub-project Proposal.

[Gilles Sadowski]

Le jeu. 12 sept. 2019 à 17:20, Gary Gregory  a écrit :
>
> Let's talk about modules after the PR comes, I only see that as needed to
> avoid bringing in dependencies for all users. IOW I would only see breaking
> up Collections into Maven modules if either the PR is giant or it depends
> on other artifacts.

I was also considering the complementary "issue": a project wanting to
use  (i.e. the Bloom filter in this case) without a
dependency on the rest of [Collections].
[IMHO, that's how it should work in general for low-level functionalities
(i.e. for "Commons" in particular): Make modules with just the minimum
of (interdependent) classes, and make module with higher (composed)
functionality depend on more basic ones.  All the way down to the
standard library.]

Gilles

>
> Gary
>
> On Thu, Sep 12, 2019, 11:15 Claude Warren  wrote:
>
> > @Gilles
> >
> > Missed your suggestion about modularity.  Can you point me to the original
> > message or paraphrase it here?
> >
> > Claude
> >
> > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski 
> > wrote:
> >
> > > Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a
> > > écrit :
> > > >
> > > > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
> > > wrote:
> > > > > Actually the code I was thinking of is the multi-filter branch.  It
> > > cleans
> > > > > up some names and simplifies a few things.  The collections and
> > storage
> > > > > packages might be best added as examples rather than as mainline
> > code.
> > > > >
> > > > > In this case we just provide the bloom filter implementation,  If we
> > > want
> > > > > to provide the container implementation then I think it should
> > > probably be
> > > > > modified to accept any SortedSet or NavigatableSet in the
> > constructor.
> > > > >
> > > > > When I return home, next week, I'll take a swipe at moving the
> > packages
> > > > > over to org.apache.commons.collections4.bloomfilter package (unless
> > > there
> > > > > is a better package name).  We can then look at the entire code
> > > donation
> > > > > and decide what changes need to be made before it is accepted.
> > > > >
> > > > > Does this sound like a reasonable approach?
> > >
> > > Any comment about my suggestion to make [Collections] modular,
> > > starting with that code ([Collections] is nearing 30k LOC...)?
> > >
> > > Gilles
> > >
> > > > [...]
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > 
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Gilles Sadowski]

Le jeu. 12 sept. 2019 à 17:32, Claude Warren  a écrit :
>
> The base code depended on commons-lang3 for building hashes.  Is this
> acceptable or should the hash generation code from lang3 be cut and pasted
> into the classes.  Not sure what the standard is in this project.

There is no "standard".
The least common denominator is "no dependency", not even towards
other components of this "Commons" project (at the cost of duplication
of code and/or API).
The only dependencies are between modules of a component, and on
the condition that all the modules evolve synchronously (same version).

IMHO, we should and could do better (than resort to cut-and-paste).
"Shading" is an alternative.

Gilles

> On Thu, Sep 12, 2019 at 4:14 PM Claude Warren  wrote:
>
> > @Gilles
> >
> > Missed your suggestion about modularity.  Can you point me to the original
> > message or paraphrase it here?
> >
> > Claude
> >
> > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski 
> > wrote:
> >
> >> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes  a
> >> écrit :
> >> >
> >> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren 
> >> wrote:
> >> > > Actually the code I was thinking of is the multi-filter branch.  It
> >> cleans
> >> > > up some names and simplifies a few things.  The collections and
> >> storage
> >> > > packages might be best added as examples rather than as mainline code.
> >> > >
> >> > > In this case we just provide the bloom filter implementation,  If we
> >> want
> >> > > to provide the container implementation then I think it should
> >> probably be
> >> > > modified to accept any SortedSet or NavigatableSet in the constructor.
> >> > >
> >> > > When I return home, next week, I'll take a swipe at moving the
> >> packages
> >> > > over to org.apache.commons.collections4.bloomfilter package (unless
> >> there
> >> > > is a better package name).  We can then look at the entire code
> >> donation
> >> > > and decide what changes need to be made before it is accepted.
> >> > >
> >> > > Does this sound like a reasonable approach?
> >>
> >> Any comment about my suggestion to make [Collections] modular,
> >> starting with that code ([Collections] is nearing 30k LOC...)?
> >>
> >> Gilles
> >>
> >> > [...]
> >>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Gilles Sadowski]

Le jeu. 12 sept. 2019 à 17:15, Claude Warren  a écrit :
>
> @Gilles
>
> Missed your suggestion about modularity.  Can you point me to the original
> message or paraphrase it here?

https://markmail.org/message/4bibv2zsibmtyrsg

Gilles

>> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CONFIGURATION] Formatting braces

[Thomas Vandahl]

On 11.09.19 15:53, Gary Gregory wrote:
> public static final ConfigurationConsumer
> DEFAULT_INCLUDE_LISTENER = e -> { throw e; };
> 
> public static final ConfigurationConsumer
> NOOP_INCLUDE_LISTENER = e -> { /* noop */ };

+1 for these.

> I propose a reformatting to use the "{ on the same line" which means that
> blocks go from:
> 
> if (test)
> {
>// this
> }
> else
> {
>   // that
> }
> 
> to:
> 
> if (test) {
>// this
> } else {
>   // that
> }

-1 here. At least not for all components.

Bye, Thomas


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Gary Gregory]

On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski 
wrote:

> Le jeu. 12 sept. 2019 à 17:32, Claude Warren  a écrit :
> >
> > The base code depended on commons-lang3 for building hashes.  Is this
> > acceptable or should the hash generation code from lang3 be cut and
> pasted
> > into the classes.  Not sure what the standard is in this project.
>
> There is no "standard".
> The least common denominator is "no dependency", not even towards
> other components of this "Commons" project (at the cost of duplication
> of code and/or API).
>

Note that plenty of Commons components depend on other Commons components,
not just for testing. The most prominent example is Commons DBCP which
relies on Commons Pool; in which case duplicating code would be madness ;-)

Some Commons components are "higher" level, like Commons Configuration and
Commons VFS, and so depend on other Commons components and other 3rd party
libraries.

It is fair to say that other components we have like Commons Lang and
perhaps Commons IO are considered "low" level and do not depend on
anything. I would expect Commons Lang to ever depend on anything else
(except for testing of course.)

Gary

The only dependencies are between modules of a component, and on
> the condition that all the modules evolve synchronously (same version).
>
> IMHO, we should and could do better (than resort to cut-and-paste).
> "Shading" is an alternative.
>
> Gilles
>
> > On Thu, Sep 12, 2019 at 4:14 PM Claude Warren  wrote:
> >
> > > @Gilles
> > >
> > > Missed your suggestion about modularity.  Can you point me to the
> original
> > > message or paraphrase it here?
> > >
> > > Claude
> > >
> > > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski  >
> > > wrote:
> > >
> > >> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes 
> a
> > >> écrit :
> > >> >
> > >> > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren  >
> > >> wrote:
> > >> > > Actually the code I was thinking of is the multi-filter branch.
> It
> > >> cleans
> > >> > > up some names and simplifies a few things.  The collections and
> > >> storage
> > >> > > packages might be best added as examples rather than as mainline
> code.
> > >> > >
> > >> > > In this case we just provide the bloom filter implementation,  If
> we
> > >> want
> > >> > > to provide the container implementation then I think it should
> > >> probably be
> > >> > > modified to accept any SortedSet or NavigatableSet in the
> constructor.
> > >> > >
> > >> > > When I return home, next week, I'll take a swipe at moving the
> > >> packages
> > >> > > over to org.apache.commons.collections4.bloomfilter package
> (unless
> > >> there
> > >> > > is a better package name).  We can then look at the entire code
> > >> donation
> > >> > > and decide what changes need to be made before it is accepted.
> > >> > >
> > >> > > Does this sound like a reasonable approach?
> > >>
> > >> Any comment about my suggestion to make [Collections] modular,
> > >> starting with that code ([Collections] is nearing 30k LOC...)?
> > >>
> > >> Gilles
> > >>
> > >> > [...]
> > >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-lang] branch master updated: Spotbugs is already run as part of the Maven default build goal.

[Alex Herbert]

A typo in this commit, see below.

> On 12 Sep 2019, at 14:09, ggreg...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
> new e144ca6  Spotbugs is already run as part of the Maven default build 
> goal.
> e144ca6 is described below
> 
> commit e144ca6816168867e6a96a93298f8c124029c764
> Author: Gary Gregory 
> AuthorDate: Thu Sep 12 09:09:20 2019 -0400
> 
>Spotbugs is already run as part of the Maven default build goal.
> ---
> .travis.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index b651149..300a964 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -32,4 +32,4 @@ script:
>   - mvn
> 
> after_success:
> -  - mvn clean test spotbugs:check jacoco:report coveralls:report 
> -Ptravis-jacoco javadoc:javadoc -Ddoclint=all
> +  - mvn clean test acoco:report coveralls:report -Ptravis-jacoco 
> javadoc:javadoc -Ddoclint=all

Missing a j from jacoco:report

IIUC an error in ‘after_success' will not break the build [1] so this will not 
be flagged by Travis and coverage reports will go missing:

[1] https://docs.travis-ci.com/user/job-lifecycle#breaking-the-build 


> 

Re: [commons-lang] branch master updated: Spotbugs is already run as part of the Maven default build goal.

[Gary Gregory]

On Thu, Sep 12, 2019 at 3:49 PM Alex Herbert 
wrote:

> A typo in this commit, see below.
>
> > On 12 Sep 2019, at 14:09, ggreg...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new e144ca6  Spotbugs is already run as part of the Maven default
> build goal.
> > e144ca6 is described below
> >
> > commit e144ca6816168867e6a96a93298f8c124029c764
> > Author: Gary Gregory 
> > AuthorDate: Thu Sep 12 09:09:20 2019 -0400
> >
> >Spotbugs is already run as part of the Maven default build goal.
> > ---
> > .travis.yml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index b651149..300a964 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -32,4 +32,4 @@ script:
> >   - mvn
> >
> > after_success:
> > -  - mvn clean test spotbugs:check jacoco:report coveralls:report
> -Ptravis-jacoco javadoc:javadoc -Ddoclint=all
> > +  - mvn clean test acoco:report coveralls:report -Ptravis-jacoco
> javadoc:javadoc -Ddoclint=all
>
> Missing a j from jacoco:report
>

Thanks! Fixed in git master.

Gary


>
> IIUC an error in ‘after_success' will not break the build [1] so this will
> not be flagged by Travis and coverage reports will go missing:
>
> [1] https://docs.travis-ci.com/user/job-lifecycle#breaking-the-build <
> https://docs.travis-ci.com/user/job-lifecycle#breaking-the-build>
>
> >
>
>

Re: New Sub-project Proposal.

[Gilles Sadowski]

Le jeu. 12 sept. 2019 à 20:28, Gary Gregory  a écrit :
>
> On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski 
> wrote:
>
> > Le jeu. 12 sept. 2019 à 17:32, Claude Warren  a écrit :
> > >
> > > The base code depended on commons-lang3 for building hashes.  Is this
> > > acceptable or should the hash generation code from lang3 be cut and
> > pasted
> > > into the classes.  Not sure what the standard is in this project.
> >
> > There is no "standard".
> > The least common denominator is "no dependency", not even towards
> > other components of this "Commons" project (at the cost of duplication
> > of code and/or API).
> >
>
> Note that plenty of Commons components depend on other Commons components,
> not just for testing. The most prominent example is Commons DBCP which
> relies on Commons Pool; in which case duplicating code would be madness ;-)

Good to hear.

> Some Commons components are "higher" level, like Commons Configuration and
> Commons VFS, and so depend on other Commons components and other 3rd party
> libraries.

Right. But for those, it's their purpose to provide a uniform interface to
external APIs.
What I had in mind however is the kind of reluctance that popped up,
for example, when [Text] introduced functionality related to random
numbers but would not tolerate a dependency on the API defined in
[RNG] (even though it was defined in a maven module to not incur any
unnecessary dependencies).

> It is fair to say that other components we have like Commons Lang and
> perhaps Commons IO are considered "low" level and do not depend on
> anything. I would expect Commons Lang to ever depend on anything else
> (except for testing of course.)

Sure, [Lang] should not depend on anything.  But it also should not
attempt to provide anything that would be better located in another
component.  Again, RNG functionality is a case in point.
Creating [Text] was a step in the right direction (i.s. stop the bloat).

We don't look actively into defining/refining scopes for the components,
and how to make them modular.  This should be a design requirement,
rather than an afterthought.

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: New Sub-project Proposal.

[Gary Gregory]

On Thu, Sep 12, 2019 at 5:24 PM Gilles Sadowski 
wrote:

> Le jeu. 12 sept. 2019 à 20:28, Gary Gregory  a
> écrit :
> >
> > On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski 
> > wrote:
> >
> > > Le jeu. 12 sept. 2019 à 17:32, Claude Warren  a
> écrit :
> > > >
> > > > The base code depended on commons-lang3 for building hashes.  Is this
> > > > acceptable or should the hash generation code from lang3 be cut and
> > > pasted
> > > > into the classes.  Not sure what the standard is in this project.
> > >
> > > There is no "standard".
> > > The least common denominator is "no dependency", not even towards
> > > other components of this "Commons" project (at the cost of duplication
> > > of code and/or API).
> > >
> >
> > Note that plenty of Commons components depend on other Commons
> components,
> > not just for testing. The most prominent example is Commons DBCP which
> > relies on Commons Pool; in which case duplicating code would be madness
> ;-)
>
> Good to hear.
>
> > Some Commons components are "higher" level, like Commons Configuration
> and
> > Commons VFS, and so depend on other Commons components and other 3rd
> party
> > libraries.
>
> Right. But for those, it's their purpose to provide a uniform interface to
> external APIs.
> What I had in mind however is the kind of reluctance that popped up,
> for example, when [Text] introduced functionality related to random
> numbers but would not tolerate a dependency on the API defined in
> [RNG] (even though it was defined in a maven module to not incur any
> unnecessary dependencies).
>
> > It is fair to say that other components we have like Commons Lang and
> > perhaps Commons IO are considered "low" level and do not depend on
> > anything. I would expect Commons Lang to ever depend on anything else
> > (except for testing of course.)
>
> Sure, [Lang] should not depend on anything.  But it also should not
> attempt to provide anything that would be better located in another
> component.  Again, RNG functionality is a case in point.
> Creating [Text] was a step in the right direction (i.s. stop the bloat).
>
> We don't look actively into defining/refining scopes for the components,
> and how to make them modular.  This should be a design requirement,
> rather than an afterthought.
>

Gilles,

Take a look at the PR, I added comments to allow the PR to have 0 deps.

Gary


>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>