Minor refactoring to prepare for extra directory targets

[TadCordle]

Towards #1581. This shouldn't change any functionality, just making changes in plugins-common so I can make the configuration changes in maven/gradle separately.

[chanseokoh]

I think the return type may depend on how we will define the new configuration. I guess one way to translate this is

    extraDirectories {
      // not sure if you can use `/`, '\,', or `C:\` as a key name in a map.
      paths = [/path/to/extra/dir: '/target/dir'] // while maintaining backward-compatibility of string list
      permissions = [
        '/path/on/container/file1': 744,
        '/path/on/container/file2': 123
      ]
    }

Using a path as a map key probably won't work in Maven either. So I reckon you'll have it like

    extraDirectories {
      paths { // directory1
         src = ...
         target = ... 
      }
      paths { // directory2
         src = ...
         target = ... 
      }
    }

?

I think returning Map<Path, AbsoluteUnixPath> here will still work even if you define a nested structure for paths, but I wonder if it is better to define a nested class (such as RawConfiguration.ExtraDirectoriesConfiguration) if we are going to have a nested structure anyway.

[TadCordle]

Hmm, I guess that's true, this could probably be closer to how AuthProperty is setup. I guess the question I have is, is RawConfiguration actually meant to imply the layout of the maven/gradle configurations, or is it just meant to purely be a translation layer? I just felt a map was simpler; if we add a nested class in RawConfiguration, we still need to translate the maven/gradle-specific nested configuration classes into the plugins-common version, so it's the same amount of work plus one extra file. The only up-side I can immediately see is that RawConfiguration would more closely resemble the maven/gradle configuration. Is that what we want to stick with?

[TadCordle]

Using a map also forces people to avoid specifying 2 target directories for the same source directory. Is that something we want to support?

[chanseokoh]

I guess the question I have is, is RawConfiguration actually meant to imply the layout of the maven/gradle configurations, or is it just meant to purely be a translation layer?

From my point of view, RawConfiguration is a higher-level abstraction that doesn't necessarily have to follow the strict configuration layout. It can be independent, as long as it provides "raw config values" in a reasonable way. It's just that, because of the "raw" nature, I think in many cases it'll naturally resemble the configuration layout. The point is, we can choose whatever option that provides a better abstraction that makes sense. For example, returning a Map doesn't describe what the keys and the values mean; the caller should have advanced knowledge that the key is the source and the value is the target. In this sense, we could say returning a structured class has an advantage. But I am not so against using Map. This is up for discussions.

Using a map also forces people to avoid specifying 2 target directories for the same source directory. Is that something we want to support?

I don't think we want to support that, at least not at the moment. Anyways, I think we can enforce this constraint when using a structured class too.

[helloworlde]

@chanseokoh
Hi, when the next time release for this optimize, we need this param now, or does there have other solution to copy file to specific path?

[chanseokoh]

@helloworlde I can't say for sure about the next release date. Could be as early as next week but may be delayed further. But it'll certainly happen in this month.

Until then, you have to prepare a desired structure ahead before invoking Jib. There are various ways and setups to achieve this, for example, using the Maven Resources Plugin (the copy-resources goal) or the Copy Rename Maven Plugin. Some examples: here, and here.