I have a IntelliJ Community Edition with Gradle 4.3.1 and com.bmuschko.tomcat plugin running. My application will be deployed currently and its working, now I want to enable JRebel for this. So that changes on my webapp folder will be hot-deployed.
At the plugin site is a description for this
Edit your Gradle startup script and add the following line to it to
tell Gradle to use the JRebel agent. Please make sure to set the
environment variable REBEL_HOME that points to your JRebel
installation directory.
JAVA_OPTS="-javaagent:$REBEL_HOME/jrebel.jar $JAVA_OPTS"
Currenty its not clear for me where do I need to change this? Obiously JRebel is not active when I start my tomcat with the pluging.
What I did:
installed the jrebel plugin in intellij
enabled the jrebel functionality with the ide
manually added a rebel.xml file (as described on the plugin site) in the build/classes/main folder
Where do I need to edit the gradle start up so that jrebel is active for gradle builds?
There are two ways you can run gradle that will affect how to add the arguments, with the daemon and without.
If you run gradle tomcatRun --no-daemon the arguments for JRebel must be added via JAVA_OPTS or GRADLE_OPTS environment variables. So this means either running as GRADLE_OPTS=-agentpath:/path/to/jrebel/lib/libjrebel64.so gradle tomcatRun --no-daemon or specifying the variable in a script(gradlew if you are using it). If you run the gradle task directly from IntelliJ, you can specify environment variables there.
If you run with the daemon, the GRADLE_OPTS variable will set JVM arguments for the launcher process, not the daemon. This will mean that JRebel is included in the wrong process and your changes aren't monitored. One way to set JVM arguments for the daemon is by adding the following to your gradle.properties
org.gradle.jvmargs='-agentpath:/path/to/jrebel/lib/libjrebel64.so'
Running with the daemon will mean that the JRebel banner is not displayed so don't be alarmed as the changes will still be monitored.
Also since JRebel 7.0 the folder structure was changed and the jrebel.jar located in installation root is the new core which requires additional bootstrapping provided by the included native agents in the jrebel/lib dir. It is suggested to use the corresponding native agent for your OS/arch using the agentpath argument and not the javaagent argument as in the tomcat plugin docs.
Related
I have a multi-module project that uses maven. Is there a way I can point IntelliJ to maven target/ folder so when I start Debug it won't rebuild the project from scratch and re-upload a whole project via JRebel all over again.
Basically, use target/ as a build folder. Changing compile output path didn't work as I expected it to not compile classes that were compiled by mvn already.
The IntelliJ Run/Debug configurations can specify which actions happen before launching the application.
By default for say web applications, this would display
Build
Build x artifact
You may remove both entries if you are happy with building via maven before launching the application.
Regarding the JRebel side of it - it should certainly not be updating the classes on the second compile assuming nothing changed. The classes have their hashes checked before a reload. This is assuming maven and IntelliJ are using the default javac compiler. If either is configured to use ecj compiler, it's best to let JRebel only see classes built with the same compiler.
I just set up JRebel to use with my Spring web app in IntelliJ, and was very surprised to learn that I have to manually rebuild the project/recompile every time I want my changes to be reflected. Doesn't this defeat the whole purpose of JRebel? Is there something I'm missing here? With Eclipse it was nearly instant, make changes anywhere, save, instantly reflected in running app. With IntelliJ the process seems very clunky. Am I missing something here?
Running with JRebel in IntelliJ involves starting your application using Run > Run with JRebel and when you change your application code you have to build the project in order for IntelliJ to compile classes and update your application.
You can do this by running SHIFT + F9 or Build > Build Project
From the JRebel docs:
JRebel relies upon your IDE to do the compiling. JRebel reloads your compiled .class files and not your .java files. When you change code, JRebel pushes the changed classes and resources to the server without redeploying.
Regardless of what IDE you use, JRebel still needs the IDE to compile the classes before it can update the running application. IntelliJ is no different to Eclipse in this regard. Perhaps Eclipse was just auto building the project without you being aware of it. You can also instruct IntelliJ to auto build from Preferences > Build, Execution, Deployment > Compiler > Build project automatically.
Here's a screenshot showing that configuration setting:
I deploy my application using Maven on Liferay 7 (on Tomcat 8). But I need to debug it. How to configure my debug? Because, when I start maven with debug mode, it builds and stops. I have no ideas how to deal with it
Maven with debug mode is only targeted to debug maven build processes. If you want to debug your portlet you should follow the next steps:
Run Menu Entry > Edit Configurations > Add New Remote Configuration > Configure your host and debug port
You have to check too that JPDA port is enabled your Tomcat (you can enable it in your startup.sh/startup.bat script adding jpda in the final line)
exec "$PRGDIR"/"$EXECUTABLE" jpda start "$#"
Quick generic answer (someone with actual IntelliJ experience can probably give more details):
You start tomcat, that has Liferay deployed. Follow the advice you have for "how to debug tomcat applications". The caveat is that you might need to point IntelliJ to the source files for some (all) of the modules in Liferay - which is a huge task (being composed out of 500 modules. For eclipse I'm aware of a fix, for IntelliJ I'm not aware. I'm pretty sure such a beast exists though.
It will be easier (e.g. quick) if you only need your own modules' source.
Can you use standalone + JRebel remote?
I have my IDE on Box A
I have my App on Box B
I want to be able to make gradle build on Box A and automatically have B hot deploy that.
If Possible I'd like all this needs to work without The intelliJ plugin because it's broken and produces the wrong paths to lib locations in our complex gradle project.
No.
Synchronization with remote servers can only done via JRebel IDE plugin.
If you have any troubles with the IDE plugin or the Gradle plugin, please contact support at support#zeroturnaround.com
It's not possible to use JRebel remoting without the IDE plugin as the remote server does licensing checks during a sync transaction and classes simply copied to the remote .cache folder will be rejected otherwise.
However you can still setup a manual remoting setup. For example you can create a "virtual" workspace on BoxB where classes/jars/wars are copied after the build. In this scenario disable the remoting plugin and use standard rebel.xml-s which map to the workspace on BoxB.
When doing changes, simply copy the files from BoxA to BoxB e.g. using rsync and they will be reloaded as usual. However note that in this setup you must provide the server on BoxB with a valid license.
I am working with a buildr project using IntelliJ IDEA and I want to get JRebel working. This is a Spring MVC project.
I have my rebel.xml configured and I created an ant script to re-package the application:
buildr package test=no
JRebel says it redeployed, but Spring seems to not be running after the redeploy.
The best you could do is to enable JRebel logging by adding -Drebel.log=true to JVM arguments and send the log file to support.
Do you see any messages in console that JRebel is actually started and is monitoring the directories? Maybe the license is missing?