-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
maven directory changes #73
Comments
with the switch to maven we need to first decide if maintaining a separate repo for the docker containers still makes sense. I m leaning towards integrating the docker operations with the build process in the main repo via a maven plugin. Move …
In both cases, I would want to stick with Modifying conf files could happen via standard maven variable substitution which would reduce the number of layers for our images, but is something we need to prepare. This involves sunsetting this repo, changing the configuration of our build pipeline on dockerhub, and modifying files in the main repo. pros:
cons:
Don't move …
We should also monitor the image size, i see that our images are consistently increasing in size, and i don't see a good reason for why they should. If one of the two approaches leads to substantially smaller images, that one takes the cake for me. Lastly, both the docker build commands, and the dockerhub code have undergone major updates recently, I m still adopting to the fallout of that, there are likely unforeseen bumps ahead. |
Well you can either not add the We already use a profile for code-signing the DMG on a Mac. That profile is only enabled when both the OS is a Mac, and the user has set the property |
I am for moving to main repo and the docker image being a release artifact of the maven build process.
Whatever we do, a rewrite of the Dockerfile is required.
I don't think, we should have any focus on this. If people want to create their own eXist image then our image should be the preferred |
ok so move with plugin it is for now. I m currently working on two branches to set this up (one with fabric8 plugin one with spotify). I should have something ready for testing tonight, but here is my current list of criteria: functionally use as base image is crucial, this involves:
the biggest changes so far:
|
As I understand it these jvm and java tool options are for adjusting for differing server environments re. |
not quite the server environment doesn't matter, they are for making sure that the internal JVM memory mechanism and the external container memory mechanism don't get into conflicts, how a server allocates memory to the container daemon is yet another level on top of that. with java11 the JVM should automatically discover when it is running inside a container environment, and apply the righ settings, but with java8 we need to configure these via JVM_OPTS. Setting at docker run time only works if the image makes the appropriate provisions |
here is what i have so far with farbic8io |
New maven based layout for exist-db,
will require an update of the copy operations
and perhaps the sym linking of the config files,
in the Dockerfile.
I have opened this issue to check list and discuss what is required
The text was updated successfully, but these errors were encountered: