Re: [VOTE] Release Apache Commons Configuration 2.8 based on RC2

[Bruno Kinoshita]

  [x] +1 Release these artifacts


Thanks Matt!

-Bruno


On Wed, 22 Jun 2022 at 15:47, Matt Juntunen 
wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Configuration 2.7 was released, so I would like
> to release Apache Commons Configuration 2.8.
>
> Apache Commons Configuration 2.8 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2
> (svn revision 55251)
>
> The Git tag commons-configuration-2.8-RC2 commit for this RC is
> f540433112b9a93c26c43277c3ec7a3d40565115 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f540433112b9a93c26c43277c3ec7a3d40565115
> You may checkout this tag using:
> git clone
> https://gitbox.apache.org/repos/asf/commons-configuration.git
> --branch
> 
> commons-configuration-2.8-RC2 commons-configuration-2.8-RC2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1590/org/apache/commons/commons-configuration2/2.8/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Jun 21 23:27:23 EDT 2022
>
> commons-configuration2-2.8-bin.tar.gz=b3f4628ecf3fc52feaf68ca13d0518d0ff5de8bea690a3fa625b91f2ffee9ef0fe1c575743d71bd035ba5d1c0be47a668ec1b28fb1953998f6723cecb8b59a38
>
> commons-configuration2-2.8-bin.zip=86dc5ee9d7581b6c0b2f2807fb4f2179eec0dc4dfdb1246ffd9054a64e4511b534a4be015946403f0d0519362029cef2d4d89c684d38eaa4bd1e6af8d8b8b3a9
>
> commons-configuration2-2.8-javadoc.jar=91dc9721ebea0345175d02b2d8e4bf08a255034549527edbecd382771540d85ca2423f22a4bc260d42ac33e9c3bd6b36a5fb7713b4919b58a0c06d9661285b0d
>
> commons-configuration2-2.8-sources.jar=85e4f25fc9a0682bd3376de2741b48bfb6b77e98795a107c818c0bb51578cde8dd60a5e38177a6ce2a73bc4a1b9f925720321f7320fef0173c6f26c0a303bb55
>
> commons-configuration2-2.8-src.tar.gz=924be9a8c0fd5f5a03d9ccd14a0bf79b83323f424fc4580084e807a5f7f242d40146cbdcd34d8d3a0098aeebe3040f77089230176ef737d649666152f2bda6ea
>
> commons-configuration2-2.8-src.zip=e6695471c21e0c885b3ad5b0e0ff65a69a65cbc82a7c96d0406342f81b2efb8185b7008dfd7d49603ca96ea44761bb681aacfd997bbbae742ad922d58173305a
>
> commons-configuration2-2.8-test-sources.jar=d203e063ec6b7ea16688c9015f10cf41bb3c592e990e214f6f808a20f19efe5973b3d30f4b939d571a8f4c1c2094d52c77733b59d0e7cdf412d27133fac7c7d9
>
> commons-configuration2-2.8-tests.jar=6878c163de212e0617650ecbcd68887db1fc0c29f596ca773598b4ef7314e7062f4671208b8360d6ec2ca8f8408c75763912bcc545903e440fd77a6086af5c49
>
>
>
> I have tested this with ***'mvn clean install site'*** using:
> ***
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> Java version: 1.8.0_322, vendor: Temurin, runtime:
> /home/matt/lang/java/jdk8u322-b06/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> family: "unix"
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
> /home/matt/lang/java/jdk-11.0.14.1+1
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> family: "unix"
> ***
>
> Details of changes since 2.7 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/index.html
> (note some *relative* links are broken and the 2.8 directories are
> not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.7):
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-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 than 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,
>
> Matt Juntunen,
> Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)
>
> 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 tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
> --branch
> 

[VOTE] Release Apache Commons Configuration 2.8 based on RC2

[Matt Juntunen]

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

Apache Commons Configuration 2.8 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2
(svn revision 55251)

The Git tag commons-configuration-2.8-RC2 commit for this RC is
f540433112b9a93c26c43277c3ec7a3d40565115 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f540433112b9a93c26c43277c3ec7a3d40565115
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1590/org/apache/commons/commons-configuration2/2.8/

