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

Interferences with checkstyle plugin? #1

Closed
karussell opened this issue Feb 15, 2018 · 4 comments
Closed

Interferences with checkstyle plugin? #1

karussell opened this issue Feb 15, 2018 · 4 comments

Comments

@karussell
Copy link

karussell commented Feb 15, 2018

I really like that you already solved the problem we are facing :) - thanks a lot!

We migrated to this new release style (see commit here but when we add your plugin here the checkstyle plugin has a problem to find its config (which is also an xml):

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (default-cli) 
on project graphhopper-parent: 
Failed during checkstyle execution: Unable to find configuration file at location: 
checkstyle.xml: Could not find resource 'checkstyle.xml'. -> [Help 1]

You can reproduce this with:

mvn clean test verify checkstyle:check

When I look at your code this error does not make any sense but when I exclude your plugin again it builds fine.

@karussell
Copy link
Author

It is somehow the combination of test and checkstyle:check. If I run them separately, it works. Also your plugin seems to touch really just the pom.xml. Strange.

@hbakkum
Copy link
Owner

hbakkum commented Feb 18, 2018

Hi there,

No worries - thanks for using the plugin.

I've taken a look at whats going on in the checkstyle source code. It seems to load the checkstyle config file relative to the modules pom file. This is fine if the pom file is in the same directory as the modules basedir, but my plugin outputs the modules pom file (with properties resolved in the version element) into the target directory. IMO the checkstyle plugin should be loading the config file relative to the modules basedir (which never changes) rather than (or in addition to) the pom file dir. I'll raise an issue (I'll update this thread with a link once done) against the checkstyle plugin and see what they say.

In the meantime, there are probably two reasonable workarounds.

First would be to prefix your checkstyle.xml path with the ${user.dir} property (which resolves to the dir the maven executable is being run from), e.g.

<configLocation>${user.dir}/core/files/checkstyle.xml</configLocation>

This does have the rather annoying downside that you can only run maven from your projects parent pom directory, i.e. you could not run a maven build from a submodule as the checkstyle.xml path would then be wrong.

The other option would be to set a property in every pom file, ${root.dir}, that points to your parent poms basedir.
For example, in your parent pom you would have:
<root.dir>${project.basedir}</root.dir>

And each of your submodules would have:
<root.dir>${project.parent.basedir}</root.dir>

And finally your checkstyle config location would be:
<configLocation>${root.dir}/core/files/checkstyle.xml</configLocation>

Hopefully one of those workarounds is acceptable. I'll need to think on this some more to see if there are any better solutions. Although I suspect without a change to the checkstyle plugin loading config relative to the basedir rather than pom dir we may be left with only these options.

Cheers,
Hayden

@karussell
Copy link
Author

Thanks a lot for your time, explanation and investigation!

downside that you can only run maven from your projects parent pom directory

This is not a problem at the moment, so I'll try this.

karussell added a commit to graphhopper/graphhopper that referenced this issue Feb 18, 2018
@karussell
Copy link
Author

karussell commented Feb 18, 2018

Nice, works and fixes another problem I had with the previous workaround :) - thanks again!

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

2 participants