Using Gradle and the gradle-gae-plugin debug parameters are not passed - gradle

I'm using gradle to build, run, deploy my Google App Engine project. The gradle-gae-plugin (version 0.4) seems to work perfect with one caveat. The debug parameters are never passed to the local running engine during gaeRun.
I've changed the http port, so I see at least one parameter taking effect. However, my IDE is rejected on the default 8000 debug port, and netstat shows nothing listening on 8000.
Here is the gae closure from my build.gradle:
gae {
httpPort = 8888
debug = true
debugPort = 8000
}
And the informational log statement coming out of GaeRunTask.groovy of the gradle-gae-plugin
[INFO] [org.gradle.api.plugins.gae.task.GaeRunTask] Using params = [com.google.appengine.tools.development.DevAppServerMain, --port=8888, /[project-dir]/war/build/exploded-war]
gradle version
------------------------------------------------------------
Gradle 1.0-milestone-3
------------------------------------------------------------
Gradle build time: Monday, 25 April 2011 5:40:11 PM EST
Groovy: 1.7.10
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.6.0_23 (Sun Microsystems Inc. 19.0-b09)
OS: Linux 2.6.38-8-generic amd64

This is because version 0.4 does not support the debug flag yet. I am currently working on version 0.5 and had already checked in the changes for the README.md file on master. Please refer to tag v0.4 for available convention properties in version 0.4. I will probably push the next version within the upcoming week. As soon as I do I will let you know.

Related

Sync error while trying to build project in IntelliJ

Getting the following sync error while trying to build my first helloWorld program in IntelliJ.
I've installed IntelliJ for the first time on my computer running Windows 10.
Could not open init generic class cache for initialization script 'C:\Users\nikhils\AppData\Local\Temp\wrapper_init5.gradle' (C:\Users\nikhils\.gradle\caches\6.6.1\scripts\2xaig2b083uxqwleg0fdntova).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 60
Change project and Gradle JDK to the supported version (8—15). Current Gradle release versions do not support Java 16. You would need Gradle 7 if you want to use Java 16.
The easiest way would be to create a new project with Java 11.
Also note that full Java 16 support will be available starting from IntelliJ IDEA 2021.1 release (current release version is 2020.3.3).
See https://www.jetbrains.com/idea/nextversion/ if you want to give it a try.

IntelliJ IDEA 2019 no longer terminates previous process on run

I have a Kotlin/JVM Gradle project that I'm working on in IntelliJ IDEA CE.
I unchecked Allow parallel run on my "Application" Run Configuration, so that IDEA would only allow a single instance of my process. I got used to the behaviour where after I press Run, the previous process is terminated before the new process is launched.
Today, I upgraded from 2018.3 (maybe?) to 2019.1.1 (details below[0]), and even though that checkbox is unchecked, every time I press run it launches a new process. The new process always quits immediately because it binds to the same port as the first process, which is still running. I need to quit the old process(es) manually.
My project is unmodified; the only thing I did was upgrade IntelliJ using the upgrade prompt when I launched it today.
When I hit run, I want the old process to quit first so it doesn't conflict with the new one. How do I get this behaviour back?
[0]:
IntelliJ IDEA 2019.1.1 (Community Edition)
Build #IC-191.6707.61, built on April 16, 2019
JRE: 1.8.0_202-release-1483-b44 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.3
IntelliJ IDEA 2019.1 delegates build and run actions to Gradle by default. With the delegation enabled, some options from the run configurations have no effect.
The solution is to disable the build/run delegation in File | Settings | Build, Execution, Deployment | Build Tools | Gradle | Runner:
In IntelliJ 2020 the gradle settings look like this, set all to IntelliJ IDEA:

Incorrect Java coverage analysis result when executing the analysis via Jenkins