These are the artifacts and their hashes:

#Release SHA-512s
#Tue Jun 21 23:27:23 EDT 2022
commons-configuration2-2.8-bin.tar.gz=b3f4628ecf3fc52feaf68ca13d0518d0ff5de8bea690a3fa625b91f2ffee9ef0fe1c575743d71bd035ba5d1c0be47a668ec1b28fb1953998f6723cecb8b59a38
commons-configuration2-2.8-bin.zip=86dc5ee9d7581b6c0b2f2807fb4f2179eec0dc4dfdb1246ffd9054a64e4511b534a4be015946403f0d0519362029cef2d4d89c684d38eaa4bd1e6af8d8b8b3a9
commons-configuration2-2.8-javadoc.jar=91dc9721ebea0345175d02b2d8e4bf08a255034549527edbecd382771540d85ca2423f22a4bc260d42ac33e9c3bd6b36a5fb7713b4919b58a0c06d9661285b0d
commons-configuration2-2.8-sources.jar=85e4f25fc9a0682bd3376de2741b48bfb6b77e98795a107c818c0bb51578cde8dd60a5e38177a6ce2a73bc4a1b9f925720321f7320fef0173c6f26c0a303bb55
commons-configuration2-2.8-src.tar.gz=924be9a8c0fd5f5a03d9ccd14a0bf79b83323f424fc4580084e807a5f7f242d40146cbdcd34d8d3a0098aeebe3040f77089230176ef737d649666152f2bda6ea
commons-configuration2-2.8-src.zip=e6695471c21e0c885b3ad5b0e0ff65a69a65cbc82a7c96d0406342f81b2efb8185b7008dfd7d49603ca96ea44761bb681aacfd997bbbae742ad922d58173305a
commons-configuration2-2.8-test-sources.jar=d203e063ec6b7ea16688c9015f10cf41bb3c592e990e214f6f808a20f19efe5973b3d30f4b939d571a8f4c1c2094d52c77733b59d0e7cdf412d27133fac7c7d9
commons-configuration2-2.8-tests.jar=6878c163de212e0617650ecbcd68887db1fc0c29f596ca773598b4ef7314e7062f4671208b8360d6ec2ca8f8408c75763912bcc545903e440fd77a6086af5c49



I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
family: "unix"

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-11.0.14.1+1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
family: "unix"
***

Details of changes since 2.7 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/changes-report.html

Site:

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

JApiCmp Report (compared to 2.7):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-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 than 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,

Matt Juntunen,
Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)

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 tag

git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2
cd commons-configuration-2.8-RC2

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must 

[CANCELLED] [VOTE] Release Apache Commons Configuration 2.8 based on RC1

[Matt Juntunen]

Thanks, Bruno! I'm going to go ahead and cancel this vote so I can fix
the README. I also noticed some inconsistency in the naming of the
version. In some places I called it 2.8.0 and in others 2.8. I'm going
to standardize on the shorter "2.8". RC2 should be out soon.

Regards,
Matt J

