Fwd: [RESULT[[VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2

[Bruno Kinoshita]

Forgot to include Gary Lucas' +1 (non-binding), sorry! Got confused with
the Gary's when counting the votes, sorry :)

-Bruno

-- Forwarded message -
From: Bruno Kinoshita 
Date: Thu, 19 May 2022 at 14:16
Subject: [RESULT[[VOTE] Release Apache Commons Imaging 1.0-alpha3 based on
RC2
To: 


This vote has passed with the following votes:

Gary Gregory +1
Andreas Lehmkuehler +1 (non-binding)
Arturo Bernal +1 (non-binding)
Matt Juntunen +1
Bruno P. Kinoshita +1
Thomas Vandahl +1

I will finalize the release in the next few hours.

Thanks a lot to everybody who voted and helped test this release, as well
as other contributors and users that helped with the changes in it.

-Bruno

On Sat, 14 May 2022 at 00:02, Bruno Kinoshita  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Imaging 1.0-alpha2 was released, so I would like to
> release Apache Commons Imaging 1.0-alpha3.
>
> Apache Commons Imaging 1.0-alpha3 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2
> (svn revision 54488)
>
> The Git tag commons-imaging-1.0-alpha3-RC2 commit for this RC is
> bef4caa54f8e736644f3d5bb4658d5c3c95ec70a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=bef4caa54f8e736644f3d5bb4658d5c3c95ec70a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-imaging.git
> --branch commons-imaging-1.0-alpha3-RC2 commons-imaging-1.0-alpha3-RC2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1587/org/apache/commons/commons-imaging/1.0-alpha3/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri May 13 23:32:54 NZST 2022
>
> commons-imaging-1.0-alpha3-tests.jar=6fad2edc85f4428de195e2dafe5b3cc2be19307b8b1dcc00c6ceaa92eb7767cfb4621c9a3a7c433e1486997f11f05114c04275a8129fe5f15999f1414baa9041
>
> commons-imaging-1.0-alpha3-sources.jar=5e2f5ad8c6d9b988569793e707926d40498dbc07f7404027d67ec67fa061e1aea9947f7d05a9cf60290326689c6296287055e8b9f334426ebab76620152fff1e
>
> commons-imaging-1.0-alpha3-bin.zip=bdf53a57521aea0c11c20e0884cbb68cc756ebee34f0d48319816333e600777caf04ded543a4f2560d1adef7dd2993c0cc9b4e32e3db6d024a950650222cc277
>
> commons-imaging-1.0-alpha3-src.zip=73511d7068a665471805af6a832b26fa5f2f32ea1a716c0cac9a5b3a2d47cfd2e343b35a2ae79d29fa22dc54586be274c4500d209e057a544776b8f0e77cb7cb
>
> commons-imaging-1.0-alpha3-javadoc.jar=624c8cafa60159be44392c51e515617548526fbe40b56f45d3f0ccc83f220a59145de474d6428e5ede383f536a18ccd4382c7673d0a14ba3b9d9cd82db4ffe6e
>
> commons-imaging-1.0-alpha3-test-sources.jar=a5204a827e9d5b8fa1d98967f7b416c9a1af81eb0d9009fc0159447dbdab56e18cdaaaf10ea50b0dfc941f6668f21df1c1a49df1c051dd8cda79a3e3f00c0572
>
> commons-imaging-1.0-alpha3-bin.tar.gz=877c1b28fe8fd82207d6873673e23b3ced73f09c9bd20fcfe35ff72be8480e1d0558f966fdbdd25dacef92fca02643b0cd0cdb27928914a77fad65dd47feea7d
>
> commons-imaging-1.0-alpha3-src.tar.gz=16300adb5873fef464bedfdce7e1368f52add8d33087f059667840880b8666024feeecdb278a53d5c3d8e76d01ab921ea146d41ca688757f0cf0c2f2b32b0d53
>
> I have tested this with ***'mvn clean install site'*** using:
> ***
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 11.0.15, vendor: Private Build, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-110-generic", arch: "amd64", family:
> "unix"
> ***
>
> Details of changes since 1.0-alpha2 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/site/index.html
> (note some *relative* links are broken and the 1.0-alpha3 directories
> are not yet created - these will be OK once the site is deployed.)
>
> CLIRR and JApiCmp reports are not being used during the alpha releases,
> but will be used again in the
> 1.0 release (alpha3 is expected to be the last 1.0 alpha release.)
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-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,
>
> Bruno P. Kinoshita,
> Release Manager (using key 33C6E01240C5468C2B7A556954E2764B48A42DF0)
>
> The following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are 

[RESULT[[VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2

[Bruno Kinoshita]

This vote has passed with the following votes:

Gary Gregory +1
Andreas Lehmkuehler +1 (non-binding)
Arturo Bernal +1 (non-binding)
Matt Juntunen +1
Bruno P. Kinoshita +1
Thomas Vandahl +1

I will finalize the release in the next few hours.

Thanks a lot to everybody who voted and helped test this release, as well
as other contributors and users that helped with the changes in it.

-Bruno

On Sat, 14 May 2022 at 00:02, Bruno Kinoshita  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Imaging 1.0-alpha2 was released, so I would like to
> release Apache Commons Imaging 1.0-alpha3.
>
> Apache Commons Imaging 1.0-alpha3 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2
> (svn revision 54488)
>
> The Git tag commons-imaging-1.0-alpha3-RC2 commit for this RC is
> bef4caa54f8e736644f3d5bb4658d5c3c95ec70a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=bef4caa54f8e736644f3d5bb4658d5c3c95ec70a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-imaging.git
> --branch commons-imaging-1.0-alpha3-RC2 commons-imaging-1.0-alpha3-RC2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1587/org/apache/commons/commons-imaging/1.0-alpha3/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri May 13 23:32:54 NZST 2022
>
> commons-imaging-1.0-alpha3-tests.jar=6fad2edc85f4428de195e2dafe5b3cc2be19307b8b1dcc00c6ceaa92eb7767cfb4621c9a3a7c433e1486997f11f05114c04275a8129fe5f15999f1414baa9041
>
> commons-imaging-1.0-alpha3-sources.jar=5e2f5ad8c6d9b988569793e707926d40498dbc07f7404027d67ec67fa061e1aea9947f7d05a9cf60290326689c6296287055e8b9f334426ebab76620152fff1e
>
> commons-imaging-1.0-alpha3-bin.zip=bdf53a57521aea0c11c20e0884cbb68cc756ebee34f0d48319816333e600777caf04ded543a4f2560d1adef7dd2993c0cc9b4e32e3db6d024a950650222cc277
>
> commons-imaging-1.0-alpha3-src.zip=73511d7068a665471805af6a832b26fa5f2f32ea1a716c0cac9a5b3a2d47cfd2e343b35a2ae79d29fa22dc54586be274c4500d209e057a544776b8f0e77cb7cb
>
> commons-imaging-1.0-alpha3-javadoc.jar=624c8cafa60159be44392c51e515617548526fbe40b56f45d3f0ccc83f220a59145de474d6428e5ede383f536a18ccd4382c7673d0a14ba3b9d9cd82db4ffe6e
>
> commons-imaging-1.0-alpha3-test-sources.jar=a5204a827e9d5b8fa1d98967f7b416c9a1af81eb0d9009fc0159447dbdab56e18cdaaaf10ea50b0dfc941f6668f21df1c1a49df1c051dd8cda79a3e3f00c0572
>
> commons-imaging-1.0-alpha3-bin.tar.gz=877c1b28fe8fd82207d6873673e23b3ced73f09c9bd20fcfe35ff72be8480e1d0558f966fdbdd25dacef92fca02643b0cd0cdb27928914a77fad65dd47feea7d
>
> commons-imaging-1.0-alpha3-src.tar.gz=16300adb5873fef464bedfdce7e1368f52add8d33087f059667840880b8666024feeecdb278a53d5c3d8e76d01ab921ea146d41ca688757f0cf0c2f2b32b0d53
>
> I have tested this with ***'mvn clean install site'*** using:
> ***
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 11.0.15, vendor: Private Build, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-110-generic", arch: "amd64", family:
> "unix"
> ***
>
> Details of changes since 1.0-alpha2 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2/site/index.html
> (note some *relative* links are broken and the 1.0-alpha3 directories
> are not yet created - these will be OK once the site is deployed.)
>
> CLIRR and JApiCmp reports are not being used during the alpha releases,
> but will be used again in the
> 1.0 release (alpha3 is expected to be the last 1.0 alpha release.)
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-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,
>
> Bruno P. Kinoshita,
> Release Manager (using key 33C6E01240C5468C2B7A556954E2764B48A42DF0)
>
> The 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-imaging.git
> --branch commons-imaging-1.0-alpha3-RC2 commons-imaging-1.0-alpha3-RC2

Re: [Crypto] How to build?

[Bruno Kinoshita]

Hi,

There's a Dockerfile in the commons-crypto repo on GitHub. Not sure if it's
used for building it... but just in case it helps.

https://github.com/apache/commons-crypto/blob/master/src/conf/Docker/Dockerfile-luw


-Bruno


On Thu, 19 May 2022 at 07:58, Jochen Wiedmann 
wrote:

> On Wed, May 18, 2022 at 9:15 PM Gary Gregory 
> wrote:
> >
> > Yeah, I recall wanting to add a dockerfile... but if it's not there I'll
> > have to go hunt around for it and the notes I might have from that
> > release...
>
> Please do, Gary.
>
> Thanks,
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] How to build?

[Jochen Wiedmann]

On Wed, May 18, 2022 at 9:15 PM Gary Gregory  wrote:
>
> Yeah, I recall wanting to add a dockerfile... but if it's not there I'll
> have to go hunt around for it and the notes I might have from that
> release...

Please do, Gary.

Thanks,

Jochen

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

Re: [Crypto] How to build?

[Gary Gregory]

Yeah, I recall wanting to add a dockerfile... but if it's not there I'll
have to go hunt around for it and the notes I might have from that
release...

Gary

On Wed, May 18, 2022, 14:58 Alex Remily  wrote:

> I agree that a Docker build is a good idea.  In fact, I *thought* the
> project already had a Dockerfile from the release process for 1.1.0.  I'm
> certain that at least one contributor created one, but apparently it never
> made the baseline.  I don't recall if it was actually used to build the
> release.  Gary was the release manager, so he is probably the person most
> likely to recall or to be aware of a functional Dockerfile's existence or
> current location.
>
> Alex
>
> On Wed, May 18, 2022 at 2:34 PM Bernd Eckenfels 
> wrote:
>
> > Hello Jochen,
> >
> > I think that’s useful with the container. I would shift it relative to
> the
> > source project, then you don’t need the wget and git clone but can use
> > copy;mount to provide the source from the current version.
> >
> > But that’s probably not related to the problems you encounter.
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Jochen Wiedmann 
> > Gesendet: Wednesday, May 18, 2022 4:59:43 PM
> > An: Apache Commons Developers List 
> > Betreff: [Crypto] How to build?
> >
> > Hi,
> >
> > I recently had the questionable pleasure to get in touch with Commons
> > Crypto, and could not build it. There are some instructions in the
> > BUILDING.txt file, but they aren't really helpful. In case, you don't
> > know: Crypto is not a simple Java library. Instead, it requires
> > building some shared libraries from C sources, that are being added to
> > the jar file.
> >
> > The main problem here: We do not have something like a fully automated
> > build procedure, that
> >
> >   a) ensures that the requirements are met, and then
> >   b) performs all the necessary steps for building that jar file.
> >
> > Thinking about that, I came up with the idea, that we could add a
> > Dockerfile to the sources, that could then be used with some simple
> > commands, like
> >
> > docker image build -t apache/commons-crypto:1.1.1-SNAPSHOT
> > docker container run --name mycrypto
> > apache/commons-crypto:1.1.1-SNAPSHOT
> > docker container cp
> > "mycrypto:/usr/local/build/commons-crypto/target/*.jar" .
> >
> > (Not sure, that these might actually work, Docker beginner.)
> >
> > So, I started working with the Docker file below: Unfortnately, that
> fails
> > with
> > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > #26 0.624 Error: Could not find or load main class
> > org.apache.commons.crypto.OsInfo
> > #26 0.697 Error: Could not find or load main class
> > org.apache.commons.crypto.OsInfo
> > #26 0.778 Error: Could not find or load main class
> > org.apache.commons.crypto.OsInfo
> > #26 0.790 make: *** No rule to make target
> >
> >
> 'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
> > needed by
> > 'target/commons-crypto-1.1.1-SNAPSHOT--/OpenSslCryptoRandomNative.o'.
> > Stop.
> >
> > And that's, where I could need your help. What's wong?
> >
> > Thanks,
> >
> > Jochen
> >
> >
> >
> > FROM ubuntu:bionic-20220401
> > RUN dpkg --add-architecture i386
> > RUN apt update
> > RUN apt-get -y install gcc
> > RUN apt-get -y install g++
> > RUN apt-get -y install make
> > RUN apt-get -y install wget curl
> > RUN apt-get -y install git
> > RUN apt-get -y install openjdk-8-jdk
> > RUN apt-get -y -oDebug::pkgAcquire::Worker=1 install openjdk-11-jdk
> > RUN apt-get install -y mingw-w64
> > # This package is documented in BUILDING.txt, but doesn't appear to be
> > available.
> > # RUN apt-get install -y x86_64-w64-mingw32-gcc
> > RUN apt-get install -y gcc-mingw-w64-i686
> > RUN apt-get install -y libssl-dev:i386 libssl-dev
> > RUN apt-get install -y g++-multilib
> > RUN mkdir -p /usr/local/build
> > WORKDIR /usr/local/build
> > RUN wget
> >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > RUN tar xzf apache-maven-3.8.5-bin.tar.gz
> > RUN ln -s ../build/apache-maven-3.8.5/bin/mvn /usr/local/bin
> > RUN git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> > commons-crypto
> > 
> > WORKDIR /usr/local/build/commons-crypto
> > RUN VERSION=1.1.1-SNAPSHOT JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
> make
> > RUN mvn
> > CMD bash
> >
> >
> >
> >
> > --
> > Philosophy is useless, theology is worse. (Industrial Desease, Dire
> > Straits)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [Crypto] How to build?

[Alex Remily]

I agree that a Docker build is a good idea.  In fact, I *thought* the
project already had a Dockerfile from the release process for 1.1.0.  I'm
certain that at least one contributor created one, but apparently it never
made the baseline.  I don't recall if it was actually used to build the
release.  Gary was the release manager, so he is probably the person most
likely to recall or to be aware of a functional Dockerfile's existence or
current location.

Alex

On Wed, May 18, 2022 at 2:34 PM Bernd Eckenfels 
wrote:

> Hello Jochen,
>
> I think that’s useful with the container. I would shift it relative to the
> source project, then you don’t need the wget and git clone but can use
> copy;mount to provide the source from the current version.
>
> But that’s probably not related to the problems you encounter.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Jochen Wiedmann 
> Gesendet: Wednesday, May 18, 2022 4:59:43 PM
> An: Apache Commons Developers List 
> Betreff: [Crypto] How to build?
>
> Hi,
>
> I recently had the questionable pleasure to get in touch with Commons
> Crypto, and could not build it. There are some instructions in the
> BUILDING.txt file, but they aren't really helpful. In case, you don't
> know: Crypto is not a simple Java library. Instead, it requires
> building some shared libraries from C sources, that are being added to
> the jar file.
>
> The main problem here: We do not have something like a fully automated
> build procedure, that
>
>   a) ensures that the requirements are met, and then
>   b) performs all the necessary steps for building that jar file.
>
> Thinking about that, I came up with the idea, that we could add a
> Dockerfile to the sources, that could then be used with some simple
> commands, like
>
> docker image build -t apache/commons-crypto:1.1.1-SNAPSHOT
> docker container run --name mycrypto
> apache/commons-crypto:1.1.1-SNAPSHOT
> docker container cp
> "mycrypto:/usr/local/build/commons-crypto/target/*.jar" .
>
> (Not sure, that these might actually work, Docker beginner.)
>
> So, I started working with the Docker file below: Unfortnately, that fails
> with
> > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> #26 0.624 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.697 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.778 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.790 make: *** No rule to make target
>
> 'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
> needed by
> 'target/commons-crypto-1.1.1-SNAPSHOT--/OpenSslCryptoRandomNative.o'.
> Stop.
>
> And that's, where I could need your help. What's wong?
>
> Thanks,
>
> Jochen
>
>
>
> FROM ubuntu:bionic-20220401
> RUN dpkg --add-architecture i386
> RUN apt update
> RUN apt-get -y install gcc
> RUN apt-get -y install g++
> RUN apt-get -y install make
> RUN apt-get -y install wget curl
> RUN apt-get -y install git
> RUN apt-get -y install openjdk-8-jdk
> RUN apt-get -y -oDebug::pkgAcquire::Worker=1 install openjdk-11-jdk
> RUN apt-get install -y mingw-w64
> # This package is documented in BUILDING.txt, but doesn't appear to be
> available.
> # RUN apt-get install -y x86_64-w64-mingw32-gcc
> RUN apt-get install -y gcc-mingw-w64-i686
> RUN apt-get install -y libssl-dev:i386 libssl-dev
> RUN apt-get install -y g++-multilib
> RUN mkdir -p /usr/local/build
> WORKDIR /usr/local/build
> RUN wget
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> RUN tar xzf apache-maven-3.8.5-bin.tar.gz
> RUN ln -s ../build/apache-maven-3.8.5/bin/mvn /usr/local/bin
> RUN git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> commons-crypto
> 
> WORKDIR /usr/local/build/commons-crypto
> RUN VERSION=1.1.1-SNAPSHOT JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make
> RUN mvn
> CMD bash
>
>
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Desease, Dire
> Straits)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] How to build?

[Bernd Eckenfels]

Hello Jochen,

I think that’s useful with the container. I would shift it relative to the 
source project, then you don’t need the wget and git clone but can use 
copy;mount to provide the source from the current version.

But that’s probably not related to the problems you encounter.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Jochen Wiedmann 
Gesendet: Wednesday, May 18, 2022 4:59:43 PM
An: Apache Commons Developers List 
Betreff: [Crypto] How to build?

Hi,

I recently had the questionable pleasure to get in touch with Commons
Crypto, and could not build it. There are some instructions in the
BUILDING.txt file, but they aren't really helpful. In case, you don't
know: Crypto is not a simple Java library. Instead, it requires
building some shared libraries from C sources, that are being added to
the jar file.

The main problem here: We do not have something like a fully automated
build procedure, that

  a) ensures that the requirements are met, and then
  b) performs all the necessary steps for building that jar file.

