Some areas which could be improved on: - Building an image requires all gradle dependencies to be downloaded.
Since the docker image is built in isolation, it doesn't benefit from the gradle cache already populated on the developer's host. This causes lots of dependencies to be downloaded. A possible solution might involve a gradle task to export ofbiz's dependencies into a temporary directory so that they can be copied to and imported into the docker image's gradle cache. I'm not sure how to do this yet. - Builds require loading all data. Using something like docker in development will only be useful if building docker images is fast. Performing a full build and data load takes quite some time - further exacerbated by the downloading of dependencies described above. One solution might be to create a base docker image with the majority of dependencies downloaded, software built and data loaded. The developer would recreate this base image from time to time. Then a second image is built upon the first which brings in new changes relevant to the developer's current task. The usefulness of this approach will depend on the task at hand though. For example, if I want to exercise a PR: At some earlier point in time I have checked out the trunk branch and run './gradlew buildOfbizBaseDockerImage'. Then later I want to test out a PR I can run 'git fetch origin pull/1234/head:pr1234; git merge --no-commit pr1234; ./gradlew buildOfbizDockerImage'. The second image built will depend on the first so will benefit from the already populated gradle cache, the majority of the code already built and the demo data already loaded. We can improve on the tagging of the image by reading the branch name from the development environment using this in the tag name, allowing the developer to have various images built which address different PRs. On Sat, 21 Nov 2020 at 22:10, Daniel Watford <d...@foomoo.co.uk> wrote: > Hello, > > Following on from the various docker discussions I wanted to mention an > approach of building a docker image based on the current development > workspace using gradle. > > Please give it a try - danwatford/ofbiz-framework at docker-from-gradle > (github.com) > <https://github.com/danwatford/ofbiz-framework/tree/docker-from-gradle> > > I have run these steps on a Windows 10 PRO machine, running commands from > git-bash. > > To build the ofbiz image: > ./gradlew --no-daemon buildDockerImage > > This will create an image, tagged ofbiz:latest, based on the current > workspace with all demo data loaded. > > To run the image in a container: > docker run -it --rm --publish 8080:8080 --publish 8443:8443 ofbiz:latest > > Visit https://localhost:8443/partymgr > Username / Password: admin / ofbiz > > The above container will be deleted when the process is terminated. > > The approach of building the image from the current workspace might be > useful as a way of quickly testing out PR merges. > Further, by building from gradle we can change the content of the docker > image based on build properties or environment variables. For example > we could build multiple images with various database drivers already > included (where licensing permits). > > I wonder if the dev community sees any value in the gradle build approach > compared to manually creating Dockerfiles either directly in the > ofbiz-framework sources or held in another repository. > > Thanks, > > Dan. > > -- > Daniel Watford > -- Daniel Watford
