[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280830#comment-280830
]
Arnaud Heritier commented on MNG-5181:
--------------------------------------
As far as I understand you can find already all remote repositories where the
artifact was found in the .lastUpdated metadata file in each artifac directory.
Thus Maven 3 only check when it does a build if the list of repositories
declared in the build (pom or settings) match a positive repository entry in
the metadata.
As I said, I think that the control may be useful but it goes further and we
shuld better try to solve the origin of these problems :
* The unability to identify a repository. An URL is wrong. It may change, you
may use a mirror ...
* The unability to classify entries in the local repository (these new metadata
are helping but a long time ago we proposed to go further by splitting the
local repository by origin. What's happen when we have 2 times an artifact with
the same identity on 2 remote repos but with a different content ? And we
should be able to have more control about what we accpet from where)
> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