Thinking about that, I came up with the idea, that we could add a
Dockerfile to the sources, that could then be used with some simple
commands, like

docker image build -t apache/commons-crypto:1.1.1-SNAPSHOT
docker container run --name mycrypto apache/commons-crypto:1.1.1-SNAPSHOT
docker container cp
"mycrypto:/usr/local/build/commons-crypto/target/*.jar" .

(Not sure, that these might actually work, Docker beginner.)

So, I started working with the Docker file below: Unfortnately, that fails with
> [22/23] RUN VERSION=1.1.1-SNAPSHOT
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
#26 0.624 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.697 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.778 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.790 make: *** No rule to make target
'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
needed by 'target/commons-crypto-1.1.1-SNAPSHOT--/OpenSslCryptoRandomNative.o'.
Stop.

And that's, where I could need your help. What's wong?

Thanks,

Jochen



FROM ubuntu:bionic-20220401
RUN dpkg --add-architecture i386
RUN apt update
RUN apt-get -y install gcc
RUN apt-get -y install g++
RUN apt-get -y install make
RUN apt-get -y install wget curl
RUN apt-get -y install git
RUN apt-get -y install openjdk-8-jdk
RUN apt-get -y -oDebug::pkgAcquire::Worker=1 install openjdk-11-jdk
RUN apt-get install -y mingw-w64
# This package is documented in BUILDING.txt, but doesn't appear to be
available.
# RUN apt-get install -y x86_64-w64-mingw32-gcc
RUN apt-get install -y gcc-mingw-w64-i686
RUN apt-get install -y libssl-dev:i386 libssl-dev
RUN apt-get install -y g++-multilib
RUN mkdir -p /usr/local/build
WORKDIR /usr/local/build
RUN wget 
https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
RUN tar xzf apache-maven-3.8.5-bin.tar.gz
RUN ln -s ../build/apache-maven-3.8.5/bin/mvn /usr/local/bin
RUN git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
commons-crypto
WORKDIR /usr/local/build/commons-crypto
RUN VERSION=1.1.1-SNAPSHOT JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make
RUN mvn
CMD bash




