[jira] [Updated] (SOLR-14889) improve templated variable escaping in ref-guide _config.yml

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org