Skip to content
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

Fixes #960 Property placeholders are not interpolated when they are only thing in XML #964

Merged
merged 1 commit into from
Apr 3, 2018

Conversation

rohanKanojia
Copy link
Member

@rohanKanojia rohanKanojia commented Mar 6, 2018

Fixes #960

Somehow these ${...} parameters are not being picked up by maven
properly when used solely without any suffix string literal, the maven
parameter string comes off as NULL. So adding a workaround for this.
We'll use +${...} as a parameter which would be handled by dmp afterwards

@rohanKanojia rohanKanojia requested a review from rhuss March 6, 2018 14:11
@codecov
Copy link

codecov bot commented Mar 6, 2018

Codecov Report

Merging #964 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #964      +/-   ##
============================================
+ Coverage     51.65%   51.67%   +0.01%     
- Complexity     1350     1351       +1     
============================================
  Files           147      147              
  Lines          7445     7447       +2     
  Branches       1121     1122       +1     
============================================
+ Hits           3846     3848       +2     
  Misses         3232     3232              
  Partials        367      367
Impacted Files Coverage Δ Complexity Δ
...ic8/maven/docker/access/ContainerCreateConfig.java 77.21% <100%> (+0.59%) 26 <0> (+1) ⬆️

@rhuss
Copy link
Collaborator

rhuss commented Mar 12, 2018

@rohanKanojia thanks for picking that up ! Gimme a bit, just on my way to a conference, so hope to review it soonish.

Copy link
Collaborator

@rhuss rhuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good !

Howver, I would harden the detection of the + a bit and move the docs to the place where the implicit variables are explained. See comments inline.

When creating a container one or more environment variables can be set via configuration with the `env` parameter
When creating a container one or more environment variables can be set via configuration with the `env` parameter. Somehow maven is showing weird behavior in case of interpolating single ${..} parameter; so we have provided a workaround for that. An `env` can take the following forms:

.Env format
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for caring about the documentation, too ;-)

However I would describe it a bit shorter. Maybe just:

If the only value of the env parameter is a docker-maven-plugin internal property which has been set implicitely you have to prefix the property with a single + like in +${docker.container.test.ip}. This is necessary due to some Maven limitations which simply interpolates a lone, non defined property, to an empty string which can't then be replaced by this plugin after the initial interpolation phase.

Maybe we can list the affected properties here. Or we should put the whole documentation to the place, where the implicit properties are explained (i think this is even better)

@@ -57,6 +57,12 @@ public ContainerCreateConfig environment(String envPropsFile, Map<String, String
String value = entry.getValue();
if (value == null) {
value = "";
} else if(value.contains("+")) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wold prefer a startsWith("+$") here because otherwise its far too unspecific. (Think about values which can validly contain + characters)

Even better, use a regexp ^\+\$\{.*\}$. This would really only match our use case.

@@ -122,6 +123,7 @@ private String copyPropsToFile() throws IOException {
Map<String,String> envMap = new HashMap<>();
envMap.put("JAVA_OPTS", "-Xmx512m");
envMap.put("TEST_SERVICE", "LOGGING");
envMap.put("TEST_HTTP_ADDR", "+${docker.container.consul.ip}");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add also tests where the + sign is part of a value or when there is something in addition like in +${docker.container.consul.ip}additional_data (here, there should be no removal of the +)

}

@Test
public void testSerialization() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this test about ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I thought I should add a test to check whether these RunImageConfiguration objects are properly serialized into objects or not. If this doesn't look like a sane to you, I would remove it.

Also, Can there be other tests related to this class?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, don't know exactly where this class should be serialized.

Adding tests are very valuable, but:

  • they add maintenance costs, which is ok if the test has some value and tests the right thing. E.g they need to be updated if ImageConfiguration changes
  • should not test trivial things which is out of scope of the project. E.g. testing Java serialization (which is the task of the JVM) is not in scope of this project. The same btw for testing setter and getter.

So, testing simple, dump configuration classes does not make sense normally, except when it add some extra logic.

What should be tested for sure are classes which use these configuration.

E.g. the latest PR about allowing to merge property based configuration with XML based configuration introduces some kind of logic to the configuration classes which could (and probably should) be tested. However, the plan is to move these classes to a Optional to handle the situation better to distinguish between default values and values set by the user when it comes to mergign (where default values should be ignored).

tl;dr - yes, please remove this test ;-) (but thanks for caring about testing, not every contribution does this)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for my naive mistakes. I'll update it

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @rohanKanojia no need to apologize ! it's awesome that you picked up the story and did the implementation. Highly appreciated !

…hey are only thing in XML

Somehow these ${...} parameters are not being picked up by maven
properly when used solely without any suffix string literal, the maven
parameter string comes off as NULL. So adding a workaround for this.
We'll use +${...} as a parameter which would be handled by dmp afterwards
Copy link
Collaborator

@rhuss rhuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks !

@rhuss rhuss merged commit 4c0fbcd into fabric8io:master Apr 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Property placeholders are not interpolated when they are the only thing in the XML element value
2 participants