I've merged the docker build into the default branch. It may not be perfect, but it does work well enough!
On Wed, 22 Jun 2022 at 17:14, sebb <seb...@gmail.com> wrote: > > On Wed, 22 Jun 2022 at 15:59, Alex Remily <alex.rem...@gmail.com> wrote: > > > > I went back and reviewed docker setup at your link: > > > > https://github.com/apache/commons-crypto/tree/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker > > > > Nice work. > > Props to you for getting the initial build working. > I just tweaked it. > > > I agree that it's more flexible and provides the same > > capability. The instructions were straightforward and the end result was a > > full build. One can also experiment via the command line, which is nice. > > A couple of comments. The comments on lines 16-21 should be removed, as > > you've provided updated instructions in the readme. > > Done. > > > I recall that during > > the last release process I recommended using 18.04 as the base image and > > was overruled because of backwards compatibility concerns with the native > > binaries. I don't know that I share those concerns, but that was the > > rationale for using the older base. > > I see. > Hopefully not an issue anymore? > > > Otherwise, it seems ready to commit and close out 120 and 132. > > > > Alex > > > > On Tue, Jun 21, 2022 at 5:52 PM sebb <seb...@gmail.com> wrote: > > > > > On Tue, 21 Jun 2022 at 22:32, Alex Remily <alex.rem...@gmail.com> wrote: > > > > > > > > <Not sure how it improves on the Docker build I derived from your > > > 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. > > > > > > > <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.> > > > > > > > > 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. > > > > > > > <If it is removed from the POM then the Docker build will also need to > > > > be > > > > 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 <seb...@gmail.com> wrote: > > > > > > > > > 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 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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
