Re: enforcer-rules: standard vs. extra-enforcer-rules

[Simon Wang]

^_^

sorry for that, just don't know what's the status for it.

Regards
Simon


2014-06-12 5:54 GMT+08:00 Karl Heinz Marbaise :

> Hi Simon,
>
> you seemed to be very impatient...
>
> Kind regards
> Karl-Heinz...
>
> BTW: I will take care within the next few days...
>
>
>
> > May I know who is handling this PR?
>
>> https://github.com/apache/maven-enforcer/pull/13
>>
>> any comments or concerns?
>>
>
>
>
>> Regards
>> Simon
>>
>>
>> 2014-05-30 10:38 GMT+08:00 Wang YunFeng > >:
>>
>>
>> Hi, Karl,
>>
>> Real case happened in our company is:
>> There are bunch of repositories using. For specific application,
>> need to limit specific set of repositories.
>>
>> Those invalid repositories could be defined anywhere.
>> like settings.xml, application's pom files or even in dependency's
>> pom files.
>>
>> So point is: this rule will ban repositories from maven session
>> level, instead of only application pom and its parent.
>> Also attached some comments below from Paul.
>>
>> I create a demo project to show how to use this rule:
>> 1. clone https://github.com/wangyf2010/maven-enforcer, "mvn clean
>> install -DskipTests" it.
>> 2. clone
>> https://github.com/wangyf2010/maven-shared/tree/banned-
>> repos/maven-dependency-analyzer
>> 3. run "mvn enforcer:enforce" for "maven-dependency-analyzer".
>>
>> Of course, you can try to add banned repositories into settings.xml
>> as well.
>>
>> Regards
>> Simon
>>
>> 
>> I think banning repositories is a great idea. The example givem may
>> not be
>> too useful -- the system architects should just turn off access to
>> the repo
>> they don't want anyone to acesss -- but I more than once wanted to
>> stop
>> some live repos (out of my control) from being accessed. +1.
>>
>>
>> Cheers,
>> Paul
>>
>>
>> 2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise > >:
>>
>>
>> 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
>> > 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

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Karl Heinz Marbaise]

Hi Simon,

you seemed to be very impatient...

Kind regards
Karl-Heinz...

BTW: I will take care within the next few days...


> May I know who is handling this PR?

https://github.com/apache/maven-enforcer/pull/13

any comments or concerns?





Regards
Simon


2014-05-30 10:38 GMT+08:00 Wang YunFeng mailto:wangyf2...@gmail.com>>:

Hi, Karl,

Real case happened in our company is:
There are bunch of repositories using. For specific application,
need to limit specific set of repositories.

Those invalid repositories could be defined anywhere.
like settings.xml, application's pom files or even in dependency's
pom files.

So point is: this rule will ban repositories from maven session
level, instead of only application pom and its parent.
Also attached some comments below from Paul.

I create a demo project to show how to use this rule:
1. clone https://github.com/wangyf2010/maven-enforcer, "mvn clean
install -DskipTests" it.
2. clone

https://github.com/wangyf2010/maven-shared/tree/banned-repos/maven-dependency-analyzer
3. run "mvn enforcer:enforce" for "maven-dependency-analyzer".

Of course, you can try to add banned repositories into settings.xml
as well.

Regards
Simon


I think banning repositories is a great idea. The example givem may
not be
too useful -- the system architects should just turn off access to
the repo
they don't want anyone to acesss -- but I more than once wanted to stop
some live repos (out of my control) from being accessed. +1.


Cheers,
Paul


2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise mailto:khmarba...@gmx.de>>:

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:


   

__codehausSnapshots
   
   ...



So the question is why adding a complete new rule instead of

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Simon Wang]

May I know who is handling this PR?
https://github.com/apache/maven-enforcer/pull/13

any comments or concerns?

Regards
Simon


2014-05-30 10:38 GMT+08:00 Wang YunFeng :

