[ https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209268#comment-17209268 ]
Chris M. Hostetter commented on SOLR-14870: ------------------------------------------- {quote}I took a peek. Is there any particular reason why you wanted to make this PrepareSources a java task and not just use DSL, Chris? {quote} Well, "class PrepareSources" initially started it's life as "class PrepareSources extends Sync", based on some advice i found on the gradle forums from gradle-devs to other users on how to refactor tasks to make them re-usable/extensible -- but that was before i'd found other examples of dynamically creating tasks in things like loops. thinking about what I wound up in, you're probably right – i can't think of any particular reason why the class couldn't/shouldn't just be defined using the DSL as common actions in the existing loop i have to create the two "prepare" tasks ... but that's w/o even really understanding yet how the "configure" method you mentioned works ... ....I'll look into it when i get a chance. (allthough ... if/when Uwe confirms that my understanding of the new javadoc structure is correct, i may more forward with what's in the patch just so we can get the validation working properly -- since the links are clearly broken right now on master – and worry about changing it to be more gradle-esque later) > 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