<That is the case with my version.> 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 <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 > >
