Re: Adjusting to Gradle

2020-07-06 Thread Erick Erickson
I didn’t explain my use-case very well.

compile with fail on warnings
fix a bunch of warnings
repeat.

The overhead of running a test just to get the file to fail to compile was
what I was avoiding. Even “assemble” was noticeably slower than 
just “classes” for the mainline code.

All that said, it was a weird use case so I’ve no objection to removing
those bits, I doubt many other people will have use for classes and testClasses.

> On Jul 6, 2020, at 3:34 AM, Dawid Weiss  wrote:
> 
>> I used them  a _lot_ from inside IntelliJ when I was working on the
>> warnings, they run faster than assemble. So I guess they were on my mind.
> 
> I don't use IntelliJ's gradle at all, actually. The gradle panel has
> an option to switch to the built-in IntelliJ compiler and this works
> best for me (even if they
> say it's not recommended, it works just fine).
> 
>> testClasses in particular because, as you say, assemble doesn’t
>> compile the test classes (that lead to another 3,000 warnings just
>> when I thought I was through, sggg).
> 
> When you run a test they should be compiled automatically. Does
> intellij try to run
> assemble for tests? That would be weird.
> 
> 
> 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: Adjusting to Gradle

2020-07-06 Thread Dawid Weiss
> I used them  a _lot_ from inside IntelliJ when I was working on the
> warnings, they run faster than assemble. So I guess they were on my mind.

I don't use IntelliJ's gradle at all, actually. The gradle panel has
an option to switch to the built-in IntelliJ compiler and this works
best for me (even if they
say it's not recommended, it works just fine).

> testClasses in particular because, as you say, assemble doesn’t
> compile the test classes (that lead to another 3,000 warnings just
> when I thought I was through, sggg).

When you run a test they should be compiled automatically. Does
intellij try to run
assemble for tests? That would be weird.


D.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



Re: Adjusting to Gradle

2020-07-05 Thread Erick Erickson
I used them  a _lot_ from inside IntelliJ when I was working on the
warnings, they run faster than assemble. So I guess they were on my mind.

testClasses in particular because, as you say, assemble doesn’t
compile the test classes (that lead to another 3,000 warnings just
when I thought I was through, sggg).

Otherwise I don’t use them externally.

Feel free to edit them out if you’d like.

Erick

> On Jul 5, 2020, at 5:19 PM, Dawid Weiss  wrote:
> 
>> - "gradlew assemble”, “gradlew dev" and “gradlew classes” do _not_ compile 
>> the test classes. Use “gradlew testClasses” to compile the test classes 
>> independently if you have a need. Executing these from within IntelliJ 
>> provides convenient clickable links to problems.
> 
> Hi Erick. These tasks are rather internal - classes, testClasses...
> why would you need to call them explicitly? Typically you'd need to
> run tests (test or check tasks) which calls (depends on) appropriate
> tasks before. If you need a JAR, invoke assemble (which, correctly,
> doesn't compile test classes). It's better to explain tasks that serve
> high-level goals rather than low-level intermediate steps?
> 
> 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: Adjusting to Gradle

2020-07-05 Thread Dawid Weiss
> - "gradlew assemble”, “gradlew dev" and “gradlew classes” do _not_ compile 
> the test classes. Use “gradlew testClasses” to compile the test classes 
> independently if you have a need. Executing these from within IntelliJ 
> provides convenient clickable links to problems.

Hi Erick. These tasks are rather internal - classes, testClasses...
why would you need to call them explicitly? Typically you'd need to
run tests (test or check tasks) which calls (depends on) appropriate
tasks before. If you need a JAR, invoke assemble (which, correctly,
doesn't compile test classes). It's better to explain tasks that serve
high-level goals rather than low-level intermediate steps?

D.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org