[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209320#comment-17209320
]
Dawid Weiss commented on SOLR-14870:
------------------------------------
The "configure" method changes the scope for the closure so that properties get
resolved against the objects you're passing to configure, nothing special there
(I believe).
My question was more about the fact that I think it is too complex right now
but I can't point out exactly how to make it simpler without actually writing
it myself... :) If you can make it work then please go ahead and I can follow
up with a functionality-preserving cleanup later on.
To answer your TODO about the "convention" to get sourceset classpath - I don't
know if there is a simpler way. I rarely venture into writing Java classes for
gradle builds. The benefit of doing this is precompilation (if you move it to
buildSrc) or external plugin (again - precompilation) but I never had a real
need of doing either. These things do make sense in the long run, once the
build stabilizes, but until then working with scripts is (in my opinion) much
faster and flexible. I admit I also like the build structure based on
aspects-splits rather than throwing everything into a single plugin or
buildSrc.
> 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
