-
Notifications
You must be signed in to change notification settings - Fork 47
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
move extra enforcer rules code from org.apache.maven.plugins.enforcer package to a non-Apache package #12
Comments
IIRC @stephenc created this project originally, and though I didn't check the commits I'd say this was done on purpose to be able to just use directly the rule name with the class name. And maybe also because the plan could be to try and move the successful rules to official Apache Maven's enforcer rules repo? |
The plan was to simplify usage (which you get with the "magic" package name) and migrate the successful ones to ASF (hence the code being ASL licensed) I'm -1 on changing the package name, rather let's get the good ones over to ASF Sent from my iPhone
|
I'm not an enforcer code expert: if putting code in Apache Maven package is the only way of having usable rule names, I think enforcer needs a new feature to look for simple rule names in multiple packages this is independant from the good idea to move some rules to ASF if they are good (like enforce bytecode...) |
It's modello that makes the package name requirement. Sent from my iPhone
|
Modello? imposing some constraints on class loading scheme? I'm surprised. Can you elaborate, please? |
The classes in extra-enforcer are already in org/apache/maven/plugins/enforcer package...so no need to change the package name. |
Sorry, brain-fart, it was plexus configuration which by default uses the same package name as the generic type being injected Sent from my iPhone
|
@khmarbaise extra enforcer is not Apache: should not require to put classes in org/apache/maven/plugins/enforcer but in its own package: makes things more clear |
@hboutemy let's just see what rules are worthy of moving to ASF and then do the move. They are all ASL so should not be an issue |
moving some extra enforcer rules to Apache Enforcer won't change the problem with remaining ones: having extra-enforcer classes in same package than Enforcer itself is misleading |
problem is indeed plexus configuration, otherwise you need to add the implementation="path.to.the.Pojo" as attribute to the tag in case of a List. It would be nice if generics would be respected. |
The extra-enforcer-rules need to be included as a dependency to the maven-enforcer-plugin, maybe the maven-enforcer-plugin could scan it's direct dependencies for classes implementing EnforcerRule? Or would parsing the POM already choke due to the plexus configuration mentioned by @rfscholte? |
https://issues.apache.org/jira/browse/MENFORCER-367 issue reported to Maven Enforcer - even for me package name was misslending, |
Starting with enforcer 3.2.1 we can do it finally |
Will be resolved by #256 |
having extra-enforcer classes in same package than Enforcer itself is misleading when there is some issue: how can an end-user determine where to report?
The text was updated successfully, but these errors were encountered: