What command did you use? Are you sure you're running the "wrapper"
script (gradlew) and not just any gradle version installed on the
system?

I ask because I just ran this and everything is fine:
./gradlew -p solr/solr-ref-guide buildSite

The exception you're getting indicates a missing dependency but this
dependency is present in versions.props on that branch:

org.asciidoctor:asciidoctorj=1.6.0-alpha.5

Dawid

On Tue, Nov 12, 2019 at 9:26 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]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to