Open phanlezz opened 9 months ago
The motivation for this issue was the sonar importer, which unfortunately currently nests the paths additionally
@phanlezz If that is the main motivation, wouldn't it then be better to work on the sonar importer and not touch the merge? If sonar returns a single root folder and that contains the other stuff:
- root
- - theprojectname
- - - src/
- - - something.else
then instead return:
- root
- - src/
- - something.else
If sonar instead returns
- root
- - anotherfolder
- - theprojectname
- - - src/
- - - something.else
Then return that because there must be some reason.
Wouldn't that solve most problems and be the easiest to implement?
PS: The tokeiimporter has the same problem and could be fixed in a similar way. tokei codecharta -o json > codecharta.tokei.json
and ccsh tokeiimporter codecharta.tokei.json -o codecharta.tokei.cc.json.gz
will return a file with the contents:
root
- codecharta
- - analysis
- - gh-pages
- - visualization
- - package.json
But it would be much better if it returned:
root
- analysis
- gh-pages
- visualization
- package.json
I agree, that the answer to the question, that I asked, is to modify the existing parsers to produce similar structures. After that, we can look into the topic of automatic merging, and if it is something useful to have as a tool.
Path Unification
All modules of the analysis should produces similar paths if possible for the same code. As a user I want to merge a variety of used modules, without modifying paths/roots of files.
The motivation for this issue was the sonar importer, which unfortunately currently nests the paths additionally, but it should be checked to what extent this also affects the other modules.
One approach could be to develop an automatic merge mode that tries to find a lowest common denominator across multiple project files. This mode should allow paths to be matched and folders to be nested correctly without manual input.
A short example:
Open questions
Modify modules or automatic merge
Side note