Add Main class exists rule #35
Merged
+343
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is actually what happens when the pom doesn't have this property
Member
|
Thanks for implementing this, @gselzer! Do you think it would be worthwhile to check that the given class not only exists, but actually has a |
Member
Author
Certainly couldn't hurt... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new custom enforcer rule that asserts that either:
main-classproperty exists (this would actually show up as a key with a blank value)main-classproperty refers to an existing class file.The intent behind this rule is to catch the situations where a POM is copied and the developer who doesn't know any better (historically me) just changes the package structure of this property without actually making the class. It's been tested on the scijava/scijava repository, and seems to be working.
Note that this rule differs from the existing rules in that it does not use the deprecated
org.apache.maven.enforcer.rule.api.EnforcerRule. Let me know if that's an issue! We could always refactor the other rules into the new classes in another PR (there seems to be no issue with using both old and new patterns simultaneously)