-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Minor refactoring to prepare for extra directory targets #2436
Conversation
…1-extra-dir-target-refactor
@@ -157,8 +159,12 @@ public String getCreationTime() { | |||
} | |||
|
|||
@Override | |||
public List<Path> getExtraDirectories() { | |||
return jibExtension.getExtraDirectories().getPaths(); | |||
public Map<Path, AbsoluteUnixPath> getExtraDirectories() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a map also forces people to avoid specifying 2 target directories for the same source directory. Is that something we want to support?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@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 |
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.