I ran into the error while starting the rsocket-cli:
The full log is here.
I did everything according to the README.md, but I got this error at the first step. It's the ./gradlew --console plain installDist.
What's the most interesting in the code this error looks like this:
I'm not sure but probably it can be important. I'm using the Shell: zsh 5.8.
rsocket-kotlin has a snapshot build, and due a 0.13.0 build sometime soon. It seems like the current TCP refactor relies on internal API.
I've raised https://github.com/rsocket/rsocket-kotlin/issues/163
In the meantime if you want websocket support I'd comment that out.
Also there is a rsocket-java CLI you can use if this is still blocking you https://github.com/making/rsc
Apologies and thanks for flagging.
Related
is it possible to get the results of a SonarQube analysis displayed in the JavaConsole?
For example, I installed SonarQube in Java/Maven. I can analyze my program and it uploads the results to localhost:9000. But can I get the number of "code-smells" or "bugs" in my console from the project when it got uploaded to localhost:9000?
I tried smth with
HttpGet httpGet = new HttpGet("http://localhost:9000/api/issues/search?pageSize=500&componentKeys=CODE_SMELLS");
But it seems like it does not work?
I tried to use the web/API but I don't understand the documentation. For example
web_api/api/measures
I don't know how to actually use it in the code I can not find an example or which method or so I have to use, to use the API.
Can someone maybe provide some example code or pseudocode for Java how I could retrieve results from the analysis?
I am fairly new to SonarQube and how to work with an API. So sorry about that.
I am using the newest SonarQube free edition, maven and IntelliJ
If you've installed the sonarlint plugin you get the lint tab next to console and terminal. Ctrl+Alt+s or Ctrl+Shift+s on your project at root and that will produce the results
On http://localhost:9000/api/webservices/list I could find all possible services and parameters.
This helped me a lot, for example:
http://localhost:9000/api/issues/search?componentKeys=myProjectKey&facets=types&facetMode=count
We encounter a strange error with Jenkin today. After investigating, we find that it's due to the fact that we delete some files in SVN, which cause a problem in Jenkin SVN plugin.
As I investigate, it seems this bug was known but it hasn't been fixed yet. So that upgrading to a newer SVN plugin version is not a solution(we are using Jenkin 1.474).
Our temporary fix is that "always checkout before building". But this is clearly very slow and takes much time for big projects. So that I'm looking for a way to (at least) detect the SVN problem in post-build scripts when it happens, and probably send an email to notify the developers.
Does anyone have any experience with this? I'm not too familiar with Jenkin, hence any help or pointer would be greatly appreciated.
Here's the error log:
Building in workspace /workspace-directory/workspace
Cleaning up /var/lib/jenkins/jobs/aaa/workspace/.
Deleting /var/lib/jenkins/jobs/aaa/workspace/logs
Deleting /var/lib/jenkins/jobs/aaa/workspace/target
Updating svn://address/trunk#HEAD
U src/main/some_file.java
D src/main/another_file.java
U src/main/other_files.java
ERROR: Failed to update svn://address/trunk#HEAD
org.tmatesoft.svn.core.SVNException: svn: E155017: Checksum mismatch while updating '/var/lib/jenkins/jobs/aaa/workspace/src/main/address/.svn/text-base/StudioSignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:85)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:69)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.driveEditor(SVNEditModeReader.java:250)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.update(SVNRepositoryImpl.java:1503)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath.act(FilePath.java:842)
at hudson.FilePath.act(FilePath.java:824)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1245)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1488)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E155017: Checksum mismatch while updating '/xxxxx/.svn/text-base/SignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.textDeltaEnd(SVNUpdateEditor15.java:637)
at org.tmatesoft.svn.core.internal.wc.SVNAmbientDepthFilterEditor.textDeltaEnd(SVNAmbientDepthFilterEditor.java:221)
at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.textDeltaEnd(SVNCancellableEditor.java:130)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.processCommand(SVNEditModeReader.java:176)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.driveEditor(SVNEditModeReader.java:232)
... 29 more
Caused by: svn: E155017: Checksum mismatch while updating '/xxxx/.svn/text-base/SignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.textDeltaEnd(SVNUpdateEditor15.java:634)
... 33 more
no change for svn://some_address/trunk since the previous build
No emails were triggered.
We have occassionally seen the problem with some builds, but we normally just clear the workspace and then rebuild. (From Jenkins, Navigate to the job, then "Workspace".)
There are a couple of different plugins that may help with detecting and possibly actually taking some actions based on the issue.
Warnings Plugin - parses the console output and looks for built in and user defined patterns that it reports as Warnings.
Log Trigger Plugin - triggers downstream jobs if a specific trigger is found in the console log. (Perhaps have an SVN "clean-up" job that is triggered?)
Of these, I have only used the Warnings Plugin myself.
These threads from Jenkins JIRA and JetBrains are interesting:
https://issues.jenkins-ci.org/browse/JENKINS-14550
http://youtrack.jetbrains.com/issue/IDEA-83673#comment=27-379397
As you mentioned, the issue remains open in Jenkins. JetBrains believe they have corrected IDEA with the updated svnkit: svnkit 1.7.5-v1.
Also noted in the jetbrains issue are some strategies to fix the issue using the commercial tool SmartSvn, an svn client which has a special feature "Validate Admin Area".
I am going to try to update the Jenkins JIRA issue with a note about the svnkit to see if that results in a fix.
EDIT:
Actually, it looks like the January Jenkins Subversion plugin, 1.4.5, takes care of this issue. After installing and manually re-starting, the mismatch went away.
I have developed a little program for myself. After testing and
finishing it locally I now wanted to put it on my server.
I get this error:
Compilation error The file /app/controllers/Links.java could not be
compiled. Error raised is : Secure cannot be resolved to a type
It is thrown at this line:
#With(Secure.class)
In the Class Links I have:
import play.mvc.With;
import controllers.*;
#With(Secure.class)
public class Links extends CRUD {
}
I have installed play 1.2.2 on my server. Play is running probably. I
type in the terminal "play start appname" and opened serverIp:9010 to
see this error. If I type "play precompile appname" everything seems
to work.
In the subfolder /modules of the app I have two text files, one "crud"
and one "secure" which point to the modules location on the server. I
also have defined the modules in dependencies.yml like this:
require:
- play
- crud
- secure
In the application.conf I have a Production definition for my server
with the proper Server-ID like this:
%server1.application.mode=PROD
Any idea why this isn't working?
I have solved it. For future reference:
I had an old process of play running. Found it with ps -aux and then kill PID. After that I started the application again with play start.
It's now running fine :)
Thanks for you help!
Declaring the secure module in dependencies.yml file is the first step.
Next you have to type the shell command "play dependencies" in order to resolve them.
Just have a glance on the documentation here : http://www.playframework.org/documentation/1.2.2/dependency#Theplaydependenciescommand
Have fun with Play!
Sometimes you have to refesh the classpath settings by using play eclipsify again. (depends on the IDE you are using)
I had to insert this line to application.config
module.secure=${play.path}/modules/secure
I had the same problem in my development environment, but not in my production server. I tried to solve by the module documentation, the accepted answer here, and many others with no success.
My solution was to download again play framework (1.2.7) and replacing it in the path where I installed first.
Hope this can guide someone else with the same issue.
Regards.
I am trying to be able to step through the code of a Hudson plugin called SVNPublisher. I checked out the code for SVNPublisher, used Netbeans to open the project, and clicked "Debug Main project". This results in a Firefox window opening address http://localhost:8080 which shows the Hudson main page. Clicking the "New Job" link results in an error page:
HTTP ERROR: 500
jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: <j:forEach> hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
RequestURI=/newJob
Caused by:
org.apache.commons.jelly.JellyTagException: jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:713)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
...
I am very new to Hudson and not very experienced with Java so I'm pretty much clueless on the meaning of this error.
Can anyone help?
I know this thread is v. old but I have just had this issues and wanted to help anyone else who has is.
I found I got this issue when I had a DescriptorImpl in a class (this is a sub-class of the main class). In my case this is ResourceAxis contains DescriptorImpl.
I started getting this issue when I renamed DescriptorImpl to ResourceDescriptorImpl. Then I started getting the following error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl.<init>(ResourceAxis.java:94)
This propted me to change ResourceDescriptorImpl back to DescriptorImpl - as it was complaining about DiscriptorImpl. At that point I got this error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl.<init>(ResourceAxis.java:94)
This one is complaining about ResourceDescriptorImpl. I realised I was not doing a Clean build each time and that the old compiled code might be causing issues (as I only change one class, so the other may not be re-compiled). If you see this issue try doing a clean build and see if that solves your issue.
Hope this helps.
I'm running into the same issue and unfortunately I haven't been able to resolve it yet either. As VonC mentioned it may have to do with a change in how generics are used between 1.5 and 1.6, this is problemaitc since even if you install a 1.5 version hudson requires 1.6 to build and run via hpi:run.
What I have noticed is that if you install hudson locally (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson#MeetHudson-TestDrive) you can use a maven install command to generate an .hpi file of the plugin and install that. I don't get the same error when I do that which makes me think it could be an issue with the hpi:run goal. That should at least let you test any changes you need to make.
Coincidentally I'm the author of that SVN Publish plugin if there are any questions you have. I haven't made any changes recently, but I found this thread because I have some in the works and ran into this issue ;)
Thanks,
Brent
While compiling my project I get:
The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
at com.sun.tools.javac.code.Type$WildcardType.isSuperBound(Type.java:435)
at com.sun.tools.javac.code.Types$1.visitWildcardType(Types.java:102)
at com.sun.tools.javac.code.Types$1.visitWildcardType(Types.java:98)
at com.sun.tools.javac.code.Type$WildcardType.accept(Type.java:416)
at com.sun.tools.javac.code.Types$MapVisitor.visit(Types.java:3232)
at com.sun.tools.javac.code.Types.upperBound(Types.java:95)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2977)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2977)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2977)
at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
...
How do you find the root of the problem?
I have found a bug report...
The bug report you linked to indicates that the bug was fixed in JDK 6. Which version of the JDK are you using to build?
If you can't identify the part of your source that is causing the problem, perhaps you could try compiling with JDK 6 to see if it can identify the problem without crashing.
Otherwise, I would use the "divide and conquer" approach: Remove half your source code, compile, and see if it still crashes. Depending on whether it does or not, you will know which half the problem is in. Repeat.
I would start by running javac with the -verbose option to see which .java file was causing the problem.
What about trying a different compiler, like the one in Eclipse? It's error messages are at least different, in my experience often more to the point. Also I haven't seen compilation failures like this yet.