--
Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)

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

Re: [text] Hexadecimal characters in decimal numeric entities

[Richard BUNEL]

Hello,

Given the absence of answers, I thought I might add another argument to my
point.

While I didn't mention it in my first post, please consider that the
semiColonOptional

option
is never activated by default.
The constructor

of
the NumericEntityUnescaper class uses by default the DEFAULT_OPTION

which
is set to the semiColonRequired

 value.

Then, the UNESCAPE_HTML4

translator
in the StringEscapeUtils class, which is in turn used by the unescapeHtml4

method,
indeed calls the aforementioned constructor.
All of this is consistent with the fact that, by default, the Commons Text
library requires semicolons to be used after numeric HTML entities, and as
such follows strictly the HTML specification.

However, the semiColonOptional

option
does exist and may be used in certain ways. Therefore, I think we can
expect it to work correctly if used with decimal entities.
That's the point of my commit, nothing more than that.
I hope this little explanation might help you make your opinion.

Thanks in advance,
Richard

Le mar. 10 mai 2022 à 09:48, Richard BUNEL  a écrit :

> Hi everyone,
>
> We're having a debate (in the comment section of this PR
> ) on the legitimacy of
> unescaping semicolon-less numerical character entities in Commons-Text.
>
> The possibility to unescape such entities has long been part of the
> library, via the semiColonOptional
> 
>  option
> in the NumericEntityUnescaper class.
>
> While testing this option, I discovered a small bug which allows to bypass
> the unescaper.
> A string like this: ** is
> ignored by the unescaper, because even though this entity is a decimal one,
> the algorithm searches for hexidecimal characters in all cases and includes
> the "a" after the "6".
> This prompted me to fix it in this commit
> 
>  and
> open the PR.
>
> However, as mentioned earlier, there is a debate on the legitimacy of
> unescaping semicolon-less from the beginning.
>
> The point of garydgregory is that such entities do not form part of the
> HTML specification and as such Commons-Text should not consider it.
>
> My point and kinow's however, is that these semicolon-less entities are
> unescaped by virtually every modern browsers (tested with Chrome, Firefox,
> Edge and Safari) and that Commos-Text could reasonnably expect the library
> to support them.
>
> Also, I pointed that my fix only makes the unsecaping work correctly with
> decimal entities, so in my opinion the PR shouldn't be blocked by the
> debate.
>
> What's your opinion about it ?
>
> Thanks !
> Richard
>
> https://github.com/apache/commons-text/pull/310
>