On Tue, Jun 21, 2022 at 1:30 AM Bruno Kinoshita  wrote:
>
> Hi Matt,
>
> Inspected NOTICE, LICENSE, RELEASE-NOTES, and found no issues. Checked out
> the tag, and `mvn clean test install site` passed with no errors.
>
> The README is still showing 2.7 in the download instructions. I **think**
> one of the preparation steps uses a release-plugin goal that re-generates
> this file with the correct version, but I could be wrong. Not sure if it's
> a blocker?
>
> Another thing that I noticed, but probably just nit-picking; opening a zip
> and a tar.gz file from dist/source folders each, and opening each file on
> Ubuntu LTS, I think not all files are UTF-8 encoded. The RELEASE-NOTES.txt
> fails to open on my Mousepad editor. It pops up an error dialogue that lets
> me try to guess the encoding to open it. Not an issue for me as I think it
> happens in other projects (I think CSV had a non-utf readme or release note
> too).
>
> Site reports look great.
>
> Tested signatures from Maven and from dist area, found no issues.
>
> [x] +1 Release these artifacts (if the README issue is not a blocker)
>
> Thanks!
> -Bruno
>
> On Tue, 21 Jun 2022 at 16:34, Matt Juntunen 
> wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Configuration 2.7 was released, so I would like
> > to release Apache Commons Configuration 2.8.
> >
> > Apache Commons Configuration 2.8 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1
> > (svn revision 55235)
> >
> > The Git tag commons-configuration-2.8-RC1 commit for this RC is
> > 01e1b40769f6dd5046c74f38c4c59cf4af5e37a1 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=01e1b40769f6dd5046c74f38c4c59cf4af5e37a1
> > You may checkout this tag using:
> > git clone
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > --branch
> > 
> > commons-configuration-2.8-RC1 commons-configuration-2.8-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1589/org/apache/commons/commons-configuration2/2.8/
> >
> > These are the artifacts and their hashes:
> >
> >
> > commons-configuration2-2.8.jar=c54782ba1d6340ccf0e136c66281af7bfcf3a78235f4a2461b50a88351a6da4f463cb19ca49afb25ff82712c4f4f14985c9f960ea65213deb1ca5a9719dead38
> >
> > commons-configuration2-2.8-sources.jar=1e277840f25d6a89b8f9168b5dd174093db38807b13e080aa47d26ff35602e4f5e4d6cf8bece6780af6791befd2204ce25710a8cd8eea62eabe3b554ea96e28c
> >
> > commons-configuration2-2.8-tests.jar=e0ffd6379863426f8b3237dd3ee64f7345c8d2876a34b736ba5f653af1e7cd99a8a3825938c60f842599f0a43922bbb32d13ea7f0c624b8dce25edf0150c6496
> >
> > commons-configuration2-2.8-test-sources.jar=f8c88936f415ab8357c96a73f9cb318e805b6a2ae47a9de9b3176c68b1fc1f4ca8880baf9045381a29af3d858be1c3b38b9f7f9bafd700f648004b591327dc1d
> >
> > commons-configuration2-2.8-bin.tar.gz=061227c898cf9094e30feebcf71d2811eecb01951793f30a6afca4f11075e5789231956b3d92b2caa5d65a24aa835026527b7d8b7dc81b1743306a48cae67ce4
> >
> > commons-configuration2-2.8-bin.zip=47a05cf9bcfee4e5f96f7d23af463bbf56e3d044ba1ea5faaeddb34f7056ca6590e15c83738a79a46c5d5d22885d5bac7dd3930a69d21b6a05c6645f0bcc383e
> >
> > commons-configuration2-2.8-src.tar.gz=eed2b99ebba4320799f8a11fde59c180022fd93f4c7b2c597398929368c92cce6828b163976c47629a0edf8fbc0e86be5cdf3e5f01cc734dd08f716038df026f
> >
> > commons-configuration2-2.8-src.zip=321365d65479889d16e27db4e03c52cfd8a4241b0a6ef2fe1f39d07f5beed4d5d9fb09d4101de77769ef634b2f9bda46a9ba4baa706540de42605c8c1e401c8f
> >
> > I have tested this with 'mvn clean install site' using:
> > ***
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 1.8.0_322, vendor: Temurin, runtime:
> > /home/matt/lang/java/jdk8u322-b06/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> > family: "unix"
> > ***
> >
> > Details of changes since 2.7 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1/RELEASE-NOTES.txt
> >
> > https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/changes-report.html
> >
> > Site:
> >
> > https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/index.html
> > (note some *relative* links are broken and the 2.8 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 2.7):
> >

Re: [CRYPTO] Updated docker build

[Alex Remily]

Then I was definitely looking at the wrong version of your file.  I'll
circle back and run it again.

On Tue, Jun 21, 2022 at 5:52 PM sebb  wrote:

