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
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
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
> 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
> 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
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
> 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
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
>>
> 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
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
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?
>
>
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
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
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
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
15 matches
Mail list logo
