Rename parent folder following maven convention

[glalloue]

Hi,

I'm look since few weeks the project and i have identified a recent renaming that i'm not agreed. I'm hoping my remark will be accepted/appreciated :)

You are using maven structure. The parent folder src is not appropriate. By convention, we're expected a pom together with a src folder. And inside the pom, we are expected a ProjectName or Artifactid equal to the name folder (WYSIWYG). More info and schema expected : wikipedia Maven

It will be more efficiency to rename as "ecocode" the src parent folder or any suggestion idea you have in mind. :)

Originally posted by @Silicoman in https://github.com/cnumr/ecoCode/discussions/72

[cyChop]

This should apply to modules as well. Right now, the folder names and artifactIds of modules are not aligned.

[dedece35]

hello, I'm agree with observation and I have been surprised to see this directory structure and pom.xml content. "ecocode" name is already used by the git project. Thus, I don't think this is a good idea to rename "src" directory to "ecocode" ( because we will have a "ecocode/ecocode" structure :( )

I think, we have to rethink the directpry structure but if we want smallest possibles impacts, indeed, the simplest way is to rename "src" directory : I suggest "dev" or "src-code" or anything else that suggests this directory contains source code.

Longer term, I think source code must be in root directory (as mentionned in maven guidelines) and some others directories for documentation, installation files, deploy files (for example : final plugin JARs should be in a "target" directory instead of "lib" directory if we want to follow maven guidelines). We have to discuss about it.

[dedece35]

an idea of code architecture

[jhertout]

I just want to indicate that the plugin-android scans 3 languages: java, xml, groovy and will support kotlin in the futur. I am not sure the "language" entry point is the best. The same is true for "plugin-ios" which could have several language in it.

If we abslolutly want to reorganize the repo, for the moment I think that "plugin-ios" and "plugin-android" should be at the same level as the web languages plugins "plugin-php"...

An other point is that in the "android-plugin" we do not work at the "language" level like in the "plugin-java" for example but at the API level (we are looking directly for bad usage of methods in the Android Bluetooth API for example). I think that it may happen in the web plugins if for example we decide to work on a "plugin-django" or a "plugin-reactjs" (It is just for the example :) ). The approach is different from the classical "language" approach of SonarQube but I think that it is necessary since (in Android at least) the true eco-conception problems came from the API.

[MP-Aubay]

Hi,

@dedece35 : I think we can remove javascript from plugin (maybe typescript too ?), I don't remember exactly, but during hackaton we see that Sonar Javascript plugin was outdated and deprecated, and linter should be use. @jhertout We should use https://github.com/cnumr/ecoLinter for JS / typescript ?

Maybe android and ios should be at the same level as "web languages plugins", but I don't know them well yet.

But, from my point of view, it is a mistake to create module / plugin like "plugin-django", we cannot create a plugin for each framework existing, for example in java we would have plugin-spring, plugin-jakartaee, plugin-quarkus, ... I don't say to not cover this framework, but rules should be in language plugin and we can add a tag to identify them.

From what I know of Sonar, it identifies language based on file extensions (or a smarter process ?), then using project or default profile containing set of rules. If a rule concerning a specific framework (as Spring) is in this profile and the analyzed project don't use this framework, the rule will be checked but not found as class and configuration did not match. The only bottleneck I see is if class naming collide between framework.

About architecture, @dedece35 another point to keep in mind is that each language plugin is a kind of fork of sonar-plugin, for exemple for java (spec here https://github.com/SonarSource/sonar-java/blob/master/docs/CUSTOM_RULES_101.md), we fork this module https://github.com/SonarSource/sonar-java/tree/master/docs/java-custom-rules-example from sonar-java plugin.

If we want to keep updated maybe we should used the sonar-java plugin as parent ?

Just my thought on this subject, not having time to work on this yet

[dedece35]

@MP-Aubay @jhertout My draw is just for initiate the discussion but I'm Ok that we must have a live internal discussion to talk about it.

@glalloue could you organize it and see who wants to participate to this live meeting ?

[jhertout]

@dedece35 I agree that we must reorganize the architecture of the project. I just write the reflections we have when working on Android. I am not sure it can be applied to web plugins too ;)

I agree that a live discussion will be more efficient on that subject.

[dedece35]

discussion in progress in core team