Hi Simon,

so after checking it i found the point...

I have defined mirrorOf * as usual in case of using a repository manager...in my settings.xml which looks like the following:

<mirrors>
  <mirror>
    <id>nexus</id>
    <mirrorOf>*</mirrorOf>
    <url>http://.../nexus/..</url>
  </mirror>
</mirrors>

So with the above i can add as much repository entries in my settings
as well as in my pom.xml and the rule will NOT warning/break my build with it...except if i explicitly exclude them in the mirrorOf via things like this:

<mirrorOf>*,!WhatEver</mirrorOf>

This brings me to two points:

First:

It would be nice if you could add an appropriate documentation (enforcer-rules/src/site/apt/) which exactly describes the differences to the requireNoRepository rule and give a good examples of the use cases which means not using mirrorOf as above etc.

After this enhancement of the patch (? submission to large for patch) i would appreciate to pick up your patch(?) and add it to extra-enforcer-rules (this will get a release faster i think) or may be the default rules (after discussion on the dev list with the other dev's) I don't know the exact procedure with such kind of submissions without paper....

Apart from the above you might can check if it's possible to
enhance the rule in that way to identify the repository entries in settings.xml/pom independent of the mirrorOf settings (may be via an option).


Kind regards
Karl-Heinz Marbaise
PS.: It's not necessary to quote the answers of the others here on the dev list to posts cause obviously I'm subscribed on the dev list and I'm following the discussion.

On 5/29/14 1:52 PM, Wang, Simon wrote:
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
On May 29, 2014, at 7:21 PM, Karl Heinz Marbaise <[email protected]> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to