Plugin fails on clean source repository

[jcamerin]

I have run into this issue due to the development teams desire to run analysis as the first step in a pull request build on Jenkins. I am also able to replicate this on my local machine to help me refine the scenario down to exactly these steps to reproduce. In my repository, I run mvn clean to replicate the state from the Jenkins build where a clean checkout is done. Run mvn codenarc:codenarc to perform the analysis. I get an error from the plugin: An error has occurred in CodeNarc Report report generation.: /Users/john.camerin/Projects///target/log4j.properties (No such file or directory)

If I simply create the target folder in that module, the codenarc analysis runs successfully. This is simple enough workaround on a small project on my local machine. However, for Jenkins builds on complex enough projects where the structure may change, this workaround is not a solution.

The plugin should create the required target folder if it does not exist.

I am using this plugin in my maven build:

org.grails.plugins

                <artifactId>codenarc</artifactId>
                <version>1.5</version>

NOTE: This also occurs with the maven plugin below, but given how outdated it is, I thought I would get more support if I used the grails plugin.

org.codehaus.mojo

                <artifactId>codenarc-maven-plugin</artifactId>
                <version>0.22-1</version>

[chrismair]

Apologies for the late response. I don't yet understand where that error message is coming from, or why it would reference "log4j.properties", or where the '///' comes from in that path. And I have to admit not having any experience with running this plugin through Maven.

But perhaps a workaround is to explicitly define the report file path (outputFile), and have it be within a directory that already exists.

[chrismair]

For what it's worth, CodeNarc itself already creates the report folder using outputFile.getParentFile()?.mkdirs().

Is it possible that somehow the outputFile config is being set to that "log4j.properties" file with the '///' path? That might explain why it gets an error trying to create that file.