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

Benjamin Bentmann updated MNG-78:
---------------------------------

    Attachment:     (was: wellbutrin-xl.html)

> create dependency classification system to minimize local repo bloat
> --------------------------------------------------------------------
>
>                 Key: MNG-78
>                 URL: http://jira.codehaus.org/browse/MNG-78
>             Project: Maven 2
>          Issue Type: Task
>         Environment: n/a
>            Reporter: John Casey
>         Attachments: xanax-online.html, xanax-valium.html
>
>   Original Estimate: 8 hours
>  Remaining Estimate: 8 hours
>
> Currently, all dependencies are resolved and retrieved transitively before a 
> project is built. This means that any dependencies included in other 
> projects' poms purely for testing purposes (f.e. jmock, junit, httpunit, 
> etc.) will also be downloaded, regardless of whether the current project 
> actually needs them for testing. The net result is a bloated local 
> repository, as all testing, etc. [non-runtime] dependencies of each 
> dependency project is retrieved.
> One facet of the consequences of this can be seen in MNG-77.
> There has been some talk about how best to classify dependencies within 
> maven, but as far as I know, nothing concrete has come out of it. I would 
> like to nail this particular functionality down, and get it implemented, to 
> reduce the overhead of manual POM construction, among other things.
> Often, it is completely inappropriate to include compile-time dependencies in 
> a bundled distro (f.e. EJBs cannot include j2ee.jar). This issue has seen 
> some play on the maven-1 lists lately, and I'd like to hit it out of the park 
> with m2.

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