Jenkins on Jetty - Unable to update plugins - continuous-integration

I am after some pointers to the problem I have.
I am installing Jenkin 1.450 on CentOS 5.5. Java has been installed and JAVA_HOME had been set properly.
I deployed Jenkins on Jetty 8.0.4. I downloaded Jetty and extracted onto a user's directory. Jenkins is deployed to Jetty's webapps directory.
Then I created a directory outside Jetty's directory, and set JENKINS_HOME to that directory. Then I also set JETTY_HOME to the extracted jetty directory. Then I run Jetty using jetty.sh script which you can find in /bin.
All worked well and I can add users etc. Then from "Manage Plugins" section I see that there is a newer svn plugins, so I want to update it. So I begin the update process. At the end Jenkins tells me "subversion plugin is already installed. Jenkins needs to be restarted for the update to take effect" - so I restarted Jetty. However, checking the version of svn now it was still the same as before and it tells me again there is a new version.
Can somebody tells me where I did wrong?
Thanks!

Your set up is good. The issue is with Jenkins itself, and a bug has been opened for this on their JIRA:
https://issues.jenkins-ci.org/browse/JENKINS-12514
While this issue was resolved for new plugins in version 1.450, it remains in the upgrade feature.
Related bugs:
https://issues.jenkins-ci.org/browse/JENKINS-12632
https://issues.jenkins-ci.org/browse/JENKINS-12583

I've had the same issue today =)
I tried setting various things in the context:
<Call class="java.lang.System" name="setProperty"> <Arg>HUDSON_HOME</Arg> <Arg>/opt/jenkins</Arg> </Call>
<Call class="java.lang.System" name="setProperty"> <Arg>JENKINS_HOME</Arg> <Arg>/opt/jenkins</Arg> </Call>
However in the end the only thing that worked was to crack open the WAR and add the following to WEB-INF/web.xml (where /opt/jenkins is my jenkins home)
<env-entry>
<env-entry-name>HUDSON_HOME</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/opt/jenkins</env-entry-value>
</env-entry>
As soon as I did this all the previous installed/upgraded plugins that were marked as missing we present.

Related

Jenkins + Maven Manual Installation

