[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210254#comment-17210254
]
Chris M. Hostetter commented on SOLR-14870:
-------------------------------------------
{quote}...If you can make it work then please go ahead and I can follow up with
a functionality-preserving cleanup later on.
{quote}
Oh, oh ... i'm sorry if i wsan't clear before: it 100% works right now, it
works exactly like i hoped it would work. I'm _SUPER_ happy with the
functionality (i just wasn't sure If i was doing something horribly "bad") ...
* syncing the source files and building the data files is now a single task –
which is ideal in my opnion
** the jekyll build flat out can't work w/o the data files, so this way
there's no "partially usable" content directory
** the only reason they were distinct ant tasks in the past was because the
"bare bones" build didn't need them
* all of the input/output caching seems dialed in on the right things
** checking file contents, not just existence of directory, no unneccessary
"replace/delete this file on ever run, even if the 'source' hasn't changed,
etc...
** running any task twice back to back is a no-op the second time
* dependencies on top level documentation hooked into the "local javadoc" link
checking
* no deplication in the definitions of the "dual" tasks – no risk (i can see)
that someone can breaks the "html" site in a way that won't cause a failure
when checking the "local links" site
{quote}I rarely venture into writing Java classes for gradle builds. The
benefit of doing this is precompilation (if you move it to buildSrc)...
{quote}
Right ... that's interesting ... maybe that's why i was seeing docs suggesting
building java classes for re-usable logic in tasks that you want multiple
instances? ... with that possibility in mind i'm now less inclined to convert
this to DSL, and more interested in figuring out how to pre-compile it down the
road :)
----
At this point the main thing i need clarity on is less about gradle, and more
about how our javadoc "output" structure seems to have changed with the move to
gradle – and if that's intentional and expected (so i can fix the links in the
ref-guide to point to the new paths) or if it isn't expected and needs fixed
(so the existing links start working again)
/cc: [~uschindler] (see previous comment about ".../8_6_0/solr-core/..." vs
".../9_0_0/core/...")
> gradle build does not validate ref-guide -> javadoc links
> ---------------------------------------------------------
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any
> broken links between the ref guide and the javadocs...
> {code}
> <target name="documentation" description="Generate all documentation"
> depends="javadocs,changes-to-html,process-webpages">
> <ant dir="solr-ref-guide" target="bare-bones-html-validation"
> inheritall="false">
> <propertyset refid="uptodate.and.compiled.properties"/>
> <property name="local.javadocs" value="true" />
> </ant>
> </target>
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}}
> just did interanal validation of the strucure of the guide, but this hook
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first
> build the javadocs; then build the ref-guide; then validate _all_ links i
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage
> this functionality from the "solr" project doesn't seem to have been
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds
> a nonsense javadoc link to the ref-guide (or removes a class/method whose
> javadoc is already currently to from the ref guide)
--
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
