Added docker build and quick-start

[mgaffigan]

While this might be somewhat responsive to #40, it is primarily just to provide a quick-start way for a developer to build and test. While trying to address Issue 5 I had hours of challenges getting things building happily - and shifted to docker as an escape hatch.

I do not expect this PR is ready to merge as is, but wanted to get something posted publicly. Known issues include:

• Not responsive to the acceptance criteria listed in Create OIE Docker Image #40
• Uses a personal container registry namespace, rather than https://hub.docker.com/u/openintegrationengine
• I'm not confident that I've implemented vmoptions handling correctly
• Missing examples for docker-compose and playwithdocker

That said, it does work to the point of passing tests, running server, client, and simple message processing.

I'm new to the project, so if I've missed a step please let me know.

[tonygermano]

I updated #40 with how I think the "official" docker container should be implemented. However, I really like the idea of what is presented here to use docker as a developer tool for building and testing.

I've also responded to some of your questions here #2 (comment)

[mgaffigan]

@tonygermano, I'm no longer aware of issues outside of the registry name (presumably someone owns the official URL?).

Differences I'm aware of relative to the original repo:

1. Uses multi-stage build to allow forks and keep dev, test, and prod on the same build pipeline and artifacts
2. Still unclear on jar signing story
3. Omitted tests since they do not seem to run even in the original repo on any modern version of python and need to be reworked. I'm sure there is some version of python, dependencies, and docker that it works - but I've not found it.
4. Publish file is only pushing Temurin JDK on Ubuntu as ${tag}-jdk, and Temurin JRE on Alpine as ${tag} (e.g.: latest-jdk, latest-jre)

Happy to discuss as needed. Every compose file, kubernetes deployment, etc... that I've tested doesn't notice the difference between this and stock.

[tonygermano]

@mgaffigan I pulled your launcher script out of this PR, made significant changes, and put it in its own PR in #119 . I think it is useful outside of a docker context, and it can still be used with docker. Would you mind reviewing it and giving any feedback?

[mgaffigan]

@tonygermano, Excellent! I'd love to see that merged and agree it is useful outside of docker.

[jonbartels]

I think this overlaps with #126 but does not entirely conflict.

This PR creates a builder image and does a good job with doco and pulling in examples. #126 is a release/runtime image. They serve different purposes.

[mgaffigan]

@jonbartels,

Thanks for the review. I think this PR got out of date and looks like it ended up with an accidental merge from #114 at some point. Let me clean it up to minimums. I'll pull the docker-compose examples out as well, assuming they fit better with #126.

[mgaffigan]

I've updated the PR to depend upon #119 for oieserver.sh and match the conventions of #126 assuming that has more community input.

Currently blocked by merge of: #119 and #126

Process used for testing:

1. Check-out this branch
2. Merge Add oieserver launcher script #119, #40 Add initial Dockerfile #126
3. Edit docker/entrypoint.sh to remove cp oieserver_base.vmoptions oieserver.vmoptions
4. docker build -t oie-dev .
5. docker run --rm -p 8443:8443 oie-dev

[kpalang]

I've updated the PR to depend upon #119 for oieserver.sh and match the conventions of #126 assuming that has more community input.

Currently blocked by merge of: #119 and #126

Process used for testing:

1. Check-out this branch

2. Merge [Add oieserver launcher script #119](https://github.com/OpenIntegrationEngine/engine/pull/119), [#40 Add initial Dockerfile #126](https://github.com/OpenIntegrationEngine/engine/pull/126)

3. Edit `docker/entrypoint.sh` to remove `cp oieserver_base.vmoptions oieserver.vmoptions`

4. `docker build -t oie-dev .`

5. `docker run --rm -p 8443:8443 oie-dev`

Don't link to #126, it is still a draft and not ready for review.

[jonbartels]

IIRC SDKMan isn't supported on windows. Do you need separate *nix, mac, and winderz instructions?

[mgaffigan]

I think *nix and mac can go as is, but windows should be clarified, yes. This also needs to be updated for the new Java 17 minimum build.

[mgaffigan]

Updated language to address windows.

[jonbartels]

Why not latest - this is now 2 months out of date

[mgaffigan]

ubuntu:noble-20251013 is current ubuntu LTS release. Specifying a specific tag is considered best practice for reproducible builds (though admittedly that would be a hash, not a tag, when taken to heart). Dependabot can submit PR's automatically to track latest, which keeps approval in the hands of the project.

I am unopposed to latest if preferred.