RefactorFirst
RefactorFirst copied to clipboard
Report not written if project base directory not same as .git directory
RefactorFirstMavenReport.java has this logic:
if(!projectBaseDir.equals(parentOfGitDir)) {
log.warn("Project Base Directory does not match Git Parent Directory");
stringBuilder.append("Project Base Directory does not match Git Parent Directory. Please refer to the report at the root of the site directory.");
stringBuilder.append(THE_END);
return;
}
Seems this is an assumption that a git repo has only one module - the "project base directory" is the same as the "git directory". Apps with a git repo containing directories of modules won't work with this logic.
Is this a necessary requirement?
Hi @jeffjensen, Thanks for asking. RefactorFirst is able to analyze a multi-module Maven project when the modules are subdirectories in the project, though it is required that the .git directory is in the same location as the pom.xml that is the parent pom for the project. I've used the multi-module project Apache Tobago (https://github.com/apache/myfaces-tobago) to test the analysis on multi-module projects and it works well.
This requirement came about when I was testing with various projects and found that some projects have their parent pom in a different directory than the .git directory exists, leading to a blank report, and I didn't want users to wonder why their screen was blank.
Are you running into an issue when you run RefactorFirst on your project? I'd be happy to investigate the issue if you can describe it or can point out a public repo that exhibits the issue you're experiencing.
Best regards, Jim
Yes, the parent pom for the modules is in a sister directory, not in the parent directory of the modules.
I am very surprised this plugin had a check for git! Does that mean it won't run on products using a different SCM?
Hi Jeff, Thanks for describing your project layout. I will start working on a command line version in the future - it could handle this case gracefully as an argument.
At this time only Git is supported. I wrote a version that supported SVN as a proof of concept a long time ago, so it can be done, but it required that the project's history be generated. My hope is that RefactorFirst can be used without needing to have the user go through much (if any) effort to run the analysis.
Please raise a feature request that your desired SCM be added as an analysis candidate. I'll update the API to be more generic to allow analysis of different SCM repos as a first step. Implementing the feature may be a bit of a different story, though. PRs are always welcome :-)
Thanks, Jim
We're using git. I didn't realize the plugin read git history, thought it did static analysis. Stating this in the README and why is interesting info.
The change I see needed to work with other project structures is not a CLI version but just a plugin config option specifying where the .git dir resides (and allow relative path). And git worktrees present yet a different problem! lol
I wonder how I ever got this to work? The project Im trying to agnosticize happens to be the one with the unconventional parent-child layout.
Bare in mind one can no longer assume the .git directory is always in the worktree directory https://git-scm.com/docs/git-worktree
Yeah, we have a similar problem (using git worktree and not having a pom in the git root). Our workaround for "just inspections" (no CI possible :/): having a fake "uber parent" that just references the actual project as a module and of course using a "real clone" and not a worktree for the report.
Yes, as coded, it is a very narrow use case. Very few (none?) products I'm involved with have the configuration as coded.
Not possible to analyze project in monorepo with structure:
- /multi-module/pom.xml
- /multi-module/library-parent/pom.xml
- /multi-module/microservice-parent/pom.xml
- /multi-module/all-libraries-together-multi-module/pom.xml
- /lib1/pom.xml
- /lib2/pom.xml ...
- /libN/pom.xml
- /microservice1/pom.xml
- /microservice2/pom.xml ...
- /microserviceN/pom.xml