> On Tue, 21 Jun 2022 at 22:32, Alex Remily  wrote:
> >
> >  previous
> > submission.>
> >
> > Don't know that it's an "improvement", but a different approach.  I think
> > if we provide a dockerfile that builds every supported arch (minus the
> Mac)
> > developers could easily modify it by removing parts they don't want as
> > opposed to adding dependencies and builds for the parts that they do.
>
> That is the case with my version.
> The builds are in separate script files that can be easily edited.
> And if a build fails due to a source issue, it can just be repeated
> after changing the source.
> No need to rebuild the image.
> Also no need to export the generated output as it is created on the host.
>
> > Also, I think this approach makes it easier for the next release manager
> > because it declares all the necessary dependencies and performs the
> builds
> > in the proper order.
>
> AFAICT there is no ordering issue with my version apart from linux32
> which needs an extra install.
>
> >  The last release was something of a challenge because
> > a lot of corporate knowledge had been lost when the original developers
> > left.
>
> Indeed.
>
> There is some documentation in the src/docker/README file, but it
> could be expanded.
>
> >  you
> > must have used a different checkout when you reported the failures.>
> >
> > I got sidetracked.  Apologies.  I need to do that and provide feedback.
> I
> > don't see why we can't have both, as long as we document them.
>
> I see no reason to have both.
>
> >  > updated.>
> >
> > As of this PR, it's in the POM but not in the dockerfile.
>
> Sorry, you are right.
> I thought I saw '32-bit build' but it was actually '32-bit Mac build'.
> Oops.
> We have already decided to drop that.
>
> > I see that you did a PR review.  I'll try to look at it tonight and
> > respond.
> >
> > Thanks.
> >
> > On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:
> >
> > > On Tue, 21 Jun 2022 at 20:00, Alex Remily 
> wrote:
> > > >
> > > > I went ahead and submitted a PR related to this discussion.  The
> > > dockerfile
> > > > does a full build, minus the Mac, and should simplify the release
> > > process.
> > >
> > > Not sure how it improves on the Docker build I derived from your
> > > previous submission.
> > >
> > > Did you try the sebb-docker branch again after my last reply?
> > > I think you must have used a different checkout when you reported the
> > > failures.
> > >
> > > > Developers can easily modify as needed for their own purposes.  I
> > > recommend
> > > > removing the 32-bit Mac build profile from the POM, but have not
> done so
> > > in
> > > > this PR.
> > >
> > > If it is removed from the POM then the Docker build will also need to
> > > be updated.
> > >
> > > Whilst it is unlikely that the 32 bit builds will be needed, at
> > > present they seem to work OK,
> > > so they might as well be kept.
> > >
> > > > Alex
> > > >
> > > > https://github.com/apache/commons-crypto/pull/166
> > > >
> > > > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> > > >
> > > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> > > wrote:
> > > > > >
> > > > > > Sebb,
> > > > > >
> > > > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > > > >
> > > > > > The Maven download link is broken.  It appears Apache updated to
> > > 3.8.6 on
> > > > > > the 17th.  I think the 3.6.3 build is less likely (although
> still not
> > > > > > certain--as you pointed out) to get overwritten.
> > > > >
> > > > > My build uses 3.6.3, so I think you may have got the wrong checkout
> > > > >
> > > > >
> > > > >
> > >
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> > > > >
> > > > > > RUN wget
> > > > > >
> > > > >
> > >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > > > > >
> > > > > >
> > > > > > I updated all the references to 3.6.3 and reran the build.
> > > > > >
> > > > > >
> > > > > > It seems there is a pathing issue on the container:
> > > > > >
> > > > > >
> > > > > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > > > > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > > > > >
> > > > > > #25 0.283 Error: Could not find or load main class
> > > > > > org.apache.commons.crypto.OsInfo
> > > > > >
> > > > > >
> > > > > > Note that it may not be possible to provide one *static*
> environment
> > > that
> > > > > > is capable of performing all builds.  This is because the 32-bit
> > > linux
> > > > > > build requires the "multilib" packages, and it appears that the
> > > > > "multilib"
> > > > > > packages overwrite the other gcc and g++ installations.  I
> happened
> > > > > across
> > > > > > this behavior when composing the full build dockerfile.  To
> > > illustrate,
> > > > > > refer to
> > > > > 

Re: [CRYPTO] Updated docker build

[sebb]

