[
https://issues.apache.org/jira/browse/SOLR-14889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201659#comment-17201659
]
Chris M. Hostetter commented on SOLR-14889:
-------------------------------------------
thanks guys ... this is very enlightening.
{quote}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.
{quote}
doFirst/doLast are actually the most straight foward aspect of the gradle
lifecycle as far as i can tell : ) ... what's blowing my mind is what Uwe
pointed out, about how during "configuration" the task execution code evidently
... "captures" (for lack of a better word) ... references to the
variables/input used that code, so that _re-assigning_ to those variables in
doFirst had no effect, but modifying the objects those variables pointed to did.
...that's wild...
... and really nothing i'd seen in any of the gradle tutotrials/lifecycle
discussion really prepared me for that.
----
I have a few lingering questions, mostly about some of the ancillary stuff, in
the latest patch (i didn't dig into who changed what) ...
* can we make `templateProps` final now? ... i didn't realize groovy supported
final as a keyword, and seems like a good idea for as many things as possible
to be final
** should we use `asImmutable()` which is apparently a groovy add-on for on
maps/collections?
* The "TODO 2" comment is stale and makes sense to remove, but shouldn't the
"TODO 1" and "TODO 3" comments stick around? ... those are still applicable
aren't they?
* why is buildSiteJekyll now hooked into the "assemble" task?
** my understanding is that "assemble" is for building the lucene/solr
artifacts/distribution – but the ref-guide shouldn't be included in that, we
don't "release" it officially
** even if it does make sense to hook into "assemble" why is it hooking
directly to buildSiteJekyll and not buildSite ?
*** if that was to avoid the "check" style validation `buildSite` does ok, but
as discussed in SOLR-14870 the way forward there seemed to be to pull it out of
buildSite into it's own "checkSite" task .. "buildSite" is the main task people
should know about/run ... buildSiteJekyll (as a task name) is an implementation
detail that should really go away
> 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-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
