Re: [Collections-BloomFilter][Discuss] missing functionality?

[Claude Warren]

I have an open pull request to fix this problem.  I could use another
review: https://github.com/apache/commons-collections/pull/476


On Tue, Apr 9, 2024 at 11:29 AM Claude Warren  wrote:

> Alex,
>
> I like your solution.  To answer your question. We create a BloomFilter
> that has a timestamp associated with it.  When the timestamp is greater
> than System.currentTimeMillis() the filter is removed.  The custom cleanup
> calls Cleanup.removeEmptyTarget().andThen()
>
> I think that creating a cleanup() or clean() method on the
> LayeredBloomFilter is the appropriate solution and that it should call
> cleanup() on the LayerManager. (so 2 new methods, one exposed).
>
> The next() method is used when external circumstances dictate that a new
> layer should be created.  I think a StableBloomFilter I implemented
> required it,  but I do not have the code to hand at the moment.
>
> Claude
>
>
> On Tue, Apr 9, 2024 at 10:38 AM Alex Herbert 
> wrote:
>
>> Hi Claude,
>>
>> Q. What is your current clean-up filter, i.e.
>> the Consumer>? I assume you are using a custom
>> one.
>>
>> The current collections code only has 2 functional implementations. One
>> will remove the newest filter if it is empty, one will remove the oldest
>> filters until the size is below a limit. Since neither of those will
>> iterate the list and purge stale objects then I assume you are using a
>> custom clean-up filter. So you had to have created the layer manager with
>> your custom filter. Assuming this then there are at least two solutions
>> for
>> the current code:
>>
>> 1. The current implementation always calls the clean-up filter with the
>> same LinkedList since it is final. So you can capture the list and do what
>> you want with it:
>>
>> @SuppressWarnings("rawtypes")
>> LinkedList[] captured = new LinkedList[1];
>> Consumer> cleanup = list -> {
>> captured[0] = list;
>> // ... do clean-up
>> };
>>
>> // Once you have captured the list, you can clean it when you
>> want:
>> // unchecked conversion
>> cleanup.accept(captured[0]);
>>
>> Obviously this is not ideal as you have to manage the captured list to
>> call
>> cleanup. But it delivers exactly what you require in terms of being able
>> to
>> call cleanup at any time.
>>
>> 2. The call to next() will clean the layers but also add a new layer. So
>> your custom clean method could clean stale objects and also any empty
>> filters not at the end of the list. This will avoid building up lots of
>> empty filters when you frequently trigger next() to purge stale filters.
>> You can call next() directly on the LayeredBloomFilter. I do not know what
>> extend check you are using so there is some management to be done with the
>> other settings of the LayerManager to avoid removing any functional layers
>> which are currently empty.
>>
>> --
>>
>> As to exposing the LayerManager and adding a clean() method to the
>> LayerManager, I think this is not in keeping with the current design. The
>> LayerManager is used during construction and then never used again. So
>> functionality to act on the layers is public through the
>> LayeredBloomFilter
>> (e.g. calling next()). So perhaps the change to the API should be to add a
>> cleanup() method to LayeredBloomFilter. This does the same as next(), but
>> does not add a new layer.
>>
>> I cannot recall the use case for next() in the LayeredBloomFilter. Would
>> the addition of cleanup() make the next() method redundant?
>>
>> --
>>
>> Note: The typing against LinkedList could be updated to java.util.Deque.
>> The only issue with this is the method:
>> public final BloomFilter get(int depth)
>>
>> This is not supported by the Deque interface. However the LinkedList
>> implementation of get(int) will use the iterator from the start or end of
>> the list (whichever is closer) to find the element. This can use the
>> iterator/descendingIterator method of Deque for the same performance (but
>> the code to do this has to be written).
>>
>> Alex
>>
>>
>> On Tue, 9 Apr 2024 at 08:45, Claude Warren  wrote:
>>
>> > Greetings,
>> >
>> > I am attempting to use the Bloomfilter code in Kafka to manage PID
>> > generation.  The requirement is to remove pid tracking after a period of
>> > time.  This is possible with the LayeredBloomFilter but it has an edge
>> case
>> > problem.
>> >
>> > The LayeredBloomFilter uses the LayerManager to manage the filters that
>> > comprise the layers of the LayerdBloomFilter.
>> > The LayerManager uses a Consumer> called
>> > filterCleanup to remove old layers.
>> > The filterCleanup is only called when a new layer is added to the
>> layered
>> > filter.
>> >
>> > This solution works well in the general case where data is flowing
>> through
>> > the layered filter.  However if nothing is added to the filter,
>> > filterCleanup is not called.
>> >
>> > In the Kafka case we have a LayeredBloomFilter for PIDs for each
>> producer.
>> > As long as 

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

