[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208556#comment-17208556
]
Dawid Weiss commented on SOLR-14870:
------------------------------------
> The main thing that bogged me down is that the lifecycle of gradle "tasks"
> really doesn't seem to make much sense, and there isn't a "clean" guide to
> how to refactor a "task" (instance) into a re-usable "class" that many tasks
> can be instances of.
It does make sense, it's just different from what you're used to. It's a bit
like functional programming vs. imperative programming. You can't just "port"
one into another.
> I tried to start by refactoring 'prepareSources' into a "class PrepareSources
> extends Sync"
Those tasks are not really meant to be subclassed. They should be composed but
the composition is typically based on task dependencies rather than in-code
explicit calls. I suspect in this case your "PrepareSources" task is merely
configuring the Sync spec - you don't need a specific class, only a task name
and configuration of the existing Sync task. Easier explained on a concrete
example than in theory but this is my guess.
> is there really no better way to get the 'main' classpath from the Project
> then the '...getPlugin(JavaPluginConvention.class)...' hoops i jumped through?
In general there is no "main" classpath - there are source sets, configurations
and a combination of these two. Java plugin creates two "convention" source
sets - one for main classes and one for tests but you could have a different
setup (and naming).
bq. if this is all expected
Yes, I think this is expected. This change reflects module names. Simpler =
better?
I can take a look at the patch later, unless Uwe beats me to it.
> 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
