You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jason van Zyl (JIRA)" <ji...@codehaus.org> on 2009/12/29 02:49:59 UTC
[jira] Updated: (MNG-2381) improved control over the repositories
in the POM
[ http://jira.codehaus.org/browse/MNG-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl updated MNG-2381:
-------------------------------
Fix Version/s: (was: 3.x)
3.1.alpha1
> improved control over the repositories in the POM
> -------------------------------------------------
>
> Key: MNG-2381
> URL: http://jira.codehaus.org/browse/MNG-2381
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories, Design, Patterns & Best Practices
> Reporter: Brett Porter
> Fix For: 3.1.alpha1
>
>
> some discussion: http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/%3c9e3862d80509301841w70bb5883hf352ac3c3bb7ea71@mail.gmail.com%3e
> 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