[jira] Closed: (MNG-2572) Support for unversioned third party JARs

["Jason van Zyl (JIRA)" <ji...@codehaus.org>]

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

Jason van Zyl closed MNG-2572.
------------------------------

    Resolution: Won't Fix

> Support for unversioned third party JARs
> ----------------------------------------
>
>                 Key: MNG-2572
>                 URL: http://jira.codehaus.org/browse/MNG-2572
>             Project: Maven 2
>          Issue Type: New Feature
>          Components: Dependencies
>    Affects Versions: 2.0.4
>            Reporter: Markus KARG
>
> Problem:
> Maven's dependency management is great, but it lacks "real" support for unversioned, third party JARs.
> A Maven project declared dependencies on "foreign" JARs by adding a dependency to the own pom.xml. That dependency declaration comprises of groupId, atifactId, and version. In turn, Maven builds the actually used JAR name by concatenating the version to the JAR's actual name. This is great if the referenced JAR is built with Maven, but it is a problem whenever that other JAR is not built by Maven.
> Example:
> You project needs to load some classes of FOO.jar. FOO.jar itself is a closed source library that can be downloaded on the web, but it must not be repackaged. Your own project will never succeed using it, since FOO.jar is never called FOO-1.0.0.jar but always only FOO-1.0.0.jar. Since e. g. licenceing rules restricts renaming and repackaging of FOO.jar, you cannot use that JAR in your project and in turn, you even cannot use Maven to build your own project.
> Cause:
> This is caused by Maven expecting the name of a referenced binary always containing the version.
> Solution:
> Maven should allow pom.xml to specificy the actual JAR name, e. g. by adding a new tag named <jar-name> that is parallel to <version>, <artifactId> etc. Once that tag is provided, it doesn't build the JAR name by adding the version but it just uses the provided JAR name. This implies the following two results:
> (a) When <jar-name>FOO</jar-name> is provided in the section describing the own project, then "mvn package" will create FOO.jar instead of ArtifactId-VersionId.jar.
> (b) When <jar-name>FOO</jar-name> is provided within a <dependency> section, then "mvn package" will add FOO.jar to Class-Path: instead of ArtifactId-VersionId.jar, and the dependency loader will try to download FOO.jar instead of ArtifactId-VersionId.jar.
> Notes:
> This new feature is optional. It is not intended to replace the dependency mechanism as it currently exists, but it is only an additional option that can be used whenever it is necessary to have the JAR name explicitely told.
> The repository will still be organized and scanned using the information found in groupId, artifactId and version. This mechanism is not touched. Only the JAR's actual name is touched by this change.
> Side Effects:
> There should be no side effects besides solving the told problems, since the original mechanism is not changed. The new feature is completely optional.

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