[ 
http://jira.codehaus.org/browse/MENFORCER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210088#action_210088
 ] 

Donnie Armstrong edited comment on MENFORCER-90 at 2/13/10 6:31 PM:
--------------------------------------------------------------------

Perhaps base the format off the output of dependency:tree? 

For example,
{noformat}
com.noelios.restlet:com.noelios.restlet.ext.spring:jar:1.1.5:compile
+- com.noelios.restlet:com.noelios.restlet.ext.servlet:jar:1.1.5:compile
+- org.springframework:spring-core:jar:2.5.6:compile
+- org.springframework:spring-context:jar:2.5.6:compile
|  \- aopalliance:aopalliance:jar:1.0:compile
+- org.springframework:spring-beans:jar:2.5.6:compile
+- org.springframework:spring-web:jar:2.5.6:compile
\- org.springframework:spring-webmvc:jar:2.5.6:compile
   \- org.springframework:spring-context-support:jar:2.5.6:compile
{noformat}
Therefore we might use the format of exclude/include as:
{noformat}groupId:artifactId:type:version:scope{noformat}

The following would permitted
{noformat}<exclude>com.noelios.restlet:*:*:*:provided</exclude>{noformat}

whereas this would be banned
{noformat}<exclude>com.noelios.restlet:*:*:*:compile</exclude>{noformat}

Another alternative might be to create a new exclude/include object that called 
out the artifact components instead of a string pattern. 
{noformat}
<exclude>
  <groupId />
  <artifactId />
  <type />
  <version />
  <scope />
</exclude>
{noformat}

      was (Author: donnie_armstrong):
    Perhaps base the format off the output of dependency:tree? 

For example,
com.noelios.restlet:com.noelios.restlet.ext.spring:jar:1.1.5:compile
+- com.noelios.restlet:com.noelios.restlet.ext.servlet:jar:1.1.5:compile
+- org.springframework:spring-core:jar:2.5.6:compile
+- org.springframework:spring-context:jar:2.5.6:compile
|  \- aopalliance:aopalliance:jar:1.0:compile
+- org.springframework:spring-beans:jar:2.5.6:compile
+- org.springframework:spring-web:jar:2.5.6:compile
\- org.springframework:spring-webmvc:jar:2.5.6:compile
   \- org.springframework:spring-context-support:jar:2.5.6:compile

Therefore we might use the format of exclude/include as:

groupId:artifactId:type:version:scope

The following would permitted
<exclude>com.noelios.restlet:*:*:*:provided</exclude>

whereas this would be banned
<exclude>com.noelios.restlet:*:*:*:compile</exclude>

- or -

create a new exclude/include object that called out the components instead of a 
string pattern. *hug* xml

<exclude>
  <groupId />
  <artifactId />
  <type />
  <version />
  <scope />
</exclude>
  
> Allow "BannedDependencies" to restrict artifacts per-scope
> ----------------------------------------------------------
>
>                 Key: MENFORCER-90
>                 URL: http://jira.codehaus.org/browse/MENFORCER-90
>             Project: Maven 2.x Enforcer Plugin
>          Issue Type: Improvement
>          Components: Standard Rules
>            Reporter: Andrew Lee Rubinger
>
> The current BannedDependencies plugin allows the restriction of any artifact 
> by groupId, artifactId, etc.  We've observed cases where we need to block 
> only in certain scopes, for instance:
> * I have a component which uses some logging backend
> * I don't want to allow any code to directly use the logging backend; it 
> should use an abstraction SPI
> * I want to bar all logging backends from the compilation classpath, but they 
> must be available at runtime for tests
> * So I'd set a banned dependency upon the logging backend for scopes 
> "compile" and "provided", permitting its use in testing
> I've mocked this (with hardcoded banned scopes) by copying from the existing 
> BannedDependency stuff:
> http://anonsvn.jboss.org/repos/sandbox/alrubinger/maven-enforcer-rule-nocompiledep/trunk/nocompiledep/src/main/java/org/jboss/maven/plugins/enforcer/rules/nocompiledep/NoCompileDependencyRule.java
> ...which works pretty well, but it'd be nice to have this
> 1) Configurable
> 2) Upstream

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to