[ http://jira.codehaus.org/browse/MNG-2572?page=comments#action_75664 ]
Geoffrey De Smet commented on MNG-2572:
---------------------------------------
You're basically asking for a the jar-override system from Maven 1.
Which was indeed handy for quick&dirty stuff.
One side effect that I can think of is what happens once you deploy your
artifact with a dependency that has such an obscure version, download location
etc? The central repo should surely not accept anything that uses
jar-override...
Better support (and a documented example...) for remote-local repositories in
the project dir, in a multiproject setup, would be more usefull I think. E.g:
foo
src
foo-web
foo-ear
foo-ejb
repo
org.hibernate
hibernate-annotations
3.2.0
hibernate-annotations-3.2.0.jar
One would still need to do the work of writing/generating a pom for the jar,
but one could create an eclipse/intellij configuration file that doesn't
require knowning and using maven first to download all jars. You could just
give the project directory. For example: you're teaching students
hibernate-annotations without first needing to teach them maven.
> 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
