https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
I don't, but if you want that functionality and do not necessarily need the IntelliJ function specifically, you could invoke 
./gradlew classes --continuous
, then Gradle will stay running and rerun the build as soon as relevant input file was chagned.
f
Aha, that sounds so nice and close to exactly what I need 😄 Can it also handle the case of a super large project (and big osgi stuff with lots of sub projects). Perhaps it is better to just monitoring on one or a few sub projects and auto build those only?
Copy code
./gradlew classes --continous
Calculating task graph as no cached configuration is available for tasks: classes --continous

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :sub-project-1:classes from command line.
> Unknown command-line option '--continous'.
And it seems not working out of the box if I run it from the root/master project. 🤔 Let me search a bit
A bit strange... so I can do 
./gradlew :application:classes
but adding --continous failed as above.
Some docs online mentioning 
-t
also works, and when I tried with 
./gradlew :application:classes  -t
it output such:
Copy code
./gradlew :application:classes  -t
Reusing configuration cache.

BUILD SUCCESSFUL in 2s
29 actionable tasks: 29 up-to-date
Configuration cache entry reused.

Waiting for changes to input files... (ctrl-d then enter to exit)
<-------------> 0% WAITING
> IDLE
> IDLE
> IDLE
> IDLE
> IDLE
However, changing a java file in IntelliJ has no effect, looking at the .class files it stays with the old one. Nothing new output on the gradlew command either... 🤔
And it should be 
--continuous
I missed a 
u
above...
v
I missed the u 😄
f
But the functionality is still not working? 🤔
v
But yeah, 
-t
is the same, just a short form
✅ 1
Why is the funcitonality not working?
Should work
f
🤔
v
And I don't know whether big project is a problem, just try it and if it doesn't work sufficiently try with a narrower scope
It monitors all input file of the tasks that were actually run and reruns the build if any changes
Most task should then be up-to-date, so should work quite fine probably even on larger projects.
f
I just update a file, and look at the output of the .class file, no update while this command is running. the command above already only compile a small sub-project called "application"
v
You will see in the build output if the build was rerun
f
Copy code
BUILD SUCCESSFUL in 4s
29 actionable tasks: 1 executed, 28 up-to-date
Configuration cache entry reused.

Waiting for changes to input files... (ctrl-d then enter to exit)
<-------------> 0% WAITING
> IDLE
> IDLE
> IDLE
The first time running it built stuff, and out put these, then it just stay there no matter what I change... could it be I am on windows and gradle is trigged via git bash?
v
No, should work fine, works here
🤔 1
Or let me retry, quite some while since I tried it. Which version are you using?
f
I also have these
Copy code
org.gradle.jvmargs=-Xmx8096m
org.gradle.parallel=true
org.gradle.configuration-cache=true
I am on 8.5
v
The feature exists since Gradle 2.5, wow, I thought it was more recent 😄
If you have configuration cache, you can actually remove parallel. With CC enabled all tasks run in parallel anyway if possible.
✅ 1
But I don't think it matters for this
Works fine here still:
Copy code
$ gw classes --continuous
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details
Calculating task graph as no cached configuration is available for tasks: classes
Type-safe project accessors is an incubating feature.
> Task :processResources
> Task :compileJava
> Task :classes

BUILD SUCCESSFUL in 46s
2 actionable tasks: 2 executed
Configuration cache entry stored.

Waiting for changes to input files... (ctrl-d then enter to exit)
modified: D:\Sourcecode\other\showcase\src\main\java\foo\Foo.java
Change detected, executing build...

Reusing configuration cache.
> Task :processResources UP-TO-DATE
> Task :compileJava
> Task :classes

BUILD SUCCESSFUL in 860ms
2 actionable tasks: 1 executed, 1 up-to-date
Configuration cache entry reused.

Waiting for changes to input files... (ctrl-d then enter to exit)
modified: D:\Sourcecode\other\showcase\src\main\java\foo\Foo.java
Change detected, executing build...

<=============> 100% EXECUTING [42s]
> IDLE
> IDLE
Also run through git bash on windows
f
I tried in a very small project I have beside me, it does work... 🤔 Let me try with another big project I have and see what happens (basically a clone of the other big one)
v
Is it really an input file of the executed tasks you did change? If you for example used 
classes
and changed a test class, it will not rerun as only the production classes got compiled.
There are actually some limitations, but I doubt you are hitting any of those: https://docs.gradle.org/current/userguide/command_line_interface.html#continuous_build_limitations
f
Yes I changed a major class and I open the .class file of it side by side. Not working on the other big class. I have a hunch - perhaps due to this: Can you perhaps quickly try put the root gradle script on the same level of a sibling folder? Aha, perhaps that "Gradle only watches for changes to files inside the project directory. Changes to files outside of the project directory will go undetected and not trigger a build."?
hmmm... 🤔
v
I'm not sure I understood. Can you sketch the layout or just try in your small play project?
f
Let me show you my big project file tree, it is sort of like this:
Copy code
- java
   |--lib1
         |--build.gradle.kts
   |--application
         |--build.gradle.kts
- build-logic
    |-- settings.gradle.kts
    |-- build.gradle.kts
- workspace
    |-- gradle(has gradlew jars and so on)
    |-- gradlew
    |-- settings.gradle.kts
so in my settings.gradle.kts I have:
Copy code
pluginManagement {
    repositories {
        gradlePluginPortal()
    }
    includeBuild("../build-logic")
}

file("../java").listFiles()
    ?.filter { it.isDirectory && !it.isHidden && !it.name.startsWith(".") && !ignoredSubFolders.contains(it.name) }
    ?.forEach {
        include(":it.name")
        project(":it.name").projectDir = file("../java/${it.name}")
    }
I am doing this because the stuff in 
java
folder is under svn, so all my colleagues are using eclipse to work with it. And I thought before I could check in all the gradle related stuff (as I am the only one using this tool), I sort of want to keep it outside of the version control system. Also would like to make it easier later someone else also want to try with a gradle build, they can just copy 
build-logic
and 
workspace
- and put those two folders besides their `java`folder, then they could build it. But now when I run the 
gradlew classes -t
command, I run it under `workspace`folder, perhaps that is why the continue build feature is not working any more.
I can try move the stuff in 
workspace
to one level above it. Not sure if it will have other said effects. For now it could be that my colleagues needs to copy 6 or 7 files and put them beside 
java
and mingle with other files on that level... A bit messy but still doable I guess. 🤔
v
I would say that structure does not qualify for that limitation. The files for each project are with the project directory of the project
f
Let me verify it then...
v
No, you are absolutely right
Copy code
$ mkdir -p ../java/foo                                                                              
$ cp -r src/ build.gradle.kts ../java/foo/
$ gw foo:classes --continuous
and it does not detect the changes
But I have no idea whether this is really what that limitation means, or whether it simply is a bug you found. I'd recommend you report it as bug with a small reproducer and then we see what the Gradle folks say.
🤔 1
👍 1
Such a flat layout is not absolutely uncommon. We also had it before it was deprecated (deprecation was reverted due to complaints from the community later). As the limitation says "files in project directories and the files are within project direcotries, just not with the root project directory, I would consider this a bug most probably.
✅ 1
f
Got it, by putthing the gradle stuff one level above on the big project now it works for me 🙂 Where do you think it a good place to report this "bug"? I can setup my small project like this and send them the link there so they can try it out
v
On Gradle GitHub issue tracker
Please also post a link to the issue here for reference
✅ 1
f
8 Views
Open in Slack
PreviousNext
Powered by