[
https://issues.apache.org/jira/browse/SOLR-14889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14889:
--------------------------------------
Attachment: SOLR-14889.patch
Status: Open (was: Open)
I thought this would be straight forward, but there's clearly still a lot about
the gradle lifecycle / order-of-evaluation that i don't udnerstand....
The key change in the attached patch that this whole idea hinges on is..
{noformat}
- expand(templateProps)
+ expand( templateProps.collectEntries({ k, v -> [k,
v.replaceAll("'","''")]}) )
{noformat}
But for reasons i don't understand, this seems to bypass the changes made to
{{templateProps}} in ' {{setupLazyProps.doFirst}} ', where the ivy version
values are added...
{noformat}
Execution failed for task ':solr:solr-ref-guide:prepareSources'.
> Could not copy file
> '/home/hossman/lucene/dev/solr/solr-ref-guide/src/_config.yml.template' to
> '/home/hossman/lucene/dev/solr/solr-ref-guide/build/content/_config.yml'.
> Missing property (ivyCommonsCodec) for Groovy template expansion. Defined
keys [javadocLink, solrGuideDraftStatus, solrRootPath, solrDocsVersion,
solrGuideVersionPath, htmlSolrJavadocs, htmlLuceneJavadocs, buildDate,
buildYear, out].
{noformat}
(I'm also not clear where that 'out' key is coming from, but i have no idea if
that pre-dates this change)
I experimented with adding a {{doFirst}} block to {{prepareSources}} that would
copy the (escaped) templateProps into a newly defined Map in that task, that
would be used in the {{expand(...)}} call – but that still seemed to result in
the {{expand(..)}} being evaluated before the {{doFirst}} modified the map (see
big commented out nocommit block in the patch for what i mean)
[~uschindler] / [~dweiss] - can you help me understand what's going on here and
how to do this "the right way" ?
> 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-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
