Feature/optimize rules specifications artifact

[jycr]

• Removes some warnings in build (see: [ISSUE 92] Centralized rules repository #178 (comment))
  • [WARNING] Duplicated destination found: overwriting file: ... could not currently be fix (issue from asciidoctor-maven-pluginwhich is fixed in future 3.x version)
• Removes metadata for rules not available in corresponding language
• Renames "js" and "ts" languages to "javascript" (see: Standalone SonarQube plugin creedengo-javascript#14 (comment) and Standalone SonarQube plugin creedengo-javascript#14 (comment))
• Removes unnecessary dependencies and plugins

[dedece35]

maybe having a meeting point on this PR to understand all modifications

[dedece35]

Hi @jycr
could you correct biuld / test errors please before all ?

[jycr]

Hi @jycr could you correct biuld / test errors please before all ?

@dedece35 : I think this issue is on SonarCloud side. Isn't it?

Caused by: java.lang.IllegalStateException: Status returned by url [https://sonarcloud.io/batch/index] is not valid: [503]

[dedece35]

Hi @jycr,
sorry again :( but please correct the conflicts :(

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

The version of Java (11.0.20) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

[github-actions]

This PR has been automatically marked as stale because it has no activity for 30 days.
Please add a comment if you want to keep the issue open. Thank you for your contributions!

[utarwyn]

Comparing the jar result with the version before this PR, I get the same result.
So, everything looks good to me 💯 Nice work!

[dedece35]

And I don't know if there is a dedicated CHANGELOG file for the rules specifications artifact?

for me, no the actual CHANGELOG.md is for all modifications of the current repository.
Currently, there are modifiations for java plugin sources and ecocode-rules-specifiacations.
Later, once java plugin source will be on new repository, no problem to continue to fill actual CHANGELOG onely for rules specifications : like that we can see old modifications of this repo.
@utarwyn Not agree ?

[utarwyn]

@dedece35
for me, no the actual CHANGELOG.md is for all modifications of the current repository. Currently, there are modifiations for java plugin sources and ecocode-rules-specifiacations. Later, once java plugin source will be on new repository, no problem to continue to fill actual CHANGELOG onely for rules specifications : like that we can see old modifications of this repo.

I ask this because today the versions are completely different between the Java plugin (1.4.0) and the rules specification artifact (0.0.3). So to track changes in a single changelog it might be more difficult? The idea of having two dedicated changelog files can solve this problem. And we can move the file concerning the Java plugin during the separation

Just a thought like that, it's as you wish 😄

[jycr]

@dedece35
for me, no the actual CHANGELOG.md is for all modifications of the current repository. Currently, there are modifiations for java plugin sources and ecocode-rules-specifiacations. Later, once java plugin source will be on new repository, no problem to continue to fill actual CHANGELOG onely for rules specifications : like that we can see old modifications of this repo.

I ask this because today the versions are completely different between the Java plugin (1.4.0) and the rules specification artifact (0.0.3). So to track changes in a single changelog it might be more difficult? The idea of having two dedicated changelog files can solve this problem. And we can move the file concerning the Java plugin during the separation

Just a thought like that, it's as you wish 😄

Indeed, I publish manually rule-specification under 0.x version.
When all automatic process (Github Workflow) will be OK, we can switch to 2.x version for rules?

[dedece35]

@utarwyn we can indeed create 2 changelog.md files, no problem for me. Maybe it will be clearer for all.

@jycr, for me, before to upgrade version number, I think we have to migrate Java PRs and issues to new repository.
In this repository, it remains only Java language plugin (PHP an python plugins have already been moved to their repository during last summer).
In fact, for java language, there is a lot of PRs and it will be time expensive to migrate one by one to new repository. That's why I reviewed a maximum of them and try to contact commiter to make modifications.
Regarding our internal process, if we have no feedback from commiter within 1 month, I will create a new PR based on commiter PR and will close this last one. Thus, when I will create this kind PR, I think I will initiate the new Java language repository and create each PR into it.

On the other way, I think changing version from 0.0.X to 2.Y doesn't respect best practice on version management. I think we have to go from 0.0.X to 1.0.0 for ecocode rule specifications.

What do you think about it, @utarwyn and @jycr ?

Finally, I try this PR locally with a build and deploy on local docker. When SonarQube starts, I have an error :(
"java.lang.NoClassDefFoundError: org/sonarsource/analyzer/commons/RuleMetadataLoader"

@jycr did you try your PR locally ?

[jycr]

@jycr did you try your PR locally ?

Yes.
But with a fresh LTS install with only java-plugin, I can reproduce the issue.
I will check that!
Thanx

[utarwyn]

@dedece35
I propose to wait for the new Java repository, and after we will be able to create dedicated changelogs in each repository, so the problem will be solved. I agree that the first stable version of the rules specification artifact must be 1.0.0 and not a 2.x.x. We have to move forward because we've been dragging this repo separation out for a long time. I'm in favor of transferring and re-creating needed PRs in the dedicated repository.

BUT I think that the first action should be to integrate this PR in order to process other PRs concerning the rules specification artifact. Some big enhancements in plugins are waiting on this one 😉

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[jycr]

@utarwyn : https://repo1.maven.org/maven2/io/ecocode/ecocode-rules-specifications/0.0.5/
Enjoy ! ;)