[Crypto] How to build?

[Jochen Wiedmann]

Hi,

I recently had the questionable pleasure to get in touch with Commons
Crypto, and could not build it. There are some instructions in the
BUILDING.txt file, but they aren't really helpful. In case, you don't
know: Crypto is not a simple Java library. Instead, it requires
building some shared libraries from C sources, that are being added to
the jar file.

The main problem here: We do not have something like a fully automated
build procedure, that

  a) ensures that the requirements are met, and then
  b) performs all the necessary steps for building that jar file.

Thinking about that, I came up with the idea, that we could add a
Dockerfile to the sources, that could then be used with some simple
commands, like

docker image build -t apache/commons-crypto:1.1.1-SNAPSHOT
docker container run --name mycrypto apache/commons-crypto:1.1.1-SNAPSHOT
docker container cp
"mycrypto:/usr/local/build/commons-crypto/target/*.jar" .

(Not sure, that these might actually work, Docker beginner.)

So, I started working with the Docker file below: Unfortnately, that fails with
> [22/23] RUN VERSION=1.1.1-SNAPSHOT
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
#26 0.624 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.697 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.778 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo
#26 0.790 make: *** No rule to make target
'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
needed by 'target/commons-crypto-1.1.1-SNAPSHOT--/OpenSslCryptoRandomNative.o'.
Stop.