> Hi, Karl,
>
> Real case happened in our company is:
> There are bunch of repositories using. For specific application, need to
> limit specific set of repositories.
>
> Those invalid repositories could be defined anywhere.
> like settings.xml, application's pom files or even in dependency's pom
> files.
>
> So point is: this rule will ban repositories from maven session level,
> instead of only application pom and its parent.
> Also attached some comments below from Paul.
>
> I create a demo project to show how to use this rule:
> 1. clone https://github.com/wangyf2010/maven-enforcer, "mvn clean install
> -DskipTests" it.
> 2. clone
> https://github.com/wangyf2010/maven-shared/tree/banned-repos/maven-dependency-analyzer
> 3. run "mvn enforcer:enforce" for "maven-dependency-analyzer".
>
> Of course, you can try to add banned repositories into settings.xml as
> well.
>
> Regards
> Simon
>
> 
> I think banning repositories is a great idea. The example givem may not be
> too useful -- the system architects should just turn off access to the repo
> they don't want anyone to acesss -- but I more than once wanted to stop
> some live repos (out of my control) from being accessed. +1.
>
>
> Cheers,
> Paul
>
>
> 2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise :
>
> 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:
>>>
>>> 
>>>   
>>> codehausSnapshots
>>>   
>>>   ...
>>> 
>>>
>>>
>>> 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 
>>> 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 

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Wang YunFeng]

Hi, Karl,

Real case happened in our company is:
There are bunch of repositories using. For specific application, need to
limit specific set of repositories.

Those invalid repositories could be defined anywhere.
like settings.xml, application's pom files or even in dependency's pom
files.

So point is: this rule will ban repositories from maven session level,
instead of only application pom and its parent.
Also attached some comments below from Paul.

I create a demo project to show how to use this rule:
1. clone https://github.com/wangyf2010/maven-enforcer, "mvn clean install
-DskipTests" it.
2. clone
https://github.com/wangyf2010/maven-shared/tree/banned-repos/maven-dependency-analyzer
3. run "mvn enforcer:enforce" for "maven-dependency-analyzer".

Of course, you can try to add banned repositories into settings.xml as well.

Regards
Simon


I think banning repositories is a great idea. The example givem may not be
too useful -- the system architects should just turn off access to the repo
they don't want anyone to acesss -- but I more than once wanted to stop
some live repos (out of my control) from being accessed. +1.


Cheers,
Paul


2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise :

> 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:
>>
>> 
>>   
>> codehausSnapshots
>>   
>>   ...
>> 
>>
>>
>> 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 
>> 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/

 ---

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Karl Heinz Marbaise]

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:


  
codehausSnapshots
  
  ...



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  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 
:


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

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Stephen Connolly]

extra-enforcer-rules is just there for a number of use cases:

* Rules that have non-ASLv2 compatible licenses
* Rules that are somewhat experimental (such rules should not be put in the
"default" package) until they are considered developed well enough to
migrate to enforcer-rules
* Rules being developed by people who have not got a Maven project commit
bit *yet* but would like to demonstrate that they deserve one after getting
the *easier to get* codehaus mojo commit bit. (Mojo's commit bit is got by
standing up and asking... the devs then vote and there you go... Maven's
commit bit is got by demonstrating to the PMC that you are "worthy" and
then the PMC deciding to invite you... different members of the PMC have
different views on what counts as "worthy" - which is the way it should be
;-) )


On 28 May 2014 21:19, Mirko Friedenhagen  wrote:

> 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
>
>

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Paul Benedict]

I think banning repositories is a great idea. The example givem may not be
too useful -- the system architects should just turn off access to the repo
they don't want anyone to acesss -- but I more than once wanted to stop
some live repos (out of my control) from being accessed. +1.


Cheers,
Paul


On Thu, May 29, 2014 at 9:24 AM, 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:
>
> 
>  
>codehausSnapshots
>  
>  ...
> 
>
>
> 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  wrote:
>
> >
> http://maven.apache.org/enforcer/enforcer-rules/requireNoRepositories.htmlseems
>  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
> >
>
>

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Wang, Simon]

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:


 
   codehausSnapshots
 
 ...



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  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 
> :
> 
>> 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
> 

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Robert Scholte]

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  
:



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

Re: enforcer-rules: standard vs. extra-enforcer-rules

[Wang, Simon]

Thanks for your comments, Mirko!

This feature would be helpful for those enterprise maven developers.
That would be great could include it into standard rules and benefit more 
enterprise users.

Regards
Simon

On May 29, 2014, at 4:19 AM, Mirko Friedenhagen  wrote:

> 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

enforcer-rules: standard vs. extra-enforcer-rules

[Mirko Friedenhagen]

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