[
https://issues.apache.org/jira/browse/SOLR-14824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197570#comment-17197570
]
Uwe Schindler edited comment on SOLR-14824 at 9/17/20, 9:46 AM:
----------------------------------------------------------------
Hi Hoss,
bq. Hmmm.... i don't really feel comfortable trying to tackle those changes
here/now – let's pursue this idea more in SOLR-14870 – because AFAICT those
productDir/buildDir variables return absolute file paths
For this issue I was mainly looking at the {{solrRootPath}} property that's
obviously not a relative URL path, which highly depends on structure of build
system (what happens if the CWD is different when executing the scripts in
later Gradle versions?). The series of ".." makes it completely unclear how it
is used. For the URLs to javadocs folders, I agree that's more the SOLR-14870
issue.
bq. but i'm assuming we could relativize those paths again the ref-guides own
buildDir
of course, instead of calling toUri(), you can do {{Path#relativize()}}, using
the own projects buildDir / output dir in combination with the code shown
above. As you need this as URI path later, don't forget to convert
operating-system specific slashes to forward slashes. See example here:
https://github.com/apache/lucene-solr/blob/master/gradle/documentation/render-javadoc.gradle#L500
{{def relative = pathFrom.relativize(pathTo).toString().replace(File.separator,
'/')}}
Also make sure that both directories EXIST before calling relativize, otherwise
the result is undefined (operating system dependent). So before calculating
relative path make sure to call mkdir.
Uwe
was (Author: thetaphi):
Hi Hoss,
bq. Hmmm.... i don't really feel comfortable trying to tackle those changes
here/now – let's pursue this idea more in SOLR-14870 – because AFAICT those
productDir/buildDir variables return absolute file paths
For this issue I was mainly looking at the {{solrRootPath}} property that's
obviously not a relative URL path, which highly depends on structure of build
system (what happens if the CWD is different when executing the scripts in
later Gradle versions?). The series of ".." makes it completely unclear how it
is used. For the URLs to javadocs folders, I agree that's more the SOLR-14870
issue.
bq. but i'm assuming we could relativize those paths again the ref-guides own
buildDir
of course, instead of calling toUri(), you can do {{Path#relativize()}}, using
the own projects buildDir / output dir in combination with the code shown
above. As you need this as URI path later, don't forget to convert
operating-system specific slashes to forward slashes. See example here:
https://github.com/apache/lucene-solr/blob/master/gradle/documentation/render-javadoc.gradle#L500
{{def relative = pathFrom.relativize(pathTo).toString().replace(File.separator,
'/')}}
Uwe
> Simplify set of Ref Guide build parameters
> ------------------------------------------
>
> Key: SOLR-14824
> URL: https://issues.apache.org/jira/browse/SOLR-14824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
> Reporter: Cassandra Targett
> Assignee: Chris M. Hostetter
> Priority: Minor
> Attachments: SOLR-14824.patch, SOLR-14824.patch
>
>
> While trying to solve LUCENE-9495, I thought it might be a good idea to try
> to simplify the set of variables and properties used during the Ref Guide
> build.
> There are 3 areas to work on:
> 1. Remove the "barebones-html" build. With Gradle the build is self-contained
> and {{gradlew check}} and {{gradle precommit}} could just build the full docs
> and check them.
> 2. Remove some properties that only existed for a hypothetical need related
> to the now-removed PDF.
> 3. Change remaining properties to be defined directly in build.gradle instead
> of relying on ant properties functionality.
--
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
