gradle module/project structure

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

gradle module/project structure

Michael Sokolov-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Michael Sokolov-4
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Jan Høydahl / Cominvent
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 <[hidden email]>:
>
> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
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 <[hidden email]> 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 <[hidden email]>:
> >
> > 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Michael Sokolov-4
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> > >
> > > 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 <[hidden email]> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Erick Erickson
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Erick Erickson
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Erick Erickson
>  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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Erick Erickson
In reply to this post by Dawid Weiss-2
Added SOLR-13935 for this general topic, please comment there if you’d rather.

> On Nov 15, 2019, at 10:36 AM, Dawid Weiss <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Dawid Weiss-2
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: gradle module/project structure

Erick Erickson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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