sebb,

Thanks for taking the time to test it out and provide feedback.  Much
appreciated.  My thoughts below.

<It works for me using Docker on macOS, though the output is in the
container and it's not obvious how to extract it.>

Good point.  I could modify the script to dump the final artifact in the
project root directory.

<I think it would be advisable to install Maven as a separate run step; if
a new version is released (e.g. 3.6.4) the link will break.>

That link is static to that release and won't change with new updates.  The
directory structure maintains the version history:

https://downloads.apache.org/maven/maven-3/

<Also I wonder if it would make sense to stop the build once all the
required software has been installed, rather than continuing to build the
code.>

That's the approach Gary took for the last release, and it's an open
question that I've posed to the community via another thread.  My
inclination is to do both.  Have one dockerfile that builds the
environment, and another that builds the artifact.

<This would make it easier to re-use the container with an updated crypto
source; at present the source is built-in.>

Actually the source is copied in from the host.  See "COPY .
/commons-crypto".

<If the host was macOS, I assume that could then be used to build the Mac
object and generate the release.>

Agreed.  The Mac is the only build that can't be cross-compiled.  I think
it was Matt who noted on another thread that AWS offers MacVMs, which I
think is a promising route.

Thanks again for taking the time to provide feedback.

Alex


On Thu, Jun 16, 2022 at 2:48 PM sebb <seb...@gmail.com> wrote:

> On Thu, 16 Jun 2022 at 18:21, Alex Remily <alex.rem...@gmail.com> wrote:
> >
> > Forwarding to the community dev list. Didn't realize it was dropped along
> > the way.
> >
> > Alex
> >
> > ---------- Forwarded message ---------
> > From: Alex Remily <alex.rem...@gmail.com>
> > Date: Thu, Jun 16, 2022 at 1:01 PM
> > Subject: Re: [Crypto] What is it ?
> > To: Jochen Wiedmann <jochen.wiedm...@gmail.com>
> >
> >
> > Jochen,
> >
> > Please give my attempt at a docker build a try.  Copy the dockerfile and
> > the makefile.common file from the project directory at the link below
> into
> > your own project directory and try doing a "docker build . -t
> yourtagname"
> > from the project directory. The makefile.common is required because there
> > was a minor syntax error in the build args for the linux-arm build ("/"
> > omitted after JAVA_HOME) that caused the directory to resolve
> improperly).
> > Alternatively, you may be able to check out my fork and build it
> directly;
> > I'm not sure what the repo permissions allow.
> >
> > https://github.com/aremily/commons-crypto
> >
> > The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04
> and
> > cross compiles the remaining builds.  Note that I've omitted the Win32
> > build because I don't think anyone in the world uses 32 bit Windows
> > anymore, and the script itself can't do the Mac build (perhaps it's
> > possible to cross-compile for the Mac, but I lack the motivation to find
> > out at this point).  The workaround to perform a build that includes the
> > Mac is to perform Maven build on a Mac and then run the docker build.
> > Docker will copy the output of the Mac build into the container and
> bundle
> > it into the final artifact.
> >
> > Please provide feedback.  If it works, I'll update the build
> documentation
> > and submit a PR to close out CRYPTO-120
> > <https://issues.apache.org/jira/browse/CRYPTO-120>.
> >
>
> It works for me using Docker on macOS, though the output is in the
> container and it's not obvious how to extract it.
>
> I think it would be advisable to install Maven as a separate run step;
> if a new version is released (e.g. 3.6.4) the link will break.
> Ideally install the changeable items as separate steps, with the most
> volatile last to avoid rebuilds.
>
> Also I wonder if it would make sense to stop the build once all the
> required software has been installed, rather than continuing to build
> the code.
>
> This would make it easier to re-use the container with an updated
> crypto source; at present the source is built-in.
> This would require mapping the host source tree to the container; it
> would have the advantage that the output would end up on the host.
>
> If the host was macOS, I assume that could then be used to build the
> Mac object and generate the release.
> It's going to be easier to upload the release from the host rather
> than the container.
>
> > Alex
> >
> > On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > Hi, Alex,
> > >
> > > ideally, I would like to have a variant of the current Dockerfile,
> > > that builds a jar file with all the binaries included. If we would
> > > have that, then we could use it to build a release.
> > >
> > > Thanks,
> > >
> > > Jochen
> > >
> > > On Tue, Jun 14, 2022 at 11:22 PM Alex Remily <alex.rem...@gmail.com>
> > > wrote:
> > > >
> > > > Sure.  Happy to help.  I'll try to get to it this week.  I haven't
> been
> > > in the code for more than a year, so please be patient as I come back
> up to
> > > speed.  What exactly do you need help with?  Building the jar via the
> > > docker file?
> > > >
> > > > Alex
> > > >
> > > > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> > > jochen.wiedm...@gmail.com> wrote:
> > > >>
> > > >> Hi, Alex,
> > > >>
> > > >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily <alex.rem...@gmail.com>
> > > wrote:
> > > >> > appropriately.  There is a Docker file currently in the
> repository,
> > > used
> > > >> > for the 1.1 release, that manages the cross-compilation for the
> JNI
> > > >> > libraries and packages them into the commons-crypto jar.
> > > >>
> > > >> Would you be able, and ready, to help me with that?
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Jochen
> > >
> > >
> > >
> > > --
> > > Philosophy is useless, theology is worse. (Industrial Disease, Dire
> > > Straits)
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to