Looking at the following file:
*solr/solr-ref-guide/build.gradle*
I see the apparently missing dependency:
* dependencies {*
* classpath "org.asciidoctor:asciidoctorj:1.6.0-alpha.5"*
* }*
I also see this TODO:
*// TODO 4: currently buildscript dependencies are hardcoded (asciidoctor)
because they can't be resolved*
*// using Palantir's plugin. This is another reason to switch to
gradle-based tools -- then*
*// only the build script dependencies would be needed and asciidoctorj
would be removed from version*
*// properties entirely (it is only used locally in this build file).*
I don't think we need to add this line, specially because I'm able to run
the buildSite target fine.
Can you provide more information w.r.t. how you ran this?
-Anshum
On Tue, Nov 12, 2019 at 12:30 PM Erick Erickson <[email protected]>
wrote:
> I just pulled down the new gradle_8 branch and got this error:
>
> * What went wrong:
> Execution failed for task ':solr:solr-ref-guide:compileToolsJava'.
> > Could not resolve all files for configuration
> ':solr:solr-ref-guide:tools'.
> > Could not find org.asciidoctor:asciidoctorj:.
> Required by:
> project :solr:solr-ref-guide
>
> I “fixed" it by adding the below to the versions.props file, but have no
> idea if that’s correct or not, it’s just the latest release of asciidoctorj
> I found on a quick google search.
>
> org.asciidoctor:asciidoctorj=2.1.0
>
> Is this OK?
>
> > On Nov 12, 2019, at 4:05 AM, Dawid Weiss <[email protected]> wrote:
> >
> >> There’s one current problem with it, which may be something in my env:
> in the grade_7_refguide branch the HTML files were generated in
> ./solr/solr-ref-guide/build, but now they are in the top-level ./build
> directory.
> >
> > I think Mark has configured gradle defaults to be specifically this way.
> >
> >> I generally don’t really care where it gets built, but there are a few
> places in the docs where we pull in source code and those now throw an
> error because the path to the files is wrong. If the Ref Guide is going to
> get built there forever, it’s a tiny & simple fix to change the path, I
> just need to know if that’s the plan or if it’s a mistake. This problem
> also does not need to hold up merging that branch to master.
> >
> > Ideally, Gradle tasks consume not explicit paths but configuration
> > artifacts or "outputs" of other tasks. This is elegant and
> > error-resilient. We can clean it up as we go -- feel free to create a
> > task in jira and assign it to me and I'll take a look.
> >
> > D.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Anshum Gupta
