users should be able to override "sources" elements

[rcernich]

For example if a user wants to use a one-off build, etc. for a specific source element.

This might be accomplished by using an external file to describe the sources.

Also, given the tight integration between the file names in the sources and the scripts which manipulate them, it might be a good idea to use variables to specify the file names in the scripts, which would probably also entail adding a fileName field to the source element.

For example:
source.name=KUBE_PING
source.fileName=openshift-ping-kube-1.0.0.Beta9-redhat-1.jar
source.url=
source.hash=

The downloaded file would be saved as openshift-ping-kube-1.0.0.Beta9-redhat-1.jar and referenced by ${KUBE_PING}.

[jmtd]

I've been thinking about this over Easter. I think part of the issue is that we currently have the definition of what sources are required (via hash:) and a method of obtaining them (via url:) coupled together. We should probably try to separate that out: the image definition should specify what sources are required (and enable their verification via checksums), but should not dictate how those sources are obtained, so a user can either obtain and supply the files out of band, or provide/use alternative methods of obtaining a given source, etc.

[jmtd]

We have an (undocumented) setting DOGEN_SOURCES_CACHE which, if defined in the environment, dogen looks in for sources files instead of using the supplied url: key. It appears DOGEN_SOURCES_CACHE can be a path, or a URI.

[goldmann]

Just small update. With changes to CCT we are doing - sources will be externalized from image.yaml and instead it'll be part of the scripts module which requires this specific file. We have a handle element there which specifies the nickname for a given file so you don't need to update the code after using a new version of file. Example of this: https://github.com/containers-tools/standalone-eap/blob/1f5ded73a3a040ceca9393c3d40d994e92ed40ae/sources.yaml

[rcernich]

It would be great if we could simply override anything in an image.yaml or module.yaml using some sort of properties/ini scheme. With ini, I could see having the sections match module names, then individual properties within would override whatever's currently in the yaml. Also, having the ability to use system properties would be beneficial as well for things like build no, version, etc. (basically, similar to what you'd use with any other build system to identify build specific details).