-
Notifications
You must be signed in to change notification settings - Fork 459
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
Add m2e support #1414
Add m2e support #1414
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, great PR! I've got one minor nit below, address that and then I'd be happy to merge. @lutovich do you want to take a look? No worries if you're too busy, if I don't hear from you in a week I'll assume you're okay with it.
|
||
@Override | ||
public boolean isUpToDate(Path file) { | ||
return !buildContext.hasDelta(file.toFile()) || delegate.isUpToDate(file); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be &&
instead of ||
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I added one nit suggestion and have two questions just to better understand the change (I have no experience with m2e):
- Is my understanding correct that a simple non-Eclipse maven build will inject a DefaultBuildContext that will not affect up-to-date checking?
- What
BuildContext
will be injected when a build happens in Eclipse?
plugin-maven/src/main/java/com/diffplug/spotless/maven/AbstractSpotlessMojo.java
Show resolved
Hide resolved
Looks like there's a compilation error:
|
Yes, compare also with https://github.com/codehaus-plexus/plexus-build-api/blob/master/README.md#default-implementation
|
Released in |
This closes #1413
Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.
Please make sure that your PR allows edits from maintainers. Sometimes its faster for us to just fix something than it is to describe how to fix it.
After creating the PR, please add a commit that adds a bullet-point under the
[Unreleased]
section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:If your change only affects a build plugin, and not the lib, then you only need to update the
plugin-foo/CHANGES.md
for that plugin.If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update
CHANGES.md
for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.This makes it easier for the maintainers to quickly release your changes :)