[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208864#comment-17208864
]
Dawid Weiss edited comment on SOLR-14870 at 10/6/20, 3:56 PM:
--------------------------------------------------------------
Perhaps I should clarify that if the intention was to pull out common
configuration and logic then it'd be more natural to define multiple tasks and
just run the same configuration closure over all these tasks (that handles
common setup). We do use it in a few places, like in
solr-forbidden-apis.gradle, for example:
{code}
configure(project(":solr:core")) {
tasks.matching { it.name == "forbiddenApisMain" || it.name ==
"forbiddenApisTest" }.all {
exclude "org/apache/solr/internal/**"
exclude "org/apache/hadoop/**"
}
}
{code}
this applies the same configuration to two tasks (selected by name). You could
just as well do something like:
{code}
configure([task1, task2]) {
// common setup.
}
{code}
and it'd work too.
was (Author: dweiss):
Perhaps I should clarify that if the intention was to pull out common
configuration and logic then it'd be more natural to define multiple tasks and
just run the same configuration closure over all these tasks (that handles
common setup). We do use it in a few places, like in
solr-forbidden-apis.gradle, for example:
{code}
configure(project(":solr:core")) {
tasks.matching { it.name == "forbiddenApisMain" || it.name ==
"forbiddenApisTest" }.all {
exclude "org/apache/solr/internal/**"
exclude "org/apache/hadoop/**"
}
}
{code}
this applies the same configuration to two tasks (selected by name). You could
just as well do something like:
configure([task1, task2]) {
// common setup.
}
and it'd work too.
> 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