Looks good to me.

Any opinions on changing the LayerManager to keep the layers in a Deque
rather than a LinkedList. I think it would only require a change to the
following method:

public final BloomFilter get(int depth)

Performance will be the same as the Deque can be a LinkedList. This is more
about how any custom downstream code is currently using the collection of
layers.

Alex

On Wed, 17 Apr 2024 at 10:00, Claude Warren  wrote:

> I have an open pull request to fix this problem.  I could use another
> review: https://github.com/apache/commons-collections/pull/476
>
>
> On Tue, Apr 9, 2024 at 11:29 AM Claude Warren  wrote:
>
> > Alex,
> >
> > I like your solution.  To answer your question. We create a BloomFilter
> > that has a timestamp associated with it.  When the timestamp is greater
> > than System.currentTimeMillis() the filter is removed.  The custom
> cleanup
> > calls Cleanup.removeEmptyTarget().andThen()
> >
> > I think that creating a cleanup() or clean() method on the
> > LayeredBloomFilter is the appropriate solution and that it should call
> > cleanup() on the LayerManager. (so 2 new methods, one exposed).
> >
> > The next() method is used when external circumstances dictate that a new
> > layer should be created.  I think a StableBloomFilter I implemented
> > required it,  but I do not have the code to hand at the moment.
> >
> > Claude
> >
> >
> > On Tue, Apr 9, 2024 at 10:38 AM Alex Herbert 
> > wrote:
> >
> >> Hi Claude,
> >>
> >> Q. What is your current clean-up filter, i.e.
> >> the Consumer>? I assume you are using a custom
> >> one.
> >>
> >> The current collections code only has 2 functional implementations. One
> >> will remove the newest filter if it is empty, one will remove the oldest
> >> filters until the size is below a limit. Since neither of those will
> >> iterate the list and purge stale objects then I assume you are using a
> >> custom clean-up filter. So you had to have created the layer manager
> with
> >> your custom filter. Assuming this then there are at least two solutions
> >> for
> >> the current code:
> >>
> >> 1. The current implementation always calls the clean-up filter with the
> >> same LinkedList since it is final. So you can capture the list and do
> what
> >> you want with it:
> >>
> >> @SuppressWarnings("rawtypes")
> >> LinkedList[] captured = new LinkedList[1];
> >> Consumer> cleanup = list -> {
> >> captured[0] = list;
> >> // ... do clean-up
> >> };
> >>
> >> // Once you have captured the list, you can clean it when you
> >> want:
> >> // unchecked conversion
> >> cleanup.accept(captured[0]);
> >>
> >> Obviously this is not ideal as you have to manage the captured list to
> >> call
> >> cleanup. But it delivers exactly what you require in terms of being able
> >> to
> >> call cleanup at any time.
> >>
> >> 2. The call to next() will clean the layers but also add a new layer. So
> >> your custom clean method could clean stale objects and also any empty
> >> filters not at the end of the list. This will avoid building up lots of
> >> empty filters when you frequently trigger next() to purge stale filters.
> >> You can call next() directly on the LayeredBloomFilter. I do not know
> what
> >> extend check you are using so there is some management to be done with
> the
> >> other settings of the LayerManager to avoid removing any functional
> layers
> >> which are currently empty.
> >>
> >> --
> >>
> >> As to exposing the LayerManager and adding a clean() method to the
> >> LayerManager, I think this is not in keeping with the current design.
> The
> >> LayerManager is used during construction and then never used again. So
> >> functionality to act on the layers is public through the
> >> LayeredBloomFilter
> >> (e.g. calling next()). So perhaps the change to the API should be to
> add a
> >> cleanup() method to LayeredBloomFilter. This does the same as next(),
> but
> >> does not add a new layer.
> >>
> >> I cannot recall the use case for next() in the LayeredBloomFilter. Would
> >> the addition of cleanup() make the next() method redundant?
> >>
> >> --
> >>
> >> Note: The typing against LinkedList could be updated to java.util.Deque.
> >> The only issue with this is the method:
> >> public final BloomFilter get(int depth)
> >>
> >> This is not supported by the Deque interface. However the LinkedList
> >> implementation of get(int) will use the iterator from the start or end
> of
> >> the list (whichever is closer) to find the element. This can use the
> >> iterator/descendingIterator method of Deque for the same performance
> (but
> >> the code to do this has to be written).
> >>
> >> Alex
> >>
> >>
> >> On Tue, 9 Apr 2024 at 08:45, Claude Warren  wrote:
> >>
> >> > Greetings,
> >> >
> >> > I am attempting to use the Bloomfilter code in Kafka to manage PID
> >> > generation.  The requirement is to remove pid tracking after a period
> of
> >> > time.  This is possible 