We run Sonar coverage analysis for multi-module Java projects in a Jenkins environment using the sonar-maven-plugin. We noticed that the coverage analysis results displayed on our Sonar dashboard are not correct for a handful of source files. One odd finding from my investigation is that I when I run the analysis from my local development laptop, the coverage analysis is correct (Sonar dashboard updated with the correct coverage percentages for those source files). Has anyone encountered any issues like this before?
Clarification:
The differences in the coverages are mostly between 0 and non-zero percent coverage. But I also see a couple of instances where the difference is between non-zero and non-zero percent coverage. Also, the differences correspond to source files from random packages, not any specific package. We are encountering this issue across various Sonar projects as well (so not just an issue specific to one of our Sonar project).
Also, when I import the Jacoco exec data file into Eclipse (using eclemma plugin), I do see the correct coverage percentages (non-zero). Furthermore, the coverage result when running the analysis locally can also be incorrect when compared with the result as interpreted by the EclEmma plugin). So, now it seems the analysis results may be incorrect regardless of which environments I run the analysis from (assuming the analysis result from EclEmma is correct).
Not sure why the coverage results is wrong only for a handful of the source files. I have compared both the client-side console logs and server side (Sonar server) logs -- but did not find any clues (no indication of error, both analysis were successful). I have also compared the coverages-xxx.pb files' sizes from the batch-report folder, but did not find any differences either.
Thanks in advance to anyone with suggestions on how I can troubleshoot this further! Please let me know if any additional information regarding the execution environments would be helpful.
Thanks,
Thinh
SONAR ENVIRONMENT:
- sonar-maven-plugin version: 3.3.0.603
- SonarQube version: 5.6.6
- sonar.java.source: 1.8
- sonar.java.target: 1.8
- sonar.sourceEncoding: UTF-8
SonarQube plugins:
- Findbugs 3.5 (findbugs)
- SonarJava 4.11.0.10660 (java)
- Git 1.2 (scmgit)
JENKINS ENVIRONMENT:
- Jenkins version: CloudBees Jenkins Enterprise 2.46.3.2-rolling
- Maven version: 3.1.1
- Java version: OpenJDK 64-bit Server 1.8.0_141
- Slave OS: 64-bit, CentOS (Red Hat 4.4.7-11), Linux version
2.6.32-504.12.2.el6.x86_64
LOCAL LAPTOP ENVIRONMENT:
- Maven version: 3.1.1
- Java version: Java HotSpot(TM) 64-Bit Server VM
(build 1.8.0_60-b27)
- OS: macOS Sierra, version 10.12.5

Can not resolve directory "node_modules" in PhpStorm with Laravel Project

PC:Windows 10 V1607.
PhpStorm 2016.3.2
Build #PS-163.10504.2, built on December 20, 2016
JRE: 1.8.0_112-b15 amd64
JVM: Java HotSpot(TM) 64-Bit Server VM by Oracle Corporation
I have already mark "node_modules" as Resource Root in setting.
I have cleaned the IDE (PhpStorm) cache and reindex files.
resources/assets/sass/app.scss which was built with Laravel still get the inspection "can not resolve the directory "node_modules"".
// Bootstrap
#import "node_modules/bootstrap-sass/assets/stylesheets/bootstrap"; // can't resolve the directory by IDE.
Mark project root as Resources Root in File->Settings->Direcotries.
If you want to locate the uri in your blade, mark your project/public as Resources Root too.
Hope it could help.
Thanks #patricus
I have received Phpstorm team's same answer about that, and strong recommend to use Jetbrains' JDK instead of Oracle's.
So it is necessary to switch to Jetbrains' JDK build instead of Oracle by following these steps:
1.Go to File | Settings | Plugins > Install JetBrains Plugin
2.Find and install JB SDK Bintray Downloader plugin
3.After the restart, press Ctrl+Shift+A or Help > Find Action
4.Type in "Get JB SDK from BinTray" and press Enter
5.From the list select the latest JDK build - at this moment it is jbsdk8u112b676_windows_x64.tar.gz (2017-01-13)
6.Press download, then press Install after it will finish
7.After a restart check that JVM vendor and JRE version are updated in Help > About screen

