maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ondrej Zizka (JIRA)" <>
Subject [jira] (MNG-5181) New resolution from local repository is very confusing
Date Fri, 01 Jun 2012 12:35:21 GMT


Ondrej Zizka commented on MNG-5181:

It's good that this feature is present; but I don't like having it forcibly enabled. At least
for my use case, i.e. creating a repo for offline use which contains artifacts from various
sources (EAP repo zip, JBoss repo, central).
I'd like to have a switch for this.

Also, when someone uses {{--offline}}, then it's probable that he knows what he's doing and
has everything in the local repo; so with {{--offline}}, this should be off by default.

And is every URL a different repo?  So e.g. Nexus "public" group alias is different from "releases"
repo? Despite having the very same artifacts? Or do some metadata tell this to Maven client?
> New resolution from local repository is very confusing
> ------------------------------------------------------
>                 Key: MNG-5181
>                 URL:
>             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 :

> 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:!default.jspa
For more information on JIRA, see:


View raw message