[
https://issues.apache.org/jira/browse/SOLR-14889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201749#comment-17201749
]
Dawid Weiss commented on SOLR-14889:
------------------------------------
bq. 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.
I think what makes it more complex is that some of these "assignments" are
actually syntactic sugar for method calls with parameters. So you're calling a
method with a reference to a local variable - this method stores that reference
somewhere. When you assign a different object to that variable later nothing
really happens to the reference previously published. I don't think there's
much magic involved there, really - it's the syntactic sugar that makes some of
these calls not obvious. If we added brackets around method calls it'd be
probably clearer.
bq. but shouldn't the "TODO 1" and "TODO 3" comments stick around? ... those
are still applicable aren't they?
Yes, but it's probably better to file a jira issue than leave them as comments.
bq. why is buildSiteJekyll now hooked into the "assemble" task?
assemble is a base plugin's convention task for "assembling the outcomes" of a
project. It's not related to lucene/solr distribution - we can *use* whatever
is assembled in the packaging project, but we don't have to. When you see an
unknown gradle project you'd typically run 'gradlew assemble' to build stuff.
Much like 'mvn package' works. Maven analogy works with "check" too (mvn
validate).
Please change the task names according to your expertise - it seemed to me that
buildSite runs the assemble and validation (check) - It was an arbitrary choice
on my behalf to just hook it up this 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-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