On Tue, 21 Jun 2022 at 22:32, Alex Remily  wrote:
>
>  submission.>
>
> Don't know that it's an "improvement", but a different approach.  I think
> if we provide a dockerfile that builds every supported arch (minus the Mac)
> developers could easily modify it by removing parts they don't want as
> opposed to adding dependencies and builds for the parts that they do.

That is the case with my version.
The builds are in separate script files that can be easily edited.
And if a build fails due to a source issue, it can just be repeated
after changing the source.
No need to rebuild the image.
Also no need to export the generated output as it is created on the host.

> Also, I think this approach makes it easier for the next release manager
> because it declares all the necessary dependencies and performs the builds
> in the proper order.

AFAICT there is no ordering issue with my version apart from linux32
which needs an extra install.

>  The last release was something of a challenge because
> a lot of corporate knowledge had been lost when the original developers
> left.

Indeed.

There is some documentation in the src/docker/README file, but it
could be expanded.

>  must have used a different checkout when you reported the failures.>
>
> I got sidetracked.  Apologies.  I need to do that and provide feedback.  I
> don't see why we can't have both, as long as we document them.

I see no reason to have both.

>  updated.>
>
> As of this PR, it's in the POM but not in the dockerfile.

Sorry, you are right.
I thought I saw '32-bit build' but it was actually '32-bit Mac build'. Oops.
We have already decided to drop that.

> I see that you did a PR review.  I'll try to look at it tonight and
> respond.
>
> Thanks.
>
> On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:
>
> > On Tue, 21 Jun 2022 at 20:00, Alex Remily  wrote:
> > >
> > > I went ahead and submitted a PR related to this discussion.  The
> > dockerfile
> > > does a full build, minus the Mac, and should simplify the release
> > process.
> >
> > Not sure how it improves on the Docker build I derived from your
> > previous submission.
> >
> > Did you try the sebb-docker branch again after my last reply?
> > I think you must have used a different checkout when you reported the
> > failures.
> >
> > > Developers can easily modify as needed for their own purposes.  I
> > recommend
> > > removing the 32-bit Mac build profile from the POM, but have not done so
> > in
> > > this PR.
> >
> > If it is removed from the POM then the Docker build will also need to
> > be updated.
> >
> > Whilst it is unlikely that the 32 bit builds will be needed, at
> > present they seem to work OK,
> > so they might as well be kept.
> >
> > > Alex
> > >
> > > https://github.com/apache/commons-crypto/pull/166
> > >
> > > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> > >
> > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> > wrote:
> > > > >
> > > > > Sebb,
> > > > >
> > > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > > >
> > > > > The Maven download link is broken.  It appears Apache updated to
> > 3.8.6 on
> > > > > the 17th.  I think the 3.6.3 build is less likely (although still not
> > > > > certain--as you pointed out) to get overwritten.
> > > >
> > > > My build uses 3.6.3, so I think you may have got the wrong checkout
> > > >
> > > >
> > > >
> > https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> > > >
> > > > > RUN wget
> > > > >
> > > >
> > https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > > > >
> > > > >
> > > > > I updated all the references to 3.6.3 and reran the build.
> > > > >
> > > > >
> > > > > It seems there is a pathing issue on the container:
> > > > >
> > > > >
> > > > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > > > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > > > >
> > > > > #25 0.283 Error: Could not find or load main class
> > > > > org.apache.commons.crypto.OsInfo
> > > > >
> > > > >
> > > > > Note that it may not be possible to provide one *static* environment
> > that
> > > > > is capable of performing all builds.  This is because the 32-bit
> > linux
> > > > > build requires the "multilib" packages, and it appears that the
> > > > "multilib"
> > > > > packages overwrite the other gcc and g++ installations.  I happened
> > > > across
> > > > > this behavior when composing the full build dockerfile.  To
> > illustrate,
> > > > > refer to
> > > > https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > > > > and notice lines 63-65.  Now move the multilib installs (lines 63
> > and 64)
> > > > > somewhere before the other 32 bit builds (line 58), and I expect
> > you'll
> > > > get
> > > > > a "not found" error during the build.
> > > >
> > > > Yes, I found that, and had to move linux32 into a separate build.
> > > >
> > > > It might perhaps be worth creating separate builds for 32 bit and 64
> > bit
> > > >
> > > > 

