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

move extra enforcer rules code from org.apache.maven.plugins.enforcer package to a non-Apache package #12

Closed
hboutemy opened this issue Sep 12, 2015 · 15 comments

Comments

@hboutemy
Copy link
Member

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?

@hboutemy hboutemy changed the title move extra enforcer rules fro org.apache.maven.plugins.enforcer package to a non-Apache package move extra enforcer rules code from org.apache.maven.plugins.enforcer package to a non-Apache package Sep 12, 2015
@batmat
Copy link
Member

batmat commented Sep 13, 2015

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?

@stephenc
Copy link
Contributor

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

On 13 Sep 2015, at 20:15, Baptiste Mathus notifications@github.com wrote:

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?


Reply to this email directly or view it on GitHub.

@hboutemy
Copy link
Member Author

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
Since we can't expect everybody putting his own code in Maven's package

this is independant from the good idea to move some rules to ASF if they are good (like enforce bytecode...)

@stephenc
Copy link
Contributor

It's modello that makes the package name requirement.

Sent from my iPhone

On 13 Sep 2015, at 22:47, Hervé Boutemy notifications@github.com wrote:

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
Since we can't expect everybody putting his own code in Maven's package

this is independant from the good idea to move some rules to ASF if they are good (like enforce bytecode...)


Reply to this email directly or view it on GitHub.

@hboutemy
Copy link
Member Author

Modello? imposing some constraints on class loading scheme? I'm surprised.
And I'm even more surprise that I didn't see any Modello model in enforcer code.

Can you elaborate, please?

@khmarbaise
Copy link
Member

The classes in extra-enforcer are already in org/apache/maven/plugins/enforcer package...so no need to change the package name.

@stephenc
Copy link
Contributor

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

On 13 Sep 2015, at 23:49, Hervé Boutemy notifications@github.com wrote:

Modello? imposing some constraints on class loading scheme? I'm surprised.
And I'm even more surprise that I didn't see any Modello model in enforcer code.

Can you elaborate, please?


Reply to this email directly or view it on GitHub.

@hboutemy
Copy link
Member Author

@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
of course, this require Maven Enforcer to support such configuration...

@stephenc
Copy link
Contributor

@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

@hboutemy
Copy link
Member Author

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

@rfscholte
Copy link
Member

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.

@mfriedenhagen
Copy link
Member

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?

@slachiewicz
Copy link
Member

https://issues.apache.org/jira/browse/MENFORCER-367 issue reported to Maven Enforcer - even for me package name was misslending,

@slawekjaranowski
Copy link
Member

Starting with enforcer 3.2.1 we can do it finally
https://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

@slawekjaranowski
Copy link
Member

Will be resolved by #256

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

8 participants