[
https://issues.apache.org/jira/browse/SOLR-14889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201368#comment-17201368
]
Uwe Schindler commented on SOLR-14889:
--------------------------------------
Hi [~dweiss], hi [~hossman],
I updated the patch, here's my new one: [^SOLR-14889.patch]
I removed the prepareLazyProps task and moved the stuff into doFirst. This has
several goodies:
- It's an antipattern to modify global properties during a task execution,
because depending on order of tasks (or parallelism) this may lead to strange
results. Because of this the doFirst clones the input map and then starts to
add stuff
- Uptodate now works as expected, because the properties as input don't
suddenly change. To me the task was suddenly reexceuted, although running it
several times. Now this is solved. prepareSources only runs if input files
change (sync task), or the modifiable templateProps input changes. It is also
reexcuted, if the configuration changes, so I also added "dependsOn
configurations.depVer"
- The properties are printed out
- After printing them out they are assigned to a FINAL local variable, which is
passed to expand. It's declared final to make sure the map reference stays the
same.
[~hossman]: you can now change the nocommits back to their original state,
looks like it works as expected. I am happy with it now.
> improve templated variable escaping in ref-guide _config.yml
> ------------------------------------------------------------
>
> Key: SOLR-14889
> URL: https://issues.apache.org/jira/browse/SOLR-14889
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-14889.patch, SOLR-14889.patch, SOLR-14889.patch,
> SOLR-14889.patch
>
>
> SOLR-14824 ran into windows failures when we switching from using a hardcoded
> "relative" path to the solrRootPath to using groovy/project variables to get
> the path. the reason for the failures was that the path us used as a
> variable tempted into {{_config.yml.template}} to build the {{_config.yml}}
> file, but on windows the path seperater of '\' was being parsed by
> jekyll/YAML as a string escape character.
> (This wasn't a problem we ran into before, even on windows, prior to the
> SOLR-14824 changes, because the hardcoded relative path only used '/'
> delimiters, which (j)ruby was happy to work with, even on windows.
> As Uwe pointed out when hotfixing this...
> {quote}Problem was that backslashes are used to escape strings, but windows
> paths also have those. Fix was to add StringEscapeUtils, but I don't like
> this too much. Maybe we find a better solution to make special characters in
> those properties escaped correctly when used in strings inside templates.
> {quote}
> ...the current fix of using {{StringEscapeUtils.escapeJava}} - only for this
> one variable -- doesn't really protect other variables that might have
> special charactes in them down the road, and while "escapeJava" work ok for
> the "\" issue, it isn't neccessarily consistent with all YAML escapse, which
> could lead to even weird bugs/cofusion down the road.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
