[
https://issues.apache.org/jira/browse/SOLR-14889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201355#comment-17201355
]
Dawid Weiss commented on SOLR-14889:
------------------------------------
Hi Chris. Uwe explained the particular problem, I wanted to follow up with a
generic explanation.
The order of evaluation is I think the most tricky bit in gradle builds as it
involves syntactic sugar of groovy, hooks in gradle itself and the different
"stages" of gradle build itself. This is a good read:
https://docs.gradle.org/current/userguide/build_lifecycle.html
In short terms the three phases are: initialization - boostrap, reading the
setup properties, etc (we don't care much), evaluation - this is actually
execution too - all build scripts (groovy) are run against an empty build
graph; they add and configure tasks, prepare properties, declare dependencies
(but shouldn't resolve them yet), etc. This is when you "set up" the build. The
execution phase follows when gradle decides which tasks to actually execute
(based on user-provided task names, dependencies, configurations to resolve and
cache states). The "doFirst" and "doLast" clauses in tasks add an anonymous
closure to the list of things to run in execution phase. So even if a script
looks linear, the closure in doFirst and doLast runs at a completely different
time than what's outside of it.
The simplest way to see what gets executed and when is to add debug printlns...
It really helps sometimes.
> 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-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
