Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report not written if project base directory not same as .git directory #33

Open
jeffjensen opened this issue Nov 15, 2021 · 8 comments

Comments

@jeffjensen
Copy link

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?

@jimbethancourt
Copy link
Collaborator

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

@jeffjensen
Copy link
Author

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?

@jimbethancourt
Copy link
Collaborator

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

@jeffjensen
Copy link
Author

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

@delanym
Copy link

delanym commented Feb 2, 2023

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

@rkraneis
Copy link

rkraneis commented Mar 1, 2023

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.

@jeffjensen
Copy link
Author

Yes, as coded, it is a very narrow use case. Very few (none?) products I'm involved with have the configuration as coded.

@SimSonic
Copy link

SimSonic commented Jul 5, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants