You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael Sokolov <ms...@gmail.com> on 2019/11/14 13:05:00 UTC
gradle module/project structure
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Erick Erickson <er...@gmail.com>.
> 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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Erick Erickson <er...@gmail.com>.
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 <da...@gmail.com> 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 <er...@gmail.com> 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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
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 <er...@gmail.com> 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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Erick Erickson <er...@gmail.com>.
Added SOLR-13935 for this general topic, please comment there if you’d rather.
> On Nov 15, 2019, at 10:36 AM, Dawid Weiss <da...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Erick Erickson <er...@gmail.com>.
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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Erick Erickson <er...@gmail.com>.
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 <da...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Michael Sokolov <ms...@gmail.com>.
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 <da...@gmail.com> 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 <ja...@cominvent.com> 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 <da...@gmail.com>:
> > >
> > > 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 <ms...@gmail.com> 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-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
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 <ja...@cominvent.com> 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 <da...@gmail.com>:
> >
> > 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 <ms...@gmail.com> 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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <da...@gmail.com>:
>
> 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 <ms...@gmail.com> 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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Dawid Weiss <da...@gmail.com>.
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 <ms...@gmail.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: gradle module/project structure
Posted by Michael Sokolov <ms...@gmail.com>.
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 <ms...@gmail.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org