[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316700#comment-316700
]
Devin Reid commented on MNG-5181:
---------------------------------
This feature makes creating portable offline builds require more steps than it
did in Maven2. In Maven2 you could do a build using a custom 'maven.repo.local'
property and then tar up the whole project, move it to a new box without
network access, and have the project build fine offline. Now you either have to
strip all the _maven.repository files manually or configure mirrors on a box
that has no network access anyway.
Would it be possible to have this feature disabled for --offline (-o) builds,
or perhaps provide another mechanism for disabling this.
> 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: Jason van Zyl
>
> 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