Re: [CRYPTO] Updated docker build

[Alex Remily]

Don't know that it's an "improvement", but a different approach.  I think
if we provide a dockerfile that builds every supported arch (minus the Mac)
developers could easily modify it by removing parts they don't want as
opposed to adding dependencies and builds for the parts that they do.
Also, I think this approach makes it easier for the next release manager
because it declares all the necessary dependencies and performs the builds
in the proper order.  The last release was something of a challenge because
a lot of corporate knowledge had been lost when the original developers
left.



I got sidetracked.  Apologies.  I need to do that and provide feedback.  I
don't see why we can't have both, as long as we document them.



As of this PR, it's in the POM but not in the dockerfile.

I see that you did a PR review.  I'll try to look at it tonight and
respond.

Thanks.

On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:

> On Tue, 21 Jun 2022 at 20:00, Alex Remily  wrote:
> >
> > I went ahead and submitted a PR related to this discussion.  The
> dockerfile
> > does a full build, minus the Mac, and should simplify the release
> process.
>
> Not sure how it improves on the Docker build I derived from your
> previous submission.
>
> Did you try the sebb-docker branch again after my last reply?
> I think you must have used a different checkout when you reported the
> failures.
>
> > Developers can easily modify as needed for their own purposes.  I
> recommend
> > removing the 32-bit Mac build profile from the POM, but have not done so
> in
> > this PR.
>
> If it is removed from the POM then the Docker build will also need to
> be updated.
>
> Whilst it is unlikely that the 32 bit builds will be needed, at
> present they seem to work OK,
> so they might as well be kept.
>
> > Alex
> >
> > https://github.com/apache/commons-crypto/pull/166
> >
> > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> >
> > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> wrote:
> > > >
> > > > Sebb,
> > > >
> > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > >
> > > > The Maven download link is broken.  It appears Apache updated to
> 3.8.6 on
> > > > the 17th.  I think the 3.6.3 build is less likely (although still not
> > > > certain--as you pointed out) to get overwritten.
> > >
> > > My build uses 3.6.3, so I think you may have got the wrong checkout
> > >
> > >
> > >
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> > >
> > > > RUN wget
> > > >
> > >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > > >
> > > >
> > > > I updated all the references to 3.6.3 and reran the build.
> > > >
> > > >
> > > > It seems there is a pathing issue on the container:
> > > >
> > > >
> > > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > > >
> > > > #25 0.283 Error: Could not find or load main class
> > > > org.apache.commons.crypto.OsInfo
> > > >
> > > >
> > > > Note that it may not be possible to provide one *static* environment
> that
> > > > is capable of performing all builds.  This is because the 32-bit
> linux
> > > > build requires the "multilib" packages, and it appears that the
> > > "multilib"
> > > > packages overwrite the other gcc and g++ installations.  I happened
> > > across
> > > > this behavior when composing the full build dockerfile.  To
> illustrate,
> > > > refer to
> > > https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > > > and notice lines 63-65.  Now move the multilib installs (lines 63
> and 64)
> > > > somewhere before the other 32 bit builds (line 58), and I expect
> you'll
> > > get
> > > > a "not found" error during the build.
> > >
> > > Yes, I found that, and had to move linux32 into a separate build.
> > >
> > > It might perhaps be worth creating separate builds for 32 bit and 64
> bit
> > >
> > > However they would be nearly 2GB each, unless some pruning can be done.
> > >
> > > >
> > > > I would welcome the effort to (in)validate my observations or to
> > > identify a
> > > > solution.  I agree that it would be nice to provide an environment
> that
> > > > supports all build profiles.  I'm just not certain it's
> supportable.  I
> > > > think the simplest way ahead may be to provide one dockerfile that
> does a
> > > > full multi-arch build and let developers modify it as they see fit to
> > > > perform more limited builds.  Much easier to remove existing builds
> than
> > > to
> > > > add them.  Local builds can be performed locally, as they are now.
> > >
> > > That's partly why I removed the Maven builds from the Docker build; it
> > > makes things more flexible.
> > >
> > > >
> > > > Alex
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Jun 18, 2022 at 6:53 PM sebb  wrote:
> > > >
> > > > > I took the very useful Dockerfile from Alex and updated it to split
> > > > > the Maven build into a separate script.
> > > > >
> > > > 

