As with "normal" issues it should be possible to create external issues that belong to the project instead of a single file.

There are cases where an issue can not be assigned to a location in a file. E.g. because it is not known where the issue occurred, e.g. when fuzzy testing the application.

Instead of using a SELECT to fetch sequence #, assign value directly from the sequence; it would lower cursor usage for people with tight DB restrictions and could improve performance by up to 50% based on this: http://oracle-base.com/articles/11g/plsql-new-features-and-enhancements-11gr1.php#sequences_in_plsql_expressions.

However it would only be compatible with Oracle 11g and up, but Oracle 10g (even R2) was dropped from even extended support for almost 2 years. If support for Oracle 10g must be kept, perhaps a support for specific dialects like "Oracle9g", "Oracle10g", "Oracle11g" and "Oracle12c" would be necessary (a bit like Hibernate does although they stopped at 10g).

This PR adds a component that wraps around the ActiveRecord based migration process and handles concurrency as well as asynchronous execution of it

this will be called from the new WS to trigger DB migration (another PR)

Sorry this PR is a little bit dense, but individual commit do not really make sense

In some cases when Sonar's Analysis Report is big enough, the upload process is failing with a Session timeout error. This happens on big multimodal projects when analysis reports more than 1Mb. Given that nowadays=, many IT people working from home and the connection bandwidth varies a lot, in many cases, the default 10-sec write timeout inherited from OkHttp is not enough.

This change is only about excessive warnings in the console. We have thousands of these comments in our project because we have a certain folder that is shared between projects.

Even when I exclude the unnecessary files with Sonar, this continues to Log them.

this PR introduces the concept of module as a group of components this will allow reducing length of the ComponentLevel classes and in the near future implement lazy start of components and/or description of implicit component dependencies this PR also includes a few module to demo usage and as a proof-of-concept

This PR :

• changes the WS response to use a root object so that the response can be easily extended in the future (best practice)
• adds more properties to the WS response for each plugin

this PR adds the new WS server/migrate

IT tests coming up as soon as I know how they are supposed to be written

this PR is based on branch feature/add_db_migration_from_java reviewed with PR #197

On my machine this change decreases time of execution of web tests on 68%, which is 43% for build of web module and 8% overall as shown below.

$ uname -p -m -o
x86_64 Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz GNU/Linux

Before:

$ time mvn clean install -pl server/sonar-web
[INFO] Casper Task 'casper:test' took ~67805ms to run
real    1m46.001s
user    1m7.538s
sys     0m2.216s

$ time mvn clean install
real    8m23.034s
user    9m17.843s
sys     0m20.167s

After:

$ time mvn clean install -pl server/sonar-web
[INFO] Casper Task 'casper:test' took ~21746ms to run
real    1m0.827s
user    1m15.891s
sys     0m3.304s

$ time mvn clean install
real    7m40.100s
user    9m52.647s
sys     0m22.536s

I'm not a JavaScript expert, but seems that there is no problem of isolation of tests. At least I did not observed spontaneous failures among 20 sequential runs.

Default value of "concurrency" level (5) seems good enough - on my machine higher values do not provide further decrease of time.

Hi,

To me, correction of ticket SONAR-13328 seems buggy. It only checks HTTP header X-Forwarded-Proto but behind a reverse proxy hostname is frequently changed too and header X-Forwarded-Host could be sent.

If Sonarqube is installed behind a reverse-proxy, I think it's better to customize Tomcat than hack incoming HTTP request (https://tomcat.apache.org/tomcat-9.0-doc/proxy-howto.html).

So in this PR I add 3 new properties to configure RP :

• sonar.web.proxyName : reverse proxy hostname
• sonar.web.proxyPort : reverse proxy port
• sonar.web.scheme : reverse proxy incoming scheme

When this properties are filled, Tomcat will return information about the original HTTP(S) request when getRequestURL() is called (by SamlResponse for example).

This PR allows processing of files in aggregator modules. When analyzing a multi-modules maven project, this allows the root pom to be indexed and analyzed. It should also be beneficial to other project types (Gradle was mentioned in SONAR-6724). This only applies to files, not folders : SONARPLUGINS-2295 introduced a warning for existing folders referenced in property sonar.sources of aggregator modules : it will still be displayed, and these folders will still be ignored.