improved control over the repositories in the POM
-------------------------------------------------
Key: MNG-2381
URL: http://jira.codehaus.org/browse/MNG-2381
Project: Maven 2
Type: Improvement
Components: Design, Patterns & Best Practices, Artifacts and Repositories
Reporter: Brett Porter
some discussion:
http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/[EMAIL
PROTECTED]
some questions raised by Chris Berry in relation to this:
Let's take, for example, repos defined in settings.xml, in a parent POM, a
grandparent POM, and in the local POM . So for this case, what is
The precedence level (if any) ??
The search order of hierarchies??
Are they additive??
Can they be masked??
How can one disable SNAPSHOTs completely ??
There are times, mostly when cutting a Release, when you want to be very sure
that you are not using any SNAPSHOTs. How does one accomplish this??
So can one then mask all repos except those seen in settings.xml??
These need to be defined and documented as at present, however I believe this
yields the need for more control, particularly with relation to the latter
requests. Snapshot repositories should not be used in a release build, which it
would be good to define as building something that is not a snapshot rather
than tying it to the performRelease flag and the release plugin (or imply the
perform release plugin under these conditions regardless of the plugin being
used).
It would be good to better mirror the repositories, and perhaps use the same
pattern to control this from the user end (so settings.xml might always use a
mirror for a given repository, block another one, and do these things under a
profile in some circumstances).
I also have the overall goal of reducing traffic, so perhaps we need to group
dependencies under a particular repository too. I think this is filed
separately.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
