maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Tran (JIRA)" <j...@codehaus.org>
Subject [jira] Closed: (MDEP-162) localRepository as file URL in settings.xml makes unpacking dependencies fail: expanding into null
Date Sun, 03 Jan 2010 03:01:55 GMT

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

Dan Tran closed MDEP-162.
-------------------------

    Resolution: Won't Fix
      Assignee: Dan Tran  (was: Brian Fox)

even though url format is valid for localRepository settings, but I dont think it is worth
for use to do the extra mile to support this since it is very uncommon usage.

> localRepository as file URL in settings.xml makes unpacking dependencies fail: expanding
into null
> --------------------------------------------------------------------------------------------------
>
>                 Key: MDEP-162
>                 URL: http://jira.codehaus.org/browse/MDEP-162
>             Project: Maven 2.x Dependency Plugin
>          Issue Type: Bug
>          Components: unpack-dependencies
>    Affects Versions: 2.0
>         Environment: Windows XP
>            Reporter: Heiko Selber
>            Assignee: Dan Tran
>            Priority: Minor
>         Attachments: expanding_into_null.txt
>
>
> I specified the localRepository in settings.xml like this:
> <localRepository>file:///C:/.m2/repository</localRepository>
> Using a file URL is apparently valid for artifacts which are only downloaded.
> However, when a dependency is to be expanded to .unpacked-modules, a file URL leads to
failure.
> The dependency is unpacked to the directory where mvn was started.
> The console output shows this line:
> [INFO] Expanding: c:\.m2\repository\com\company\project\activemq-cpp\2.1.3_02\activemq-cpp-2.1.3_02-win32.zip
into null
> Debug output is attached, look for outputDirectory.
> The problem here is an inconsistency in treating a file URL; it is correctly used by
some modules, but incorrectly by others.
> Possible solutions:
> 1. Accept file URLs everywhere (preferred)
> 2. Don't accept file URLs anywhere and fail cleanly when file URL is encountered
> 3. Document clearly in which format the path is to be given

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

        

Mime
View raw message