Re: [CRYPTO] Updated docker build

[sebb]

On Tue, 21 Jun 2022 at 20:00, Alex Remily  wrote:
>
> I went ahead and submitted a PR related to this discussion.  The dockerfile
> does a full build, minus the Mac, and should simplify the release process.

Not sure how it improves on the Docker build I derived from your
previous submission.

Did you try the sebb-docker branch again after my last reply?
I think you must have used a different checkout when you reported the failures.

> Developers can easily modify as needed for their own purposes.  I recommend
> removing the 32-bit Mac build profile from the POM, but have not done so in
> this PR.

If it is removed from the POM then the Docker build will also need to
be updated.

Whilst it is unlikely that the 32 bit builds will be needed, at
present they seem to work OK,
so they might as well be kept.

> Alex
>
> https://github.com/apache/commons-crypto/pull/166
>
> On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
>
> > On Mon, 20 Jun 2022 at 14:35, Alex Remily  wrote:
> > >
> > > Sebb,
> > >
> > > I cloned your repo and ran the dockerfile.  Feedback:
> > >
> > > The Maven download link is broken.  It appears Apache updated to 3.8.6 on
> > > the 17th.  I think the 3.6.3 build is less likely (although still not
> > > certain--as you pointed out) to get overwritten.
> >
> > My build uses 3.6.3, so I think you may have got the wrong checkout
> >
> >
> > https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> >
> > > RUN wget
> > >
> > https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > >
> > >
> > > I updated all the references to 3.6.3 and reran the build.
> > >
> > >
> > > It seems there is a pathing issue on the container:
> > >
> > >
> > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > >
> > > #25 0.283 Error: Could not find or load main class
> > > org.apache.commons.crypto.OsInfo
> > >
> > >
> > > Note that it may not be possible to provide one *static* environment that
> > > is capable of performing all builds.  This is because the 32-bit linux
> > > build requires the "multilib" packages, and it appears that the
> > "multilib"
> > > packages overwrite the other gcc and g++ installations.  I happened
> > across
> > > this behavior when composing the full build dockerfile.  To illustrate,
> > > refer to
> > https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > > and notice lines 63-65.  Now move the multilib installs (lines 63 and 64)
> > > somewhere before the other 32 bit builds (line 58), and I expect you'll
> > get
> > > a "not found" error during the build.
> >
> > Yes, I found that, and had to move linux32 into a separate build.
> >
> > It might perhaps be worth creating separate builds for 32 bit and 64 bit
> >
> > However they would be nearly 2GB each, unless some pruning can be done.
> >
> > >
> > > I would welcome the effort to (in)validate my observations or to
> > identify a
> > > solution.  I agree that it would be nice to provide an environment that
> > > supports all build profiles.  I'm just not certain it's supportable.  I
> > > think the simplest way ahead may be to provide one dockerfile that does a
> > > full multi-arch build and let developers modify it as they see fit to
> > > perform more limited builds.  Much easier to remove existing builds than
> > to
> > > add them.  Local builds can be performed locally, as they are now.
> >
> > That's partly why I removed the Maven builds from the Docker build; it
> > makes things more flexible.
> >
> > >
> > > Alex
> > >
> > >
> > >
> > >
> > > On Sat, Jun 18, 2022 at 6:53 PM sebb  wrote:
> > >
> > > > I took the very useful Dockerfile from Alex and updated it to split
> > > > the Maven build into a separate script.
> > > >
> > > > There are now two stages:
> > > > - create the build environment with all the necessary tools
> > > > - run Maven to build the various objects
> > > >
> > > > The container uses the source (and Maven repo) from the host, so the
> > > > output is generated on the host.
> > > >
> > > > This means it is easy to make source changes; the Docker build should
> > > > rarely need updating.
> > > > For details, please see
> > > > https://github.com/apache/commons-crypto/tree/sebb-docker/src/docker
> > > >
> > > > To try it, check out the sebb-docker branch and cd src/docker
> > > >
> > > > It probably needs some tweaking...
> > > >
> > > > Sebb
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