And that's, where I could need your help. What's wong?

Thanks,

Jochen



FROM ubuntu:bionic-20220401
RUN dpkg --add-architecture i386
RUN apt update
RUN apt-get -y install gcc
RUN apt-get -y install g++
RUN apt-get -y install make
RUN apt-get -y install wget curl
RUN apt-get -y install git
RUN apt-get -y install openjdk-8-jdk
RUN apt-get -y -oDebug::pkgAcquire::Worker=1 install openjdk-11-jdk
RUN apt-get install -y mingw-w64
# This package is documented in BUILDING.txt, but doesn't appear to be
available.
# RUN apt-get install -y x86_64-w64-mingw32-gcc
RUN apt-get install -y gcc-mingw-w64-i686
RUN apt-get install -y libssl-dev:i386 libssl-dev
RUN apt-get install -y g++-multilib
RUN mkdir -p /usr/local/build
WORKDIR /usr/local/build
RUN wget 
https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
RUN tar xzf apache-maven-3.8.5-bin.tar.gz
RUN ln -s ../build/apache-maven-3.8.5/bin/mvn /usr/local/bin
RUN git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
commons-crypto
WORKDIR /usr/local/build/commons-crypto
RUN VERSION=1.1.1-SNAPSHOT JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make
RUN mvn
CMD bash




