JRebel rebel.xml generation


(Marcel Overdijk) #1

The Gradle JRebel plugin has a task to generate the rebel.xml file.

I’m migrating my current Maven project to Gradle and in Maven the the Gradle Maven plugin is hooked to the processResources phase.

What should I do to use something similar in Gradle. I think I need to override a task and call the generateRebel task.

Something like:

someTask << { tasks.generateRebel.execute() }

But I wonder to what existing task I should attach this? Note that I read about processResources in the docs but this one is not listed when I do gradle tasks?

Regards, Marcel


(Tye Howard) #2

buildscript {

repositories {

mavenLocal()

mavenCentral()

mavenRepo(name: ‘zt-public-snapshots’,

url: ‘http://repos.zeroturnaround.com/nexus/content/groups/zt-public/’)

}

dependencies {

classpath group: ‘org.zeroturnaround’, name: ‘gradle-jrebel-plugin’, version: ‘1.0.2-SNAPSHOT’

} } apply plugin: “java” apply plugin: “rebel”

build.dependsOn generateRebel


(Marcel Overdijk) #3

Thanks!

PS: JRebel plugin 1.0.3-SNAPSHOT is also available.


(Marcel Overdijk) #4

PS2: How did you do that formatting?


(Tye Howard) #5

You mean the < code > tags?


(Tye Howard) #6

Just add < code > … some code here </ code > but take the spaces out of the tags.


(Marcel Overdijk) #7

I see the small letters now :blush:

Note that I had to change

build.dependsOn generateRebel

to

war.dependsOn generateRebel

as the gaeRun task I’m using (from the Gradle App Engine Plugin) does not call the build task.

It calls:

compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:generateRebel
:war UP-TO-DATE
:gaeExplodeWar
:gaeRun

Or do you think adding the dependency to another task would be better?


(Peter Niederwieser) #8

You should add the task dependency to those task(s) that make use of the ‘rebel.xml’ file produced by the ‘generateRebel’ task. If that file needs to go into the War, then ‘war.dependsOn generateRebel’ makes sense.


(Marcel Overdijk) #9

Yes indeed Peter. That’s why I think was task should be the one to use.

PS: Does Gradle make a difference in internal/public tasks or something. E.g. processResources seems to be a task, but is not listed when calling gradle tasks Just wondering why this is…


(Peter Niederwieser) #10

There’s some heuristic in place which tasks to show by default. The aim is to only show the tasks that the user will (llikely) invoke directly, to avoid cluttering the output with irrelevant details. Apart from that, all tasks are equal, and there is no private/public distinction. To display all tasks, use ‘gradle tasks --all’, as indicated at the bottom of the ‘gradle tasks’ output.