I installed Jenkins on to 2 new machines no-problemo!
But, when attempting to integrate Maven, I am having "command not found" in my Jenkins log, yet I can run mvn no problem in the command line.
So, I thought it was a PATH issue - so I added the /bin and also the / (of the location where Maven is extracted to), yet I'm still getting the error.
I tried adding the PATH to my ~/.bash_profile as well, so my current PATH is:
$PATH:/usr/local/bin:/Users/jenkins/apache-maven-3.5.2/bin:/Users/jenkins/apache-maven-3.5.2
Still, Jenkins will not find Maven. I do NOT want to globally install Maven, as it may affect the other 5 build servers we have that are working with Maven correctly (not sure how it's working).
The issue was resolved by simply re-connecting the Jenkins Slave. Thanks for your feedback!

Couldn’t find any executable in apache-maven-3.3.3

I have a windows jenkins slave and I have download apache-maven-3.3.3 on it.
It is located C:\Users\myUsername\Desktop\apache-maven-3.3.3 This is copy and pasted from the windows explorer on my Windows slave.
Then when I point at this location in Jenkins and run a build. I get this error
Couldn’t find any executable in C:\Users\myUsername\Desktop\apache-maven-3.3.3
I have also tried Couldn’t find any executable in C:\Users\myUsername\Desktop\apache-maven-3.3.3\bin
This works just fine on my linux slaves. What is the difference? Why is this not working?
Maven changed the name of the executable in Maven 3.3 from mvn.bat to mvn.cmd. Jenkins recognized mvn.cmd since Jenkins 1.613 (see this commit). If you are on an earlier Jenkins version you can add a symlink from mvn.bat to mvn.cmd on windows as a workaround.
The executable is in the \bin folder (namely, mvn.bat). Try to point Jenkins to C:\Users\myUsername\Desktop\apache-maven-3.3.3\bin
First
Under your Windows machine
1. create an Environment Virable named MAVEN_HOME and set its value to C:\Users\myUsername\Desktop\apache-maven-3.3.3.
2. Add %MAVEN_HOME%\bin into your System PATH
Second
Go to
http://your-jenkins-server/computer/your-windows-slave/configure -->Node Properties-->Tool Locations-->(Maven)maven
and set its value to C:\Users\myUsername\Desktop\apache-maven-3.3.3 as well.
Third
Reconnect your jenkins slave, then rerun your job.
Well for me it was wrong setting for maven. Go to configure, under post build action, go to advanced setting and there fix the Maven version to be used, i changed it to maven 3.3.3 and it worked.
I am using Windows. The accepted answers does not work for me. So, I have to create a new Maven in Jenkins and select the option "Install automatically". Then it works.

Unit test code analysis using "sonar.*" property and maven-sonar-plugin

I'm trying to do code analysis of Java unit test using maven sonar plugin. But the plugin doesn't seem to take into account my sonar properties "sonar.*". I've tried to modify simple examples and it did work either. According to MSONAR-70, the issue has been fixed and I'm using the version 2.4.
For the test, I've tried it on a simple case:
Clone sonar-examples.git
use the project sonar-examples/projects/languages/java/maven/java-maven-simple as example
Renamed src/main to src/test
In the pom.xml, add to the properties section :
<sonar.sources>src/test/java</sonar.sources>
<sonar.binaries>target/test-classes</sonar.binaries>
Run mvn sonar:sonar.
--> the code analysis didn't took into account my settings. The project is created on SonarQube but code as not been analyzed.
If I use the sonar-runner command line, it's analyzing the code:
sonar-runner [...] -Dsonar.sources=src/test/java
-Dsonar.binaries=target/test-classes
-Dsonar.language=java
-Dsonar.sourceEncoding=UTF-8
-Dsonar.projectKey=org.codehaus.sonar:example-java-maven
-Dsonar.projectName="Simple Java Maven Project"
-Dsonar.projectVersion=1.0-SNAPSHOT
According to a previous revision of the question, the OP solved their problem like this:
We were using SonarQube 4.0 version. Updating the version to 4.4, made the properties be taken into account.
That was in 2014; the current version now is 5.5.
The steps to upgrade can be found here:
Stop the old SonarQube server
Download and unzip the new SonarQube distribution in a fresh directory, let's say NEW_SONARQUBE_HOME.
Start it using the default H2 database and use the update center to install the plugins you need.
Manually install any custom plugins.
Stop the new server.
Update the content of the sonar.properties and wrapper.conf files located in the NEW_SONARQUBE_HOME/conf directory with the content of the related files in the OLD_SONARQUBE_HOME/conf directory (web server URL, database settings, etc.). Do not copy-paste the old files.
If a custom JDBC driver is used, copy it into NEW_SONARQUBE_HOME/extensions/jdbc-driver/.
Back up your database.
Remove the data/es directory.
Start the new web server
Browse to http://localhost:9000/setup (replace "localhost:9000" with your own URL) and follow the setup instructions.

Trying to build Tomcat 6 from source: Ant doesn't download libs

I am trying to build Tomcat 6 or 7 on my machine from provided source codes.
I have checked out the sources from repository and ran the ant build.
In the very beginning of the build Ant needs to download the libs Tomcat needs. In the 6th version it is done by separate command 'ant download', in the 7th version this command is incorporated into build.xml.
The problem is that Ant cannot download the libs Tomcat needs for build while trying to build both the versions.
It stops here:
trydownload:
[get] Getting: http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.24/source/tomcat-native-1.1.24-src.tar.gz
[get] To: /Users/dmitrijskorov/libraries/tomcat-native-1.1.24/tomcat-native.tar.gz
After printing this nothing happens. No errors, no end of execution. The file itself is created inside the folder for downloads, but its size is 111KB instead of 262KB if I download it manually. Ping of that server also evaluates ok.
Looks like I have problems with Ant download task.
Probably the reason is some proxy settings I need to provide to Ant. But I dont know how to find out my proxy settings. All settings in all browsers and OS point to automatic detection of proxies and thus I cannot setup proxy in Ant build. And I dont know whether I need this at all.
MacOs Lion, Tomcat 6 or 7, Java 6.
With Ant 1.7 or later you can use the -autoproxy option to Ant to tell it to use the proxy settings from the operating system
ant -autoproxy download
Ref: Ant manual

"PWC6345: There is an error in invoking javac." error when using Jetty WTP plugin to deploy a JSP page on Jetty

I'm trying to deploy a JSP-page on Jetty, using the Jetty WTP plugin for Eclipse. But I get the error below. It looks like Jetty can't find javac. Is there any settings I have to do for the Jetty WTP plugin in Eclipse or how do I fix this?
The JSP page works fine if I export my project as a .war-file to jetty\webapps and then start Jetty manually using java -jar start.jar. But it doesn't work if I deploy using the Jetty WTP plugin for Eclipse as described.
I have my JAVA_HOME set to C:\Program Files (x86)\Java\jdk1.7.0_01 and I use Jetty 8.0.4 on Windows 7.
Servlets is working fine with the current setup. Any suggestions on how to solve this for JSP pages?
HTTP ERROR 500
Problem accessing /MyJavaWeb/formProcess. Reason:
PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
Caused by:
org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:378)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:119)
at org.apache.jasper.compiler.Jsr199JavaCompiler.compile(Jsr199JavaCompiler.java:208)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:384)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at com.example.FormProcessServlet.doPost(FormProcessServlet.java:39)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Unknown Source)
As Jan Bartel suggested, from Jetty: How to configure JSP:
by adding the line below in the start.ini-file in Eclipse, it works fine.
-Dorg.apache.jasper.compiler.disablejsr199=true
I too happened to suddenly get the org.apache.jasper.JasperException: PWC6345 with my Eclipse installation and the Jetty Maven Plugin (which I use to start up Jetty from within Eclipse).
The reason was that I updated my JDK installation shortly before. Inside Eclipse, this caused to change the "Installed JRE" to point to a plain JRE installation instead of a full-fledged JDK installation. A JDK installation is needed for Jasper, as Jasper needs javac (which is not provided by JRE).
In my case, the solution was to provide Eclipse with the JDK installation. To do so, select Window -> Preferences -> Java -> Installed JREs. Here, click Add..., then point to your JDK installation (in my case, JRE home should point to C:\Program Files (x86)\Java\jdk1.7.0_17). Click Finish. Then back in the Installed JREs overview, remove the old JRE reference and select the newly added JDK installation.
I got the PWC6345 error when running a webapp with Run-Jetty-Run plugin.
The fix was to change the Execution environments settings in Preferences.
Since I'm using java 7 I needed to change the setting for JavaSE-1.7.
Probably other execution environments will behave similarly.
Window -> Preferences -> Java -> Installed JREs -> Execution environments
Select JavaSE-1.7 on the left -> pick the *jdk*1.7.x_xx on the right hand side
Ok, solved this after a lot of searching around.
Download any jdk and point JAVA_HOME to this jdk.
Inside this jdk folder you will find ./bin and ./jre/bin
Copy the javac from ./bin and paste it in ./jre/bin [remember copy not cut]
Now in eclipse, Run->External-Tools->External-Tools-Configurations, select the build.xml for of your project in the left pane and click on the JRE tab in the right pane.
Click on installed JREs and add the jdk in the previous step.
Once done, select this new JRE (jdk1.6.0_31) as the 'Separate JRE', click on apply at the bottom and run.
This assumes you are doing a jetty:run using ant on eclipse.
Strange because this thread suggests:
The solution was to install the package jdk7-openjdk.
Perhaps this should be added to the list of dependencies (or maybe for jetty, and not solr itself)?
But that doesn't help much on Windows, where the binary for openjdk7 aren't easily available.
(In "OpenJDK availability for Windows OS" comments, eckes mentions having found some openjdk binaries for Windows, as part of the Build b146. However, said releases aren't maintained any more)
The bug report filled by the OP Jonas is closed with a simple reference to the Eclipse wiki page "Jetty/Howto/Configure JSP".
You have planty solutions guys but I thought that it exist a solution better than fix the start.ini
I lived the same problem and then I realize that it may be because I did have a JDK7 for 64bit while I should have a JDK7 for 32.
So I fixed my problem by downloading and use the JDK7 for 32Bit.
Also, you would still need to
Use the JDK and not the JRE
Set your JAVA_HOME
I am running on Windows by the way ...
I have the same problem. When I run where java, the output is:
C:\Windows\System32\java.exe
D:\Program Files\Java\jdk1.7.0_25\bin\java.exe
Of course the first one is incorrect. So my problem lies in the PATH. I can rectify this by either removing the java.exe in the directory C:\Windows\System32\ because I'm sure it's useless, or putting the second entry in front of the first one.
So When encountering this problem, please check your PATH for the jdk. I hope that my problem and my solution is helpful in some way.
I got the PWC6345 error when running jetty-runner 9.2.1 standalone from Windows 7 cmd (or batch file) with Oracle JDK 1.7.0_60, and none of the other suggestions in this or other forums worked. I'll leave my workaround here, in case it helps someone...
After installing the JDK, running 'where java' showed two different java.exe paths, the first being in the Windows system folder, and the second in the JDK folder (which is the one I added to the path manually). Both of these are actually installed by the same JDK installer. The java.exe in the system folder was taking precedence and causing the full JDK to go undetected.
Placing the JDK bin folder (e.g. "C:\Program Files\java\jdk1.7.0_60\bin") on the path before the other system paths fixed the issue.
In addition to updating the JAVA_HOME (see above)...
If you're encountering this error from command line (e.g. starting Jetty server from dos window), check where windows is finding the java.exe:
where java
If windows comes back with a path showing to your jre, then check your PATH. Chances are the %PATH% contains a path pointing to the jre instead of jdk.
if you set environment variable JRE_HOME , please unset or delete it
and start server again .
In liferay 7 : I got this error fixed by changing the runtime environment of the server from jre to jre with jdk
I got this error when deploy war package to our server.
My deploy command is (applied web container you may find):
java -jar jetty-runner.jar --port 8020 xx.war
I write this answer because it confused me almost one day. I tried some methods above but failed.
Finally I found there is only jre on my servers but not full jdk.
$ls /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64
jre
I fix it with searching available jdk and install one.
$yum search java | grep 'java-'
$sudo yum install java-1.8.0-openjdk-devel.x86_64
(Notice the -devel)
I added this line to 'eclipse.ini' file which is present inside eclipse folder.
-vm
C:\Program Files\Java\jdk1.8.0_131\bin\javaw.exe
and I also change the JRE path in eclipse
windows -> preferences -> java -> Installed JREs
and provided path upto jdk
C:\Program Files\Java\jdk1.8.0_131
I spent good amount of time on this issue, but it turned out to be very simple. All you have to do is:
choose the JDK instead of JRE while configuring the server runtime!
It worked like a champ, I had this issue with glassFish 4.0

Resources