When running a GWT app through the Jetty server:
./mvnw jetty:run -pl app-server -am -Denv=dev
Within the container of Github Codespaces, it automatically makes a proxy to forward the internal port to the outside world like:
https://{username}-humble-couscous-{some-id}-8081.preview.app.github.dev/
Now when this page loads, it tries to load SuperDev Mode at port 9876 as such:
https://{username}-humble-couscous-{some-id}-8081.preview.app.github.dev:9876
But, the port 9876 is proxied to a different URL, like https://{username}-humble-couscous-{some-other-id}-9876.preview.app.github.dev
Now I'd like to ask if there's a way to change the behavior of SDM in maven as such the project would load the SDM from within a given proxy or something similar.
Related
I have created a simple Selenium+java maven project locally on my machine. I am able to execute the testing locally triggering it with Maven.
I want to trigger it from Jenkins (which is installed on a remote machine (my company's QA server))
I am using the option 'custom workspace' of Jenkins.
As the Jenkins is on the server, it's not able to understand/locate the local path
'C:\Automation\MavenProject\'
How I can achieve this?
You can do it with master-slave concepts in Jenkins. Slave machine would be your windows machine which will connect to master Jenkins with the help of some jars. You need to create a node on your Jenkins server and after adding the configuration, you need to download the corresponding slave jars on your machine. Once you execute those jars on your local machine, it will interact with Jenkins server. Your Jenkins job can then perform further activities on your slave machine.
Also in the Jenkins job, you need to refer to this node by enabling the following option.
Restrict where this project can be run
1)Create a Maven Project in Jenkins, you may have to install some plugin if its not visible
Pushing your code to some type of version Control like Github
You need to configure Jenkins to provide GitHub build information and POM Location
Since you Jenkins is hosted up in the server, you have be able to access it public, you need to download Github integration plugin and configure jenkins to provide GitHub hook trigger for GITScm polling and similar action in github itself
This should get you going, also google or youtube, lots of solution , one example
https://www.youtube.com/watch?v=PhxZamqYJws
I have a jersey 2 rest api. I use rest assured for unit testing my api. I use TravisCI for continuous integration. My project is using maven.
When the travis build gets triggered, it cannot run the tests because the connection is refused. This is normal because nothing is listening to port 8080.
When I run mvn test locally with tomcat running, the build works(travisci builds with this command).
Travis will not start up the server for me, if I do not specify it in scripts steps.
How can I tell travis to start up the tomcat server for me ?
.travis.yml :
language: java
I have created an API using Ratpack and Groovy. All the GET, POST apps are working locally. Now I want this to move it to some remote server(say dev environment). How can I do this?
To start and run the app in local, I have to do either "gradle run" or "Run the Ratpack.groovy as a groovy script" from eclipse IDE. Then it says "Ratpack Server running in localhost:8080". And then I can use the APIs as localhost:8080/api/.../.../... but at the same time when I try to run it as JAVA Application, I am getting error as:
{"#timestamp":"2016-06-02T14:47:06.026+05:30","#version":1,"message":"Starting server...","logger_name":"ratpack.server.RatpackServer","thread_name":"main","level":"INFO","level_value":20000,"tags":null}
Exception in thread "main" java.io.UncheckedIOException: java.io.IOException: Is a directory
at ratpack.util.Exceptions.uncheck(Exceptions.java:52)
at ratpack.groovy.Groovy.ratpack(Groovy.java:112)
at ratpack.groovy.Groovy$ratpack.callStatic(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:206)
at Ratpack.run(Ratpack.groovy:22)
To deploy it in prod, I moved the jar to the server. After that what should I do to start the Ratpack server or rather API service?
I would recommend setting up a CI pipeline that builds a java jar and deploys the artifact to your target environment.
I recommend using the Shadow Plugin from John Engleman https://plugins.gradle.org/plugin/com.github.johnrengelman.shadow
This plugin produces a shadow jar (similar to Maven's shaded jar) that can optionally include bash scripts or batch scripts for starting your application.
High level suggestion:
Add the shadow plugin to your gradle build file
plugins {
id 'io.ratpack.ratpack-groovy' version '1.3.3'
id 'com.github.johnrengelman.shadow' version '1.2.3'
}
Have your CI server or you manually execute `gradlew installShadowApp
SCP/FTP this artifact from your build/installShadow directory to your target server
Invoke the shell script from build/installShadow/$appName/bin/$appName to start application
For a more maintainable solution I would recommend registering this shell script as a service or with a solution like monit/upstart/ etc
For a more detailed example on deploying to Heroku as an example take a look at my notes: http://danhyun.github.io/2016-gr8confeu-rapid-ratpack-groovy/#deploying_to_heroku
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.
How can I automatically deploy a war from Nexus to Tomcat?
I have a maven web project which gets built and deployed (both SNAPSHOT and release versions) on Nexus successfully. I would like to know if there is feature/plugin in Nexus where it picks the released war and deploys on remote Tomcat automatically?
I know that you can deploy the war to remote Tomcat using maven-tomcat-plugin but would like to know if there is an alternative solution.
Please guide.
Typically you'd use a CI tool like Jenkins to run the Maven build that publishes your War file into Nexus. Nexus would then be used by whatever tool you're using to push the War onto the target tomcat environment:
There are lots and lots of options.
Jenkins post build SSH script
Run a post-build SSH task from Jenkins that does something like this on the target tomcat server:
curl "http://myrepo/nexus/service/local/artifact/maven/redirect?r=releases&g=myorg&a=myapp&v=1.1&e=war" \
-o /usr/local/share/tomcat7/webapps/myapp.war
service tomcat7 restart
Rundeck
My preference is to use Rundeck for deployments, because it has a Nexus plugin, providing convenient drop-down menus of available releases.
There is also a Rundeck plugin for Jenkins that can be used to orchestrate a CI process with Jenkins performing the build, hand-over to Rundeck for deployment, followed by a Jenkins call-back to run the integration tests.
Chef
I also use chef which can be used to automatically deploy software in a pull fashion.
The artifact cookbook has direct support for Nexus, whereas the application_java cookbook uses a more generic "pull from a URL" approach that also works well.
..
..
The list goes on, so I hope this helps.
We used UrbanCode for the deployment automation, retrieves war from Artifactory/Nexus and deploy to the target server.
I used the Nexus Rest-API, these endpoints downloads the artifact to Jenkins workspace.
In order to deploy Snapshot & Release to Tomcat we can create a Jenkins parameterized job and pass the parameters to the REST endpoint, also to deploy to a server like Tomact "Deploy WAR/EAR" Jenkins plugin will help.
We can parameterize the endpoint and use as part of "Build" step along with "Execute Shell script" option for the build.
wget --user=${UserName} --password=${Password} "http://192.168.49.131:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=${GroupId}&a=${ArtifactId}&v=${Version}&e=${TypeOfArtifact}" --content-disposition
Actual endpoints to Nexus looks something like below.
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=snapshots&g=org.codezarvis.artifactory&a=hushly&v=0.0.1-SNAPSHOT&e=jar" --content-disposition
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=org.codezarvis.artifactory&a=hushly&v=0.0.5&e=jar" --content-disposition
Thanks
-Sudarshan