Re: gradle module/project structure
Thanks, I just put it in gradle tasks for now. on to the equivalent of “ant server dist”. > On Nov 15, 2019, at 1:03 PM, Dawid Weiss wrote: > > Doesn't make sense to spend much time on such discussions, Erick, not > at this early stage. If you like it -- leave it in, I have no problem > with it whatsoever. > > Dawid > > On Fri, Nov 15, 2019 at 6:02 PM Erick Erickson > wrote: >> >> Added SOLR-13935 for this general topic, please comment there if you’d >> rather. >> >>> On Nov 15, 2019, at 10:36 AM, Dawid Weiss 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: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Doesn't make sense to spend much time on such discussions, Erick, not at this early stage. If you like it -- leave it in, I have no problem with it whatsoever. Dawid On Fri, Nov 15, 2019 at 6:02 PM Erick Erickson wrote: > > Added SOLR-13935 for this general topic, please comment there if you’d rather. > > > On Nov 15, 2019, at 10:36 AM, Dawid Weiss 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: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Added SOLR-13935 for this general topic, please comment there if you’d rather. > On Nov 15, 2019, at 10:36 AM, Dawid Weiss 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: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
> 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 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: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
> 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Ohhh, I really like this, especially given the amount of time I’ve spent
looking at all of the possible tasks….
Instead of a help.txt file though, how about some help task? ./gradlew helpAnt?
But I need a sanity check here before pushing this (assuming y’all agree)
before I go changing some things:
“./gradlew tests” (note the plural) fails with:
java.io.FileNotFoundException:
/Users/Erick/apache/solrVersions/solr-gradle_8/buildSrc/common/help-text/testHelp.txt
(No such file or directory)
And, indeed, there is no such file. However, there is a file:
/Users/Erick/apache/solrVersions/solr-gradle_8/help/help-text/testHelp.txt
So if I change the file: ../solr_gradle_8/help/build.gradle (the “tests” task)
from:
println file("${rootDir}/buildSrc/common/help-text/testHelp.txt").text
to
println file("${rootDir}/help/help-text/testHelp.txt").text
it works just fine. Does this seem consistent with the structure of the Gradle
build? I don’t want to blunder about with things like this without checking
what others think until I get a better feel for how this all should work.
A couple of other things:
1> I detest a “test” and “tests” tasks having wildly different outcomes, so I
changed all the tasks in "../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).
2> I added a new file "../solr_gradle_8/help/help-text/antHelp.txt” to be the
printout of a new task “helpAnt” that has Dawid’s suggestions in it.
And there’s an empty file: .../solr-gradle_8/buildSrc/common/build-help.gradle.
It’s unclear to me what the intention is here, but from what I can see it’s a
stub for building
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.
diff --git a/help/build.gradle b/help/build.gradle
index 2918118ab93..5504cdf679e 100644
--- a/help/build.gradle
+++ b/help/build.gradle
@@ -22,15 +22,25 @@ sourceSets {
}
}
-task tests {
+task helpTest {
group = 'Help (Build Documentation)'
description = "How to run Lucene and Solr tests and the options that are
available to you."
doLast {
-println file("${rootDir}/buildSrc/common/help-text/testHelp.txt").text
+println file("${rootDir}/help/help-text/testHelp.txt").text
}
}
+task helpAnt {
+ group = 'Help (Build Documentation)'
+ description = "Ant equivalences in the Gradle build."
+
+ doLast {
+println file("${rootDir}/help/help-text/antHelp.txt").text
+ }
+}
+
+
task deps {
group = 'Help (Build Documentation)'
description = "How dependencies are managed and what you need to know to
change them."
@@ -39,7 +49,7 @@ task deps {
}
}
-task testBuild {
+task helpBuild {
group = 'Help (Build Documentation)'
description = "Information on using Docker to test that your build changes
are not too disruptive."
}
> On Nov 15, 2019, at 4:30 AM, Dawid Weiss wrote:
>
> ant compile => gradlew compileJava
> ant jar => gradlew package
> ant clean => gradlew clean
> ant clean-jars => [no replacement - JARs sourced directly from gradle caches]
> ant jar-checksums => gradlew jarChecksums
> ant test => gradlew test [or better (includes any other verification
> tasks): gradlew check]
> ant validate => gradlew check
> ant precommit => TODO
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
> Want to raise a JIRA (task?) and put it in the umbrella task? (SOLR-13914)? > I’m trying to keep all these kinds of TODO’s in a place we won’t forget them. I won't forget this -- it's too annoying. ;) We can't change the folder structure now because merges would be too painful (and if we want to keep parallel build systems in place we can't do it anyway). This really is of low priority. What we should have in place is a list of common ant tasks that people use and a corresponding list of gradle commands -- this would ease the transition and encourage people to try the gradle build. I'd create an in-your-face top-level file "help.txt" and have a concise list of these. It can also be prioritized so that we know what needs to be ported asap? I can think of: ant compile => gradlew compileJava ant jar => gradlew package ant clean => gradlew clean ant clean-jars => [no replacement - JARs sourced directly from gradle caches] ant jar-checksums => gradlew jarChecksums ant test => gradlew test [or better (includes any other verification tasks): gradlew check] ant validate => gradlew check ant precommit => TODO If there's anything people regularly use, I'd add it to the list above. Most tasks that are rarely (or never) used I would *not* port from ant. Things like "jar-src" or "jacoco"... They should be components of other higher-level tasks or even subprojects on their own (jacoco could be a "check" task on a submodule called "tests:coverage" for example). A prioritized list of common workflow is really necessary to know which things are needed first so that people can start to use it for work. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Want to raise a JIRA (task?) and put it in the umbrella task? (SOLR-13914)? I’m trying to keep all these kinds of TODO’s in a place we won’t forget them. Up to you… > On Nov 14, 2019, at 11:56 AM, Dawid Weiss wrote: > >> I didn't realize you could specify a folder name with -p ! I think >> that covers the use case I was describing. If the module names we have >> are helpful in an IDE, that's reason enough to keep them >> fully-qualified. > > I would opt to change them to reflect folder structure precisely (it's > simpler to reason about them then) but it'll have to wait until ant is > gone. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
> I didn't realize you could specify a folder name with -p ! I think > that covers the use case I was describing. If the module names we have > are helpful in an IDE, that's reason enough to keep them > fully-qualified. I would opt to change them to reflect folder structure precisely (it's simpler to reason about them then) but it'll have to wait until ant is gone. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
I didn't realize you could specify a folder name with -p ! I think that covers the use case I was describing. If the module names we have are helpful in an IDE, that's reason enough to keep them fully-qualified. On Thu, Nov 14, 2019 at 11:13 AM Dawid Weiss wrote: > > Perhaps. I don't use this wrapper. Knowing the difference and > understanding what you're expressing with both variants is all it > takes, really. > > D. > > On Thu, Nov 14, 2019 at 5:08 PM Jan Høydahl wrote: > > > > Isn’t this why Mark recommended using gdub (gw) so you can run from within > > sub folders? > > > > Jan Høydahl > > > > > 14. nov. 2019 kl. 14:22 skrev Dawid Weiss : > > > > > > Your understanding is incorrect, Michael. > > > > > > This: > > > > > >> ./gradlew lucene:lucene-analyzers:lucene-analyzers-nori:test seems to > > >> work > > > > > > runs task 'test' inside module > > > lucene:lucene-analyzers:lucene-analyzers-nori > > > > > > while this: > > > > > >> ./gradlew lucene:lucene-analyzers:test > > > > > > tries to run task 'test' in module lucene:lucene-analyzers but this > > > project doesn't have this task at all. > > > > > > Try pointing at a folder instead of fully qualified project name > > > (benefit of the shell expanding paths as well): > > > > > > ./gradlew -p lucene/analysis test > > > > > > the difference being it'll try to run the 'test' task in any of the > > > submodules under that folder. > > > > > > Also, this will show you all available tasks and projects: > > > > > > gradlew tasks --all > > > > > > > > > Dawid > > > > > >> > > >> does not. it would really be nice to have a way to run all the analysis > > >> tests > > >> > > >>> On Thu, Nov 14, 2019 at 8:05 AM Michael Sokolov > > >>> wrote: > > >>> > > >>> I'm trying to run the tests in the lucene/analysis module (really I'd > > >>> like to run tests in lucene/analysis/kuromoji), but I'm having trouble > > >>> figuring out the naming convention and/or the project structure. It > > >>> doesn't seem to be the same as the directory structure? EG I am able > > >>> to run tests in core with: > > >>> > > >>>./gradlew lucene:lucene-core:test > > >>> > > >>> although I expected it to be > > >>> > > >>>./gradlew lucene:core:test > > >>> > > >>> I forget how I stumbled on the "correct" naming > > >>> > > >>> but none of these work: > > >>> > > >>>./gradlew lucene:analysis:test > > >>>./gradlew lucene:lucene-analysis:test > > >>>./gradlew lucene:analyzers:test > > >>>./gradlew lucene:lucene-analyzers:test > > >>> > > >>> (gradle suggested the "lucene-analyzers" project name) > > >>> > > >>> where is the mapping from module to gradle project name kept? Can we > > >>> make it consistent with the directory naming, and ideally not have an > > >>> explicit mapping at all? > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > >> For additional commands, e-mail: dev-h...@lucene.apache.org > > >> > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Perhaps. I don't use this wrapper. Knowing the difference and understanding what you're expressing with both variants is all it takes, really. D. On Thu, Nov 14, 2019 at 5:08 PM Jan Høydahl wrote: > > Isn’t this why Mark recommended using gdub (gw) so you can run from within > sub folders? > > Jan Høydahl > > > 14. nov. 2019 kl. 14:22 skrev Dawid Weiss : > > > > Your understanding is incorrect, Michael. > > > > This: > > > >> ./gradlew lucene:lucene-analyzers:lucene-analyzers-nori:test seems to work > > > > runs task 'test' inside module lucene:lucene-analyzers:lucene-analyzers-nori > > > > while this: > > > >> ./gradlew lucene:lucene-analyzers:test > > > > tries to run task 'test' in module lucene:lucene-analyzers but this > > project doesn't have this task at all. > > > > Try pointing at a folder instead of fully qualified project name > > (benefit of the shell expanding paths as well): > > > > ./gradlew -p lucene/analysis test > > > > the difference being it'll try to run the 'test' task in any of the > > submodules under that folder. > > > > Also, this will show you all available tasks and projects: > > > > gradlew tasks --all > > > > > > Dawid > > > >> > >> does not. it would really be nice to have a way to run all the analysis > >> tests > >> > >>> On Thu, Nov 14, 2019 at 8:05 AM Michael Sokolov > >>> wrote: > >>> > >>> I'm trying to run the tests in the lucene/analysis module (really I'd > >>> like to run tests in lucene/analysis/kuromoji), but I'm having trouble > >>> figuring out the naming convention and/or the project structure. It > >>> doesn't seem to be the same as the directory structure? EG I am able > >>> to run tests in core with: > >>> > >>>./gradlew lucene:lucene-core:test > >>> > >>> although I expected it to be > >>> > >>>./gradlew lucene:core:test > >>> > >>> I forget how I stumbled on the "correct" naming > >>> > >>> but none of these work: > >>> > >>>./gradlew lucene:analysis:test > >>>./gradlew lucene:lucene-analysis:test > >>>./gradlew lucene:analyzers:test > >>>./gradlew lucene:lucene-analyzers:test > >>> > >>> (gradle suggested the "lucene-analyzers" project name) > >>> > >>> where is the mapping from module to gradle project name kept? Can we > >>> make it consistent with the directory naming, and ideally not have an > >>> explicit mapping at all? > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Isn’t this why Mark recommended using gdub (gw) so you can run from within sub folders? Jan Høydahl > 14. nov. 2019 kl. 14:22 skrev Dawid Weiss : > > Your understanding is incorrect, Michael. > > This: > >> ./gradlew lucene:lucene-analyzers:lucene-analyzers-nori:test seems to work > > runs task 'test' inside module lucene:lucene-analyzers:lucene-analyzers-nori > > while this: > >> ./gradlew lucene:lucene-analyzers:test > > tries to run task 'test' in module lucene:lucene-analyzers but this > project doesn't have this task at all. > > Try pointing at a folder instead of fully qualified project name > (benefit of the shell expanding paths as well): > > ./gradlew -p lucene/analysis test > > the difference being it'll try to run the 'test' task in any of the > submodules under that folder. > > Also, this will show you all available tasks and projects: > > gradlew tasks --all > > > Dawid > >> >> does not. it would really be nice to have a way to run all the analysis tests >> >>> On Thu, Nov 14, 2019 at 8:05 AM Michael Sokolov wrote: >>> >>> I'm trying to run the tests in the lucene/analysis module (really I'd >>> like to run tests in lucene/analysis/kuromoji), but I'm having trouble >>> figuring out the naming convention and/or the project structure. It >>> doesn't seem to be the same as the directory structure? EG I am able >>> to run tests in core with: >>> >>>./gradlew lucene:lucene-core:test >>> >>> although I expected it to be >>> >>>./gradlew lucene:core:test >>> >>> I forget how I stumbled on the "correct" naming >>> >>> but none of these work: >>> >>>./gradlew lucene:analysis:test >>>./gradlew lucene:lucene-analysis:test >>>./gradlew lucene:analyzers:test >>>./gradlew lucene:lucene-analyzers:test >>> >>> (gradle suggested the "lucene-analyzers" project name) >>> >>> where is the mapping from module to gradle project name kept? Can we >>> make it consistent with the directory naming, and ideally not have an >>> explicit mapping at all? >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Your understanding is incorrect, Michael. This: > ./gradlew lucene:lucene-analyzers:lucene-analyzers-nori:test seems to work runs task 'test' inside module lucene:lucene-analyzers:lucene-analyzers-nori while this: > ./gradlew lucene:lucene-analyzers:test tries to run task 'test' in module lucene:lucene-analyzers but this project doesn't have this task at all. Try pointing at a folder instead of fully qualified project name (benefit of the shell expanding paths as well): ./gradlew -p lucene/analysis test the difference being it'll try to run the 'test' task in any of the submodules under that folder. Also, this will show you all available tasks and projects: gradlew tasks --all Dawid > > does not. it would really be nice to have a way to run all the analysis tests > > On Thu, Nov 14, 2019 at 8:05 AM Michael Sokolov wrote: > > > > I'm trying to run the tests in the lucene/analysis module (really I'd > > like to run tests in lucene/analysis/kuromoji), but I'm having trouble > > figuring out the naming convention and/or the project structure. It > > doesn't seem to be the same as the directory structure? EG I am able > > to run tests in core with: > > > > ./gradlew lucene:lucene-core:test > > > > although I expected it to be > > > > ./gradlew lucene:core:test > > > > I forget how I stumbled on the "correct" naming > > > > but none of these work: > > > > ./gradlew lucene:analysis:test > > ./gradlew lucene:lucene-analysis:test > > ./gradlew lucene:analyzers:test > > ./gradlew lucene:lucene-analyzers:test > > > > (gradle suggested the "lucene-analyzers" project name) > > > > where is the mapping from module to gradle project name kept? Can we > > make it consistent with the directory naming, and ideally not have an > > explicit mapping at all? > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
OK with some grepping I I found these module names in various places (looks like they were defined as maven module names, where I guess maybe it is best practice for every submodule's name to contain the complete hierarchy of all its ancestor modules??) ./gradlew lucene:lucene-analyzers:lucene-analyzers-nori:test seems to work but ./gradlew lucene:lucene-analyzers:test does not. it would really be nice to have a way to run all the analysis tests On Thu, Nov 14, 2019 at 8:05 AM Michael Sokolov wrote: > > I'm trying to run the tests in the lucene/analysis module (really I'd > like to run tests in lucene/analysis/kuromoji), but I'm having trouble > figuring out the naming convention and/or the project structure. It > doesn't seem to be the same as the directory structure? EG I am able > to run tests in core with: > > ./gradlew lucene:lucene-core:test > > although I expected it to be > > ./gradlew lucene:core:test > > I forget how I stumbled on the "correct" naming > > but none of these work: > > ./gradlew lucene:analysis:test > ./gradlew lucene:lucene-analysis:test > ./gradlew lucene:analyzers:test > ./gradlew lucene:lucene-analyzers:test > > (gradle suggested the "lucene-analyzers" project name) > > where is the mapping from module to gradle project name kept? Can we > make it consistent with the directory naming, and ideally not have an > explicit mapping at all? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