-- 
Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)

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

Re: [Math] Review of "genetic algorithm" module

[Avijit Basak]

Hi All

Please find my comments below.

Comments related to new model:

1) Hierarchy of GeneticOperator: In the proposed model the genetic
operators are designed hierarchically implementing a common interface and
operators are accepted as a list.
This enables interchangeability of operators. Library users would be able
to use crossover and mutation operators interchangeably.
However, in genetic algorithms or other population based search algorithms
the operators are used for broadly two purposes, exploration and
exploitation.
In GA crossover is used for exploitation and mutation is used for
exploration. Keeping them in a common hierarchy and allowing
interchangeable operation violates that purpose.

2) Chromosome Fitness: In the new design the chromosome fitness is
maintained as a hashmap where the key is the chromosome itself.
Are we going to retain the fitness value in chromosome too otherwise
implementation of Comparable won't be possible?
Assuming the chromosome representation would be used to calculate hashcode,
it would be a very time consuming process depending on the length of
chromosome.
E.g. in binary chromosomes we have provision to allow chromosome length
upto (2^31 - 1). Along with that the chromosome implements Comparable
interface.
Equality by Comparable interface would be decided by fitness however
equality by equals() method would depend on representation.
As chromosomes with different representations may also have the same
fitness, this would produce a conflict.

