My current Setup:
I have Ecliple Mars installed on Windows 10
I have some repositories checked out in my Project explorer which I basically use for any code changes, debugging purpose.
I have tomcat installed in C directory and have its path configured in the Servers section of eclipse.
So, every time I do any code changes in eclipse, I manually go into the eclipse workspace, and do the maven build using the following commandmvn -Plocal -DskipTests=true clean install, and then manually copy the war generated in the target folder into the webapps directory of my tomcat.
After doing all these, I start my tomcat in debug mode catalina jpda start and then setup Remote Java Application in eclipse for a particular module.
I can then setup breakpoints and see the changes in the debugger.
I am wondering , all of the above steps are time consuming if I have to do frequent code changes and then debug something in Debug mode in eclipse as I have to repeat steps 4 to 6 again and again for any code changes.
Could anyone tell me if there is a quick way to achieve the same goal?
You can run application dirrectly from maven via maven-{your_servlet_container}-plugin (maven-tomcat-plugin, maven-jetty-plugin, etc.). you can also specify debug mode there, so all you need to do is just run maven and connect in eclipse to remote app.
set ENV variable for always run maven in debug:
set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
(unset by setting this value to empty string)
with env variable:
mvn -Plocal -DskipTests=true clean tomcat7:run
or run mvnDebug:
mvnDebug -Plocal -DskipTests=true clean tomcat7:run
If you have your tomcat configured with eclipse properly, then you don't need to perform all these steps. I am not sure if you want to automate all these steps from outside. if yes, then either you can automate above steps with writing all in a batch file & triggering all steps with it (not a standard way) or using maven plugins to automate most of these steps.
Hope this information will help...
Related
How can I compile (if changes were made) and run Jenkins from source on localhost without running any tests?
Obviously that I read the documentation but this doesn't really say how to run it without any tests, only to how to compile the war file.
The funny part is that the doc page even specifies on how to run inside the debugger but that's not what I want.
I just want to write a script that compiles and runs it, ideally even killing it if it was already running (so I can run it multiple times without worrying about being unable to start).
I am on MacOS but I am pretty sure that solution would work on almost any system.
Jenkins used maven as it's build tool, so just add this system parameter
mvn -DskipTests=true ...
to skip the tests.
It seems that running Jenkins from build needs something long like like
mvn clean install -pl war -am -DskipTests && java -jar war/target/jenkins.war
What's the problem?
Is it possible to debug a Gradle web app running via Jetty plugin (using jettyRun or jettyRunWar) by using a IntelliJ IDEA Run/Debug Configuration?
I know that it is possible (I've done it before) to do it with Maven/Tomcat7 plugin and creating a simple Maven Run/Debug Configuration with the clean package tomcat7:run goals.
I've tried to create a Gradle Run/Debug Configuration with the clean jettyRunWar tasks. If I Run the configuration, everything works well. But the Debug option is not working as expected: the application actually runs, but debugger won't connect.
However, I did manage to debug the project by running on debug mode externally, like this:
$ export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n"
$ ./gradlew clean jettyRunWar
And then creating a Remote Run/Degug Configuration with all the default configurations except the port, which was set to 9999.
But that's not the solution I was looking for. I want to be able to debug the project by only clicking a button. Am I missing something?
Not in the mood to read everything? Here's an example
I've created a simple IDEA/Gradle/Jetty web app using Jersey available on Github here. The problem can be reproduced by:
Cloning the repository
Importing it on IDEA
Creating a Gradle Run/Debug Configuration for the root project with the clean jettyRunWar tasks
Debug using the configuration
The debugger won't connect and breakpoints won't work.
I am using:
IntelliJ IDEA Community Edition 2016.1.3 (OS X)
Gradle 2.7 (a wrapper is available on the Git repository, so it doesn't matter)
I started to investigate the guice-rf-activities artifact with the new maven gwt plugin from Thomas Broyer.
I played a little bit with the code and added a function on the GreetingService on the serverside. I followed down the path and added the required bits and bytes until the code was properly calling either the greetServer or insultServer method.
I found, that a simple SDM recompile did not make the method available on the server. Restarting the Tomcat did not help either. Saving a file in eclipse did not trigger the compile properly.
In the end, running a full module compile did the trick.
I see this as a problem, as any change on the service will potentially give you some time for coffee on large projects. Is there some "trick", I did not do, or is the complexity of RequestFactory code generation that heavy, that I cannot simply use the SDM + JRebel or server restart to change the service interfaces?
UPDATE: The way described by Thomas (thanks!) works, if you plan to start your tomcat with the maven tomcat target.
UPDATE2: Described the launcherDir approach to get the wtp/eclipse/mvn/Jrebel to run.
If you want to use the eclipse wtp tomcat launcher and, as I do, JRebel, to compile your server-classes on the fly, the JRebel reload will not catch the ofuscated RF service names.
To fix this, add the following JVM attribute to your wtp launch configuration (thanks, Thomas!):
-Dgwt.rf.ServiceLayerCache=false
When the server interface changes, the following happens
(eclipse Luna Service Release 2 (4.4.2), JRebel 6.x):
change your service and context classes as required
you see JRebel reloading the class
call mvn process-classes on the commandline
you see JRebel reloading the obfuscationfactory
SDM compile in the browser (F5 will do the trick)
Your service is now working in the client
Linking the gwt client code with the wtp server
To link the codeserver with the wtp environment, the src/main/webapp folder needs to contain your GWT code folder.
To achieve this, the codeserver must be directed to generate the SDM stub at the right location. Add a property to the module/pom.xml as such:
<properties>
<gwt.launcherDir>${project.build.directory}/gwt/launcherDir</gwt.launcherDir>
</properties>
Additionally, configure the gwt maven plugin to use the property instead:
<build>
<plugins>
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<inherited>false</inherited>
<configuration>
<launcherDir>${gwt.launcherDir}</launcherDir>
</configuration>
</plugin>
</plugins>
...
To run the codeserver inside eclipse or on the commandline, give the proper definition for gwt.launcherDir to maven. I am using a
small cmd to run the codeserver for eclipse:
mvn -Dgwt.launcherDir=module-app-server\src\main\webapp gwt:codeserver
This way, the "recompile on f5" works very nice and smooth. This is finally the full integration of GWT in eclipse with maven and JRebel. Wow. Kudos to #TBroyer :-)
The client side doesn't need anything special. The server side though requires the RequestFactory and all its RequestContext and proxies hierarchy to be processed by the validation tool.
From the command line, in the context of the archetypes, that means launching the process-classes phase on the *-server module, e.g.
mvn process-classes -pl *-server -am
With the mvn tomcat7:run -Denv=dev running, Tomcat should detect the class changes and automatically reload the webapp.
Then just refresh the page in the browser, and after authenticating again (reloading the webapp in Tomcat loses the session/authentication) you can see the changes end-to-end.
Steps to reproduce:
create the project
in one terminal, launch mvn gwt:codeserver -pl *-client -am
in another terminal, launch mvn tomcat7:run -pl *-server -am -Denv=dev
open http://localhost:8080 in your browser, sign into the webapp and notice the client-side app compiling automatically (that's the new SDM in GWT 2.7)
edit *-shared/src/main/java/**/GreetingContext.java and duplicate greetServer as insultServer
similarly, edit *-server/src/main/java/**/GreetingService.java and duplicate greetServer and insultServer (change the Hello message into an insult to feel the change)
edit *-client/src/main/java/**/GreetingActivity.java and replace the call to greetServer to a call to insultServer (or add another button and duplicate the code)
in yet another terminal, run mvn process-classes -pl *-server -am; notice that Tomcat reloads the webapp
Refresh the page in the browser, sign in again, and notice the client-side app recompiling. Hit the button and get insulted rather than greeted. QED.
The validation tool can be configured as an annotation processor in your IDE; see https://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation for the details. Note that Eclipse is notoriously bad (broken?) wrt annotation processing; it might be better to not run the processor in the editor as they call it (i.e. incrementally) and instead trigger a project build when you're done (that should –hopefully– be equivalent to the mvn process-classes), or you could just launch the mvn process-classes from within Eclipse.
Note that I advise against launching mvn gwt:codeserver and mvn tomcat7:run from within Eclipse, as Eclipse hard-kills processes, which generally causes the CodeServer to stay alive (it's a forked process), and won't run your JVM shutdown hooks or ServletContextListener's contextDestroyed.
I have a maven project. I want to debug tests that run during the project assembly. I run maven from cli
mvnDebug -DforkCount=0 test
Then I could successfully connect with remote debugger to the running jvm from Intellij. All necessary breakpoints are set. But it wouldn't stop at the breakpoints. Build successful and that is all.
This command works properly though
mvn -Dmaven.surefire.debug test
But I need to do it with the first.
I did not override plugin configuration so version 2.12 was used. The option that I needed was -DforkMode=never. Since 2.14 this option is deprecated and -DforkCount=0 should be used instead. http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
You need the debugForkedProcess option to surefire.
I want to debug Eclipse build with tests. I tried to run it by Run > Debug Configurations > Maven Build. In Base directory is my Maven repo directory with pom.xml file, in goals 'clean install'. When I click on debug Eclipse starts build, run tests but it doesn't stops on breakpoints.
Easiest way I find is to:
Right click project
Debug as -> Maven build ...
In the goals field put -Dmaven.surefire.debug test
In the parameters put a new parameter called forkCount with a value
of 0 (previously was forkMode=never but it is deprecated and doesn't work anymore)
Set your breakpoints down and run this configuration and it should hit the breakpoint.
if you are using Maven 2.0.8+, then it will be very simple,
run mvndebug from the console, and connect to it via Remote Debug Java Application with port 8000.
probleme : unit test result are not the same runing with eclipse and maven due ti order of library used by eclipse and maven.
In my case the test was success with maven but i want to debug my unit test using eclipse, so
the most easy way to debug unit test class with eclipse and runing maven is :
1) mvn -Dtest=MySuperClassTest -Dmaven.surefire.debug test ==> it will listen to the 5005 port (default port)
2) Go to eclipse, open a debug configuration, add a new java remote application and change the port to 5005 and debug
3) of course you must add break point somewhere in the class that you want to debug
The Run/Debug configuration you're using is meant to let you run Maven on your workspace as if from the command line without leaving Eclipse.
Assuming your tests are JUnit based you should be able to debug them by choosing a source folder containing tests with the right button and choose Debug as... -> JUnit tests.