On Tue, 21 Jun 2022 at 20:00, Alex Remily <alex.rem...@gmail.com> 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 <seb...@gmail.com> wrote: > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily <alex.rem...@gmail.com> 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 <seb...@gmail.com> 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 unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
