[ 
http://jira.codehaus.org/browse/MNG-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-1390.
----------------------------------

       Resolution: Not A Bug
    Fix Version/s:     (was: 3.0-alpha-8)
         Assignee: Benjamin Bentmann

{...@requiresdependencyresolution}} is equivalent to 
{...@requiresdependencyresolution runtime}} and runtime scope does not include 
provided scope. Plugins get what they ask for, not more.

> @requiresDependencyResolution in process-classes post compile
> -------------------------------------------------------------
>
>                 Key: MNG-1390
>                 URL: http://jira.codehaus.org/browse/MNG-1390
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Inheritance and Interpolation
>    Affects Versions: 2.0
>            Reporter: Jesse McConnell
>            Assignee: Benjamin Bentmann
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> I was looking back into some plugins I had written a while back and ran 
> across an oddity.
> it appears that when using a plugin in the process-classes phase, after the 
> compiler plugin has done its thing, the @requiresDependencyResolution javadoc 
> flag will toggle the presense of dependencies that are scoped to provided in 
> the dependencies section when calling project.getCompileClasspathElements();  
> (a difference of 80 vs 24 when not using the flag and then using it)
> ---
> this are two snippits of code from the plugin
> /**
>  * A plugin for generating * java file containing all the classes in a src 
> tree.
>  *
>  * @goal generate
>  * @requiresDependencyResolution
>  * @description Functions Generator plugin
>  * @author jesse <je...@g.com>
>  */
>  
>  
>  
>          List classpathFiles = project.getCompileClasspathElements();
>  
>          URL[] urls = new URL[classpathFiles.size() + 1];
>  
>          getLog().debug("" + classpathFiles.size());
>  
>          for (int i = 0; i < classpathFiles.size(); ++i) {
>             getLog().debug((String)classpathFiles.get(i));
>             urls[i] = new File((String)classpathFiles.get(i)).toURL();
>          }
>  
>          urls[classpathFiles.size()] = new File( buildDirectory + "/classes" 
> ).toURL();
>  
>          URLClassLoader ucl = new URLClassLoader(urls, 
> Thread.currentThread().getContextClassLoader());
> being used with the following plugin declaration:
> <plugin>
>             <groupId>gallup.maven</groupId>
>             <artifactId>services-provider-maven-plugin</artifactId>
>             <version>1.0.1</version>
>             <configuration>
>                
> <fullyQualifiedFileName>com/g/util/ServiceProvider.java</fullyQualifiedFileName>
>             </configuration>
>             <executions>
>                <execution>
>                   <phase>process-classes</phase>
>                   <goals>
>                      <goal>generate</goal>
>                   </goals>
>                </execution>
>             </executions>
>          </plugin>
> ----
> analyzing the debug output when I run the plugin without the 
> @requiresDependencyResolution I get 80 dependencies and it builds out the 
> classloader correctly..
> but if I add the @requiresDependencyResolution statement I go down to 24 
> dependencies being put into the classloader...and the discrepency corresponds 
> to the presense of the <scope>provided</scope> statement.

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