[ANNOUNCE] Apache Commons Text Version 1.12.0

[Gary Gregory]

The Apache Commons team is pleased to announce Apache Commons Text
Version 1.12.0.

Apache Commons Text is a set of utility functions and reusable
components for the purpose of processing and manipulating text that
should be of use in a Java environment.

Release 1.12.0. Requires Java 8 or above.

Historical list of changes:
https://commons.apache.org/proper/commons-text/changes-report.html

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

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

Download page: https://commons.apache.org/proper/commons-text/download_text.cgi

Gary Gregory
- Apache Commons Team

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

Re: [VOTE] Release Apache Commons Imaging 1.0.0-alpha5 based on RC1

[Tomas Lanik]

My +1 [release]

Tomas Lanik

On Mon, Apr 15, 2024, 15:36 Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Imaging 1.0.0-alpha4 was released, so I would like to release Apache
> Commons Imaging 1.0.0-alpha5.
>
> Apache Commons Imaging 1.0.0-alpha5 RC1 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1
> (svn revision 68532)
>
> The Git tag commons-imaging-1.0.0-alpha5-RC1 commit for this RC is
> 6dc0ba92f62056584af40a24f6c8a8215469ca8f which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=6dc0ba92f62056584af40a24f6c8a8215469ca8f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-imaging.git
> --branch 
> commons-imaging-1.0.0-alpha5-RC1
> commons-imaging-1.0.0-alpha5-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1720/org/apache/commons/commons-imaging/1.0.0-alpha5/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Apr 15 13:22:38 UTC 2024
>
> commons-imaging-1.0.0-alpha5-bom.xml=b76ae4de3f358c9d3c47925005ba0ea76ad48c0c523e6785d34d9e106dbb2b019b43e974ceb3eff598c03e6ae507b51bf9a5b0cee6fa04664f0dd589540a359e
>
> commons-imaging-1.0.0-alpha5-bin.zip=a94f25a37942b921742765931f89d640320ce5b6d7588ecf9bfb89fa8ea64d4940f88c4062cb5621e64aa9ae18e72bed81e6f517a2695b58d91d972b1f12ed9d
>
> org.apache.commons_commons-imaging-1.0.0-alpha5.spdx.json=43cea02387f469d5b4760a5a34697f81467e7de48567767bbda494f4c25f9543d44fcaac750876aec8834c1781e706e7f7884e36bf8b321ee06bfac0742ee51d
>
> commons-imaging-1.0.0-alpha5-bom.json=79e8a06869238c75a84f817986ba090bbde0124ea885efee11f24eb2f18efc8ab5ffb9699233feb08f3dedfb89580ca702c65bcc9948be5ebcbe3a9796049721
>
> commons-imaging-1.0.0-alpha5-src.zip=78c930ad5edc1f897f049ad357a4b32e5a1c50bd5e9c127296c2209fa22f0705d981828b45c8c4e17efaea34c3c9f68f95fd416dbd6317aeeb3e4908eec0fc50
>
> commons-imaging-1.0.0-alpha5-tests.jar=4a371d7c4fd0f16c084533cedfaafd0eb98d229758ed3455d749bc135564504e788bcf3ceb20a5c8db29aaa837744be3e06ed29d312ffbfbebfa32ff4030c9ce
>
> commons-imaging-1.0.0-alpha5-test-sources.jar=9cc2712d43a5f7d3591940a20dde807730cf0c9e9e74d3105b487f6929f3df5635e4499c9c174550516779cad02b44c7b853c971b9f0a2c206c5357a2d95345d
>
> commons-imaging-1.0.0-alpha5-src.tar.gz=fe6c8b94fecae6a694f22ec10aafe20dd4cac2fcc3811f87ac9ac5d51df11f528fc550f0e7e1e336f900cd8e92a80dedc8c3b00ff31c6e4fb03075d86c19dd3c
>
> commons-imaging-1.0.0-alpha5-javadoc.jar=4bd1c9229e443a8367fbf1402d99cc6fbf2a7f159903ddf34edb46de4d02e91f900cd3c8f9cea6c400da1c62184320c9d71729a5259748d9896cb15f5e76b530
>
> commons-imaging-1.0.0-alpha5-sources.jar=ee27d8161b2b2b93d26b44153b319a790bb0227894cf9ab241182f02f51e2b499911253cbf0f6deef60964559bbb31414e5ee695916ef8275482d11a51b4de1d
>
> commons-imaging-1.0.0-alpha5-bin.tar.gz=ad98e5b49cfc6382c341af86ae2011da0587354dd45a7427a0507310d878b618d790ed6fc6cfdfd610801699015db1d46668a3d1eed79c5977ce00da37c2d602
>
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy ' using:
>
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 17.0.10+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 17.0.10, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac"
>
> Darwin  23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05
> PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64
>
> Details of changes since 1.0.0-alpha4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/index.html
> (note some *relative* links are broken and the 1.0.0-alpha5
> directories are not yet created - these will be OK once the site is
> deployed.)
>
> JApiCmp Report (compared to 1.0.0-alpha4):
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/japicmp.html
> This is an alpha release with one API break.
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/rat-report.html
>
> KEYS:
> https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] 

