> But again -- why pollute the build file with stuff > that could be just a set of plain-text files
All depends on how you define “simplest" ;). One definition is how few different systems I have to use. Another is how can I get this information in the least complicated way I don’t have a lot of skin in this game, AFAIC let’s just pick one way and go about it. What do people think? 1> have the bits in Gradle that print the different help files as now. 1a> in this case, add a plain-text file at the root directing people who like editors to help/help-text…. 2> have a simple Gradle help task that tells people to look in help/help-text for the plain text versions. I like 1 best on the principle that it’s one less place people need to know about to look. BTW, part of the output of "gradlew tasks” Help (Build Documentation) tasks -------------------------------- helpAnt - Ant equivalences in the Gradle build. helpBuild - Information on using Docker to test that your build changes are not too disruptive. helpDeps - How dependencies are managed and what you need to know to change them. helpTest - How to run Lucene and Solr tests and the options that are available to you. which is actually kind of nice. Let me know. > On Nov 15, 2019, at 10:36 AM, Dawid Weiss <[email protected]> wrote: > >> Instead of a help.txt file though, how about some help task? ./gradlew >> helpAnt? > > I don't think that's easier, to be honest. You need to know which task > to invoke (and how). > A plain file is just right there in your face. > >> it works just fine. Does this seem consistent with the structure of the >> Gradle build? > > There is no one "structure" to a gradle build. There are some > conventions but they're much more relaxed compared to Maven (or even > ant). A gradle build is really just an arrangement of code blobs... > how you write it is up to you. > > "../solr_gradle_8/help/build.gradle” to have a “help” prefix. > helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks > aren’t case-sensitive). > > I personally don't like the fact you need to run gradle to display a > text file... Mark added it at the beginning but I don't think it's > really necessary. If you've done it already, so be it. > >> Here’s the diff, FYI. If this looks like it doesn’t do violence to the >> structure of the gradle build I’ll check it in. > > It's fine I think. But again -- why pollute the build file with stuff > that could be just a set of plain-text files (which people can display > with anything they like)? Occam's razor -- the simplest method is > typically the best. > > 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]
