Hi Simon,

after diving into this a little bit more...

Can you give an real example of the use case for your rule, cause if you are in an enterprise environment you should use already a repository manager which means only having a mirror entry in your settings.xml (usually looks like this here: http://books.sonatype.com/nexus-book/reference/maven-sect-single-group.html)
 no repositories in your pom's (which can be checked by the
requireNoRepositories rule).

Apart from that I have tried your rule, but unfortunately it does not identify repositories defined in the pom file (ok that was not the intention) nor does it realize that i have defined supplemental repositories in my settings.xml file....

May be you can give an full example in which cases it will help...or may be i mistaken things here...

Kind regards
Karl-Heinz Marbaise

On 5/29/14 4:24 PM, Wang, Simon wrote:
Hi, Robert,

Karl asked same question, please refer below mail about this question.
Hope that help.

Regards
Simon
~~~~
Hi, Karl,

Thanks for your comments.

I did dig into requireNoRepositories.html, the purpose for that rule is:
detect whether pom and pom’s parents contains repositories definition.
That make sense to guide users to use correct convention (not define 
repositories in pom files).

But “BannedRepositories” is different purpose, it’s just like 
“BannedDependencies”.
This rule is major for those “maven repository migration” case.
Some users used to have old repositories, those repositories might be defined 
in pom.xml or settings.xml.
This rule could benefit on these cases a lot.
It will detect banned repositories from maven session context instead of only 
pom.xml and parents.

After all, requireNoRepositories.html is trying to help users to follow correct 
maven convention.
but “BannedRepositories” is trying to avoid misuse incorrect repositories. 
Especially in enterprise environment.

Regards
Simon

~~~~
Hi Simon,


I have taken a look into your suggestions ....I have a couple of thoughts about 
it ...

First there exists already a rule to avoid repositories 
(http://maven.apache.org/enforcer/enforcer-rules/requireNoRepositories.html) 
which can be used and is has an option
to allow particular repositories by using a  white-list of allowed repository 
based on the repository id.

like this:

<requireNoRepositories>
  <allowedRepositories>
    <allowedRepository>codehausSnapshots</allowedRepository>
  </allowedRepositories>
  ...
</requireNoRepositories>


So the question is why adding a complete new rule instead of enhancing the 
existing by your idea using the url as identification for the repository which 
i think is a really good idea...so users are not able to forge the repository 
they use by using a different id only the url is used to identify the allowed 
repositories.


Kind regards
Karl-Heinz Marbaise

On May 29, 2014, at 10:15 PM, Robert Scholte <rfscho...@apache.org> wrote:

http://maven.apache.org/enforcer/enforcer-rules/requireNoRepositories.html 
seems to cover this, right?

Robert

Op Wed, 28 May 2014 22:19:07 +0200 schreef Mirko Friedenhagen 
<mfriedenha...@gmail.com>:

Hello everybody,

there is an outstanding MENFORCER-193[0] request for a new standard
rule, which will allow to ban repositories. What is your opinion about
adding new standard rules in enforcer vs. adding to Mojo's
extra-enforcer-rules?

Regards Mirko
[0] https://jira.codehaus.org/browse/MENFORCER-193
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to