Re: [VOTE] Release Apache Commons Imaging 1.0.0-alpha5 based on RC1

[Gary Gregory]

My +1

Gary


On Mon, Apr 15, 2024, 4:36 PM Rob Tompkins  wrote:

> +1
>
> > On Apr 15, 2024, at 1:01 PM, Bruno Kinoshita 
> wrote:
> >
> > +1
> >
> > Thank you Gary!
> >
> >> On Mon, 15 Apr 2024 at 15:36, Gary Gregory  wrote:
> >>
> >> We have fixed a few bugs and added enhancements since Apache Commons
> >> Imaging 1.0.0-alpha4 was released, so I would like to release Apache
> >> Commons Imaging 1.0.0-alpha5.
> >>
> >> Apache Commons Imaging 1.0.0-alpha5 RC1 is available for review here:
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1
> >> (svn revision 68532)
> >>
> >> The Git tag commons-imaging-1.0.0-alpha5-RC1 commit for this RC is
> >> 6dc0ba92f62056584af40a24f6c8a8215469ca8f which you can browse here:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=6dc0ba92f62056584af40a24f6c8a8215469ca8f
> >> You may checkout this tag using:
> >>git clone https://gitbox.apache.org/repos/asf/commons-imaging.git
> >> --branch <
> https://gitbox.apache.org/repos/asf/commons-imaging.git--branch>
> >> commons-imaging-1.0.0-alpha5-RC1
> >> commons-imaging-1.0.0-alpha5-RC1
> >>
> >> Maven artifacts are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1720/org/apache/commons/commons-imaging/1.0.0-alpha5/
> >>
> >> These are the artifacts and their hashes:
> >>
> >> #Release SHA-512s
> >> #Mon Apr 15 13:22:38 UTC 2024
> >>
> >>
> commons-imaging-1.0.0-alpha5-bom.xml=b76ae4de3f358c9d3c47925005ba0ea76ad48c0c523e6785d34d9e106dbb2b019b43e974ceb3eff598c03e6ae507b51bf9a5b0cee6fa04664f0dd589540a359e
> >>
> >>
> commons-imaging-1.0.0-alpha5-bin.zip=a94f25a37942b921742765931f89d640320ce5b6d7588ecf9bfb89fa8ea64d4940f88c4062cb5621e64aa9ae18e72bed81e6f517a2695b58d91d972b1f12ed9d
> >>
> >>
> org.apache.commons_commons-imaging-1.0.0-alpha5.spdx.json=43cea02387f469d5b4760a5a34697f81467e7de48567767bbda494f4c25f9543d44fcaac750876aec8834c1781e706e7f7884e36bf8b321ee06bfac0742ee51d
> >>
> >>
> commons-imaging-1.0.0-alpha5-bom.json=79e8a06869238c75a84f817986ba090bbde0124ea885efee11f24eb2f18efc8ab5ffb9699233feb08f3dedfb89580ca702c65bcc9948be5ebcbe3a9796049721
> >>
> >>
> commons-imaging-1.0.0-alpha5-src.zip=78c930ad5edc1f897f049ad357a4b32e5a1c50bd5e9c127296c2209fa22f0705d981828b45c8c4e17efaea34c3c9f68f95fd416dbd6317aeeb3e4908eec0fc50
> >>
> >>
> commons-imaging-1.0.0-alpha5-tests.jar=4a371d7c4fd0f16c084533cedfaafd0eb98d229758ed3455d749bc135564504e788bcf3ceb20a5c8db29aaa837744be3e06ed29d312ffbfbebfa32ff4030c9ce
> >>
> >>
> commons-imaging-1.0.0-alpha5-test-sources.jar=9cc2712d43a5f7d3591940a20dde807730cf0c9e9e74d3105b487f6929f3df5635e4499c9c174550516779cad02b44c7b853c971b9f0a2c206c5357a2d95345d
> >>
> >>
> commons-imaging-1.0.0-alpha5-src.tar.gz=fe6c8b94fecae6a694f22ec10aafe20dd4cac2fcc3811f87ac9ac5d51df11f528fc550f0e7e1e336f900cd8e92a80dedc8c3b00ff31c6e4fb03075d86c19dd3c
> >>
> >>
> commons-imaging-1.0.0-alpha5-javadoc.jar=4bd1c9229e443a8367fbf1402d99cc6fbf2a7f159903ddf34edb46de4d02e91f900cd3c8f9cea6c400da1c62184320c9d71729a5259748d9896cb15f5e76b530
> >>
> >>
> commons-imaging-1.0.0-alpha5-sources.jar=ee27d8161b2b2b93d26b44153b319a790bb0227894cf9ab241182f02f51e2b499911253cbf0f6deef60964559bbb31414e5ee695916ef8275482d11a51b4de1d
> >>
> >>
> commons-imaging-1.0.0-alpha5-bin.tar.gz=ad98e5b49cfc6382c341af86ae2011da0587354dd45a7427a0507310d878b618d790ed6fc6cfdfd610801699015db1d46668a3d1eed79c5977ce00da37c2d602
> >>
> >> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> >> jacoco -P japicmp clean package site deploy ' using:
> >>
> >> openjdk version "17.0.10" 2024-01-16
> >> OpenJDK Runtime Environment Homebrew (build 17.0.10+0)
> >> OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing)
> >>
> >> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> >> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> >> Java version: 17.0.10, vendor: Homebrew, runtime:
> >> /usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home
> >> Default locale: en_US, platform encoding: UTF-8
> >> OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac"
> >>
> >> Darwin  23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05
> >> PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64
> >>
> >> Details of changes since 1.0.0-alpha4 are in the release notes:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/RELEASE-NOTES.txt
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/changes-report.html
> >>
> >> Site:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/index.html
> >>(note some *relative* links are broken and the 1.0.0-alpha5
> >> directories are not yet created - these will be OK once the site is
> >> deployed.)
> >>
> >> JApiCmp Report (compared to 1.0.0-alpha4):
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-alpha5-RC1/site/japicmp.html