-
To 

Re: [CRYPTO] Updated docker build

[Alex Remily]

I went ahead and submitted a PR related to this discussion.  The dockerfile
does a full build, minus the Mac, and should simplify the release process.
Developers can easily modify as needed for their own purposes.  I recommend
removing the 32-bit Mac build profile from the POM, but have not done so in
this PR.

Alex

https://github.com/apache/commons-crypto/pull/166

On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:

> On Mon, 20 Jun 2022 at 14:35, Alex Remily  wrote:
> >
> > Sebb,
> >
> > I cloned your repo and ran the dockerfile.  Feedback:
> >
> > The Maven download link is broken.  It appears Apache updated to 3.8.6 on
> > the 17th.  I think the 3.6.3 build is less likely (although still not
> > certain--as you pointed out) to get overwritten.
>
> My build uses 3.6.3, so I think you may have got the wrong checkout
>
>
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
>
> > RUN wget
> >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> >
> >
> > I updated all the references to 3.6.3 and reran the build.
> >
> >
> > It seems there is a pathing issue on the container:
> >
> >
> > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> >
> > #25 0.283 Error: Could not find or load main class
> > org.apache.commons.crypto.OsInfo
> >
> >
> > Note that it may not be possible to provide one *static* environment that
> > is capable of performing all builds.  This is because the 32-bit linux
> > build requires the "multilib" packages, and it appears that the
> "multilib"
> > packages overwrite the other gcc and g++ installations.  I happened
> across
> > this behavior when composing the full build dockerfile.  To illustrate,
> > refer to
> https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > and notice lines 63-65.  Now move the multilib installs (lines 63 and 64)
> > somewhere before the other 32 bit builds (line 58), and I expect you'll
> get
> > a "not found" error during the build.
>
> Yes, I found that, and had to move linux32 into a separate build.
>
> It might perhaps be worth creating separate builds for 32 bit and 64 bit
>
> However they would be nearly 2GB each, unless some pruning can be done.
>
> >
> > I would welcome the effort to (in)validate my observations or to
> identify a
> > solution.  I agree that it would be nice to provide an environment that
> > supports all build profiles.  I'm just not certain it's supportable.  I
> > think the simplest way ahead may be to provide one dockerfile that does a
> > full multi-arch build and let developers modify it as they see fit to
> > perform more limited builds.  Much easier to remove existing builds than
> to
> > add them.  Local builds can be performed locally, as they are now.
>
> That's partly why I removed the Maven builds from the Docker build; it
> makes things more flexible.
>
> >
> > Alex
> >
> >
> >
> >
> > On Sat, Jun 18, 2022 at 6:53 PM sebb  wrote:
> >
> > > I took the very useful Dockerfile from Alex and updated it to split
> > > the Maven build into a separate script.
> > >
> > > There are now two stages:
> > > - create the build environment with all the necessary tools
> > > - run Maven to build the various objects
> > >
> > > The container uses the source (and Maven repo) from the host, so the
> > > output is generated on the host.
> > >
> > > This means it is easy to make source changes; the Docker build should
> > > rarely need updating.
> > > For details, please see
> > > https://github.com/apache/commons-crypto/tree/sebb-docker/src/docker
> > >
> > > To try it, check out the sebb-docker branch and cd src/docker
> > >
> > > It probably needs some tweaking...
> > >
> > > Sebb
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[collections] JMH results for IndexedLinkedList

[Rodion Efremov]

Hi,

Data structure: IndexedLinkedList

Benchmark: IndexedLinkedListBenchmark


Benchmark output:
https://github.com/coderodde/indexedLinkedList/#benchmark-output

>From the benchmark output, we can judge that IndexedLinkedList outperforms
both java.util.LinkedList and the Apache Commons Collections TreeList. It,
however, does not seem to supersede the java.util.ArrayList.

Basically, I would expect the IndexedLinkedList to beat the ArrayList where
we have a lot of following operations:

   - addFirst(E)
   - add(int, E)
   - remove(int)

So, what do you think? I am getting anywhere with that?

Best regards,
rodde