[
https://issues.apache.org/jira/browse/MNG-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802922#comment-16802922
]
Max Lee commented on MNG-6612:
------------------------------
While this might work for some projects it doesn't work for tons of others
which can't be hosted there due to depending on other libraries or having
non-compatible licenses. (Besides all the obvious issues a centralised
service has)
I do lots of work in the Minecraft server modding and extending community
and projects are often impossible to be hosted on central, either due to
the base APIs not being (able to be) included or due to their interaction
with the proprietary base game code. Granted they don't seem to take the
"self-contained" rule too serious as far as I can tell, but it's
questionable if someone who only barely is able to use maven for their
small project would be able to go through the whole process of arguing
against one of the rules to get it included. In the end you are lucky if
the projects you want to depend on are even using maven. I would assume
that other modding communities would face similar issues, although I don't
know of any Java based ones that have comparable sizes.
Also part of me opening this issue was hoping for me having overlooked an
obvious configuration option, so I guess I got my answer and have to do the
work myself if I really want this.
> Ability to set repository of dependency
> ---------------------------------------
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
> Reporter: Max Lee
> Priority: Minor
> Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project
> it would be a useful to be able to specify which repository contains which
> dependency in the pom and not resolve such dependencies from the general
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in
> certain repositories because they contain broken versions or when you simply
> want to stop the potential privacy/security issues that leaking dependencies
> to another repository that doesn't even include the dependency could
> introduce. (Theoretically an ignored/skip-repositories setting could also
> solve this issue) Another application of this feature could be to define
> different update or checksum check setting for different artifacts that would
> use the same repository.
> This could theoretically be setup using the repository name:
>
> {code:java}
> <dependency>
> <groupId>id.group</groupId>
> <artifactId>artifact-id</artifactId>
> <version>version-string</version>
> <repositories>
> <repository>repository-id</repository>
> </repositories>
> </dependency>
> {code}
> or by allowing to directly set the repository-settings in the dependency and
> not on the outer scope (this would allow for a wider range of applications by
> allowing different repository settings per artifact but require a larger
> config for simply setting the repository of an artifact)
>
> {code:java}
> <dependency>
> <groupId>id.group</groupId>
> <artifactId>artifact-id</artifactId>
> <version>version-string</version>
> <repositories>
> <repository>
> <id>repository-id</id>
> <url>https://repo.example.com/</url>
> </repository>
> </repositories>
> </dependency>
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