Sonar-runner fails due to missing cxx-language plugin, although installed

I am very new to Sonar and in the process of setting up my first server/project.
Environment:
OS: Windows Server 2008 R2 / amd64 / 6.1
App Server: Tomcat/7.0.40I, deployed the Sonar WAR file (3.5.1).
DB: MySQL 5.6.11
(relevant) Plugins:
Sonar C++ Community Plugin (0.2)
The plugin is visible under General Settings --> Sonar C++ Community Plugin
sonar-project.properties
# Required metadata
sonar.projectKey=test:pmc
sonar.projectName=PMC
sonar.projectVersion=1.0
sonar.language=c++
# Comma-separated paths to directories with sources (required)
sonar.sources=c:/SVN/Development/test/PMC/trunk/AppServer,c:/SVN/Development/test/PMC/trunk/PmcShared,c:/SVN/Development/test/PMC/trunk/WebServer,c:/SVN/Development/test/PMC/trunk/Tools
# Optional path to the CppCheck program required to activate some CppCheck rules
sonar.cpp.cppcheck.path=C:/Program Files (x86)/Cppcheck/cppcheck.exe
# Encoding of the source files
sonar.sourceEncoding=UTF-8
The thing I do not understand is that it cannot find a plugin that supports the 'cxx' language:
C:\Users\Administrator\Documents\sonar-projects\PMC>sonar-runner
C:\Users\Administrator\Documents\sonar-runner-2.2.1
Sonar Runner 2.2.1
Java 1.7.0_21 Oracle Corporation (64-bit)
Windows Server 2008 R2 6.1 amd64
INFO: Runner configuration file: C:\Users\Administrator\Documents\sonar-runner-2.2.1\conf\sonar-runner.properties
INFO: Project configuration file: C:\Users\Administrator\Documents\sonar-projects\PMC\sonar-project.properties
INFO: Default locale: "en_US", source code encoding: "UTF-8"
INFO: Work directory: C:\Users\Administrator\Documents\sonar-projects\PMC\.sonar
INFO: Sonar Server 3.5.1
15:20:54.231 INFO - Load batch settings
15:20:54.794 INFO - User cache: C:\Users\Administrator\.sonar\cache
15:20:54.797 INFO - Install plugins
15:20:55.742 INFO - ------------- Executing Project Scan
15:20:56.482 INFO - Install JDBC driver
15:20:56.487 INFO - Apply project exclusions
15:20:56.493 INFO - Create JDBC datasource for jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
15:20:56.771 INFO - Initializing Hibernate
15:20:59.229 INFO - ------------- Inspecting PMC
15:20:59.229 INFO - Load module settings
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 6.162s
Final Memory: 13M/221M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: You must install a plugin that supports the language 'cxx'
ERROR:
ERROR: To see the full stack trace of the errors, re-run Sonar Runner with the -e switch.
ERROR: Re-run Sonar Runner using the -X switch to enable full debug logging.
I do have the Sonar C++ Community Plugin installed so I guess I am missing the obvious...could someone please help me getting started?
It seems I made a mistake in the configuration file. I re-created it and now the job runs! This issue is closed and the configurations above will work.
I had a similar error with the C# plugin:
ERROR: Caused by: You must install a plugin that supports the language 'cs '
Please remark the 'cs '
After long time I spotted the extra ' ' after 'cs'. When removing the extra space in the configuration file it worked. It seems like sonar-runner don't use "trim".
For new users, if you still getting this error (SonarQube 4+) start the server, go to the 'Settings' ( top right ) then search for 'Update center' there you add missing modules , next restart Server. it should works
Source: Link from official project website
To find the string required to activate any given SonarQube language plugin, go to "Settings" -> "System" -> "Update Center". For each plugin, the short name will be in square brackets to the right of the human-readable name.
C / C++ / Objective-C [cpp]
In this example, "cpp" is the name to use in the sonar.language property in your sonar-project.properties.

Resources