I just pushed a new branch for the Ref Guide based off the gradle_7 branch (it’s "jira/SOLR-13452_gradle_7_refguide”). I’m completely stuck and try as I might I can't get myself unstuck with the time I have.
There are several phases to our current build, and some of these we can drop if we drop the PDF build. Just to summarize: 1) All files in solr/solr-ref-guide/src are copied to solr/build/solr-ref-guide. The _config.yml.template (used by Jekyll) is populated (I think) and copied to plain _config.yml for Jekyll to use. 2) The page hierarchy is built for the left nav and for the previous-next links at the bottom of each page. The file list for the PDF is created. The bare-bones-html is created to check all the links (unique section ids, javadoc links). 3) Jekyll creates the HTML pages and asciidoctor-ant creates the PDF. I might be missing some nuances there, but that’s the gist. I’ve barely been able to recreate this in the branch I created. I’ve added a task for Jekyll to the build.gradle and am able to get it to download the gems (unlike today when you have to download them in advance), but the build still fails because it doesn't have all the usual steps of copying the dir and fixing the template, etc., but those steps are beyond what I know how to do. It also occurred to me that we could replace some of the Java classes with Groovy in the build.gradle itself, but again, I can’t do it. I’ve also replaced the asciidoctor-ant with asciidoctor-gradle-plugin, but I’m not sure how much that’s really getting us if we don’t do the PDF. Supposedly the latest versions of that plugin (2.3) allow better gem support, but I couldn’t get them to work so I reverted back to 1.6. Someone who knows Gradle better might have better luck. I’m more than happy to share more details our current build so we can replicate some of the above steps, but I’m stuck without a lot more basic Gradle skills that I don’t have time to acquire with day-job/personal life commitments. I put it into a separate branch so we could iterate a little easier, can anyone help? Cassandra On Sep 20, 2019, 2:59 PM -0500, Dawid Weiss <dawid.we...@gmail.com>, wrote: > I don't want to blow this discussion out of proportion so I'll try to > make it quick... > > > There is convention for this :) The convention is to commit your > > gradle.properties and that is what holds your project config. It's widely > > done and promoted by the Gradle team. > > I disagree with this statement and base my opinion on both my > experience and what's written in [1]. The gradle.properties file is > for configuring gradle (and the build's system properties), not for > configuring project properties and project-related behavior. Even the > API reflects this distinction (gradle environment vs. the Settings > object vs. eventual project properties and their inheritance). I'd > argue that the current setup abuses gradle properties for things that > could as well be defined elsewhere; ideally as normal project > properties (however loaded or declared) where they'd be nicely > propagated to subprojects. But it's cosmetics, fine. > > > The daemon is not controlled by us, it's controlled by you and what you put > > in your global file. > > Exactly. But the versioned gradle.properties has: > > org.gradle.daemon=false > > If I'd like to work with Lucene with daemon enabled, I'll have to > change this setting globally (in ~/.gradle.properties). This will > affect any other Gradle project I have on that machine, which isn't > too great. Sure, I can set up an environment variable override or even > a command alias but it's not the point -- it's either a global > override of this daemon setting or having a dirty checkout. And this > somehow doesn't feel right to me. > > > I would say this: their code to manage this is 1000 times more simple than > > the code to do it in randomized testing :) > > Well, I strive for perfection but am not hesitant to recognize > brighter minds (think JUnitBenchmark vs. JMH...). > > > For something like testFast (or whatever it's called), first it's super > > simple code, second, > > Hmm. Did you push these changes? Which branch is this testFast code > on? I committed a few cleanups to jira/SOLR-13452_gradle_7 -- don't > know if you saw them. > > > This is a big build, there is a lot going on. [... ] so I think it's best > > that we devote a JIRA to anything that people feel is important in order to > > focus an actionable discussion. > > I think it'd be easier to work collectively on that dedicated gradle > branch, cleaning up stuff and introducing small changes there, but if > you'd rather have Jira issues or PRs that's up to you -- I asked about > this but didn't receive a reply. > > Dawid > > [1] https://docs.gradle.org/current/userguide/build_environment.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