Re: Is there a blog for commons?

[Elric V]

On 16/04/2024 13:08, Gary Gregory wrote:

There is an Apache wide blog here:
https://news.apache.org/


There used to be a planet.apache.org which aggregated committer/project 
blogs, but that seems to be broken.


Would there be any interets in an aggregated ASF-project wide blog? 
Where contributors from all projects could submit posts? Would be a 
great way to keep up to do date, as well as learn about other ASF projects.



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

Re: Is there a blog for commons?

[Gary Gregory]

Well, we already have https://news.apache.org/

Gary

On Wed, Apr 17, 2024, 1:50 PM Elric V  wrote:

> On 16/04/2024 13:08, Gary Gregory wrote:
> > There is an Apache wide blog here:
> > https://news.apache.org/
>
> There used to be a planet.apache.org which aggregated committer/project
> blogs, but that seems to be broken.
>
> Would there be any interets in an aggregated ASF-project wide blog?
> Where contributors from all projects could submit posts? Would be a
> great way to keep up to do date, as well as learn about other ASF projects.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[RESULT][VOTE] Release Apache Commons CLI 1.7.0 based on RC1

[Gary Gregory]

This release vote passes with the following +1 votes:

- Gary Gregory (ggregory), binding
- Bruno Kinoshita (kinow), binding
- Claude Warren (Claudenw), binding
- Tomas Lanik, non-binding
- Rob Tompkins (chtompki), binding
- Eric Pugh (epugh), non-binding

Thank you all,
Gary

On Mon, Apr 15, 2024 at 12:59 PM Eric Pugh
 wrote:
>
> +1 to release!
>
> > On Apr 15, 2024, at 12:53 PM, Rob Tompkins  wrote:
> >
> > +1 site, release-notes, signatures, and builds all check out
> >
> > Thanks!!
> >
> > -Rob
> >
> >> On Apr 13, 2024, at 7:29 AM, Gary Gregory  wrote:
> >>
> >> We have fixed a few bugs and added enhancements since Apache Commons
> >> CLI 1.6.0 was released, so I would like to release Apache Commons CLI
> >> 1.7.0.
> >>
> >> Apache Commons CLI 1.7.0 RC1 is available for review here:
> >>   https://dist.apache.org/repos/dist/dev/commons/cli/1.7.0-RC1 (svn
> >> revision 68470)
> >>
> >> The Git tag commons-cli-1.7.0-RC1 commit for this RC is
> >> caed6714a73ce366aebccebf4a21e287d6d34ae0 which you can browse here:
> >>   
> >> https://gitbox.apache.org/repos/asf?p=commons-cli.git;a=commit;h=caed6714a73ce366aebccebf4a21e287d6d34ae0
> >> You may checkout this tag using:
> >>   git clone https://gitbox.apache.org/repos/asf/commons-cli.git
> >> --branch commons-cli-1.7.0-RC1 commons-cli-1.7.0-RC1
> >>
> >> Maven artifacts are here:
> >>   
> >> https://repository.apache.org/content/repositories/orgapachecommons-1718/commons-cli/commons-cli/1.7.0/
> >>
> >> These are the artifacts and their hashes:
> >>
> >> #Release SHA-512s
> >> #Sat Apr 13 02:26:30 UTC 2024
> >> commons-cli-1.7.0-bom.json=fd710316564b50a1af147751c01f25c473c8ccee4af117e3ebd12f7e1eda9524b10389e8ae8705922cc82c0164bc1c5a2977327eb22eac449ce4b149b15d3d90
> >> commons-cli-1.7.0-test-sources.jar=7b1e4940a6d0b2c84939146122849db1086730d93b8c540047a6fd2b6112eba9c420008302300557c8187821316cddbb7b0599664f04fa21e325e04bd4bb06f0
> >> commons-cli-1.7.0-src.zip=e0f684163327c6180098c61d89705ff49041239b04dcd0235dd0b7b3b9ac590c23da85236ae4458135b1d804824d639db2f4a85ee9cfa281c2cc49ec2f5775f1
> >> commons-cli-1.7.0-javadoc.jar=fea0659ba7c7f23940547f2aa6ae15d85817a7ecf9d537083b7c5873012e85b39aa9dbf1054f69f49a86b30b3ea06e037dc5b972c1bc553caa2c6004be409613
> >> commons-cli_commons-cli-1.7.0.spdx.json=1527955bcb67fdbefac08bd6905290f01c3397e6921eb5980e4b96145cf68a4a6745f28b29435fb4e181f051cd1c9d43017d53db5df6a12e76244bd642c5213a
> >> commons-cli-1.7.0-bin.zip=07a2a6698ba1010c5952ec26ad2e4ce73a87476f0fd97dd34cb5280f0563c0a0bdeb65e3cc9afbe9bca50c149f2570fa716f0a617c9f277b1ffdd9baa75081d0
> >> commons-cli-1.7.0-tests.jar=08338e5488c6d12e28a65b2d5ea2da172a087832c0c58915f47e1078038b10873bf5594237dc2275a6079027487745d5a76722424c5482c5f786ba95f5c34acb
> >> commons-cli-1.7.0-src.tar.gz=d97be4df213e0df72a3866b8271e34064e984e98debb2ae8bdd1bef94ea1fd358655dbc730866cb62b4232bad7888d69b4d964a101139f2cf36cd0fcfb39d28b
> >> commons-cli-1.7.0-sources.jar=9bc86da3391d3fc87806384fda1272b8e0a0313eb529ae4e9eaf7d5fc63708a90449f6fe72b4d29da730c21c4fc497f395c01812b625803479884e08f0593090
> >> commons-cli-1.7.0-bom.xml=40623202b108d74635fee720a826e730ed63b838596db45a887f4718be949db9ca01f9661be3c03067b2d1d9246d7fde1524c83c7718db1cb2202e0d3ed748d2
> >> commons-cli-1.7.0-bin.tar.gz=c429f22021bbb80f11e9b27bc768ec28b797d9d6fc18b3af369bfc7278641f2585c62cd6d6736b7f1813e3f9690390f8fd304743f123ae9fff496edd1942cac6
> >>
> >>
> >> I have tested this with 'mvn' and 'mvn -V -Duser.name=$my_apache_id
> >> -Dcommons.release-plugin.version=$commons_release_plugin_version
> >> -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> >> deploy' using:
> >>
> >> openjdk version "17.0.10" 2024-01-16
> >> OpenJDK Runtime Environment Homebrew (build 17.0.10+0)
> >> OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing)
> >>
> >> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> >> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> >> Java version: 17.0.10, vendor: Homebrew, runtime:
> >> /usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home
> >> Default locale: en_US, platform encoding: UTF-8
> >> OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac"
> >>
> >> Darwin * 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05
> >> PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64
> >>
> >> Details of changes since 1.6.0 are in the release notes:
> >>   
> >> https://dist.apache.org/repos/dist/dev/commons/cli/1.7.0-RC1/RELEASE-NOTES.txt
> >>   
> >> https://dist.apache.org/repos/dist/dev/commons/cli/1.7.0-RC1/site/changes-report.html
> >>
> >> Site:
> >>   
> >> https://dist.apache.org/repos/dist/dev/commons/cli/1.7.0-RC1/site/index.html
> >>   (note some *relative* links are broken and the 1.7.0 directories
> >> are not yet created - these will be OK once the site is deployed.)
> >>
> >> JApiCmp Report (compared to 1.6.0):
> >>   
> >> https://dist.apache.org/repos/dist/dev/commons/cli/1.7.0-RC1/site/japicmp.html
> >>
> >> RAT 

[ANNOUNCE] Apache Commons CLI Version 1.7.0

[Gary Gregory]

The Apache Commons team is pleased to announce Apache Commons CLI Version 1.7.0.

Commons CLI provides a simple API for working with the command line
arguments and options.

Historical list of changes:
https://commons.apache.org/proper/commons-cli/changes-report.html

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

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

Download page: https://commons.apache.org/proper/commons-cli/download_cli.cgi

Gary Gregory
- The Apache Commons Team

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