[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318665#comment-318665
]
Brian Fox commented on MNG-5181:
--------------------------------
i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part. People
already get confused about what's a local repo vs what's a repository manager
and the mixing of these concepts here will make that worse.
> New resolution from local repository is very confusing
> ------------------------------------------------------
>
> Key: MNG-5181
> URL: https://jira.codehaus.org/browse/MNG-5181
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
> Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
> Reporter: Arnaud Heritier
> Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> I just discover the change introduced in Maven 3.x to try to improve the
> resolution mechanism and to avoid to use a local artifact which may not be
> available in its remote repository :
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> Even if the feature is interesting it has several problems :
> # When an artifact isn't accessible from its remote repository it isn't used
> by maven which replies a classical "dependency not found error". It is really
> annoying for a user with some Maven 2 skills which will have a look at his
> local repo, will find the artifact and won't understand why Maven doesn't use
> it. At least the error reported by Maven should be clear that even if the
> dependency is available locally, it isn't used because it's remote repository
> isn't available.
> # This behavior cannot be configured to be only a warning for example. It is
> really annoying because it doesn't take care of some context and constraints
> we may have in a development team. Let's imagine that the remote artifact is
> really removed. Cool Maven broke the build to warn us. But it brakes the
> build of all the team whereas perhaps only one of them may try to solve the
> issue (and it can be a long resolution). Thus having the ability to configure
> if this control is blocker or warning may allow the team to configure it as
> blocker on the CI server and as warning on the development environment.
> # This behavior may introduce some bad practices for example when we are
> using a staging feature on a repository manager. In our case my teams have a
> dedicated profile to activate a staging repository when we are validating a
> release. I recommend to not have this profile always activated but to do it
> only on-demand to avoid them to DL staging stuffs they don't need. With this
> new feature they need for all builds they run to activate this staging
> profile while binaries are stored in it. When you have to do it 20 times per
> day minimum let's imagine what the developer does : It adds it as an
> alwaysActive profile and then forget to remove it when the release is ended.
> For all these reason I would like we improve this feature to make it more
> usable and before all bet understandable for ours users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
