[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5181:
-------------------------------
Description:
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/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#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.
was:
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.
> New resolution from local repository is very confusing
> ------------------------------------------------------
>
> Key: MNG-5181
> URL: https://jira.codehaus.org/browse/MNG-5181
> Project: Maven
> 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-alpha-1
>
>
> 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/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#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 was sent by Atlassian JIRA
(v6.1.6#6162)