3) The model does not consider anything related to adaptive approaches.
Would it be a separate factory?

4) Comparison of chromosomes: In the current model two chromosomes are
compared after decoding the genotype to phenotype using the internal
decoder.
How can we address this in the new model?

5) Chromosome String representation: Currently we use the toString() method
to print the chromosome's phenotype. In the new model we would need to
avoid this approach as decoders won't be available to chromosomes.

6) However in the new model the generic type parameters and java.util
packages are used in a more organized way. We can adopt the same in the
existing model.



>If we need to document software (e.g. the "examples") produced
>by a "Commons" component, it is preferable that we use and refer
>to "Log4j2".
>[The logger API is another matter since it does not impact how the
>software is used (from a user's POV).]
-- I shall make the changes.

>
>> >
>> >> There was a discussion
>> >> earlier on this and the decision was to use console for example
modules
>> >> log messages.
>> >
>> >I recall that we want a separation between the logger API (library
>> >dependency) and logger implementation ("examples" dependency).
>> >
>> >Is it a feature of "slf4j-simple" to only print to "stderr" or can it
>> >be configured?
>> >There is no issue on the "examples" module to depend on a
>> >full-featured logger (primary candidate would be "Log4j2").
>> --Already mentioned earlier.
>
>We should change SimpleLogger -> Log4j2 equivalent.
--I shall do this.

[...]
>Doing manually will be too tedious.
>If you are reasonably confident that you've ported everything
>valuable, I guess that we'll rely on coverage tools...
>The current log statements could also be construed as (totally)
>unnecessary, as they merely document statements which I would
>consider part of an "application", not the GA "library".
>I believe that we do not agree yet on where to draw the line (my
>proposal in MATH-1618 is related to that difference of opinion).
>
-- Probably I am missing something here. These log statements are more
useful for library users. If we remove all log statements how users would
be able to debug any issue.
What if there are issues in any part of library code or may be anything
fails due to some application related customization.
It may not be necessarily a library bug.

>> >> >Likewise, the "PopulationStatisticsLogger" is not general enough to
>> >> >be worth being part of the library.
>> >> -- I would love to keep this simple implementation of convergence
>> >> listener. This can provide a very basic overview on the nature of
>> >> convergence.
>> >
>> >As a user, you'll be able to provide the feature to your application
>> >with less than 10 lines of code (by registering a "listener").
>> >Everyone else might want a slightly different output (contents and/or
>> >format) than what this class generates.
>> -- Users would always have the freedom to register their own listener.
>> PopulationStatisticsLogger provides only a very basic option to track the
>> population statistics during the convergence process.
>> This is never a very generic solution to meet the needs of all users.
>
>AFAICT, the "PopulationStatisticsLogger" class satisfies *your* needs
>(as a user), but as developers we should only include functionality that
>is broadly useful.  I think I provided arguments that it is not the case of
>that class.
-- So do you want this class to be