[
http://jira.codehaus.org/browse/MNG-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108539
]
Dan Rollo commented on MNG-2381:
--------------------------------
I have a question related to the statement in the thread above that: all repo
settings should come from external sources (ie settings.xml).
I currently define our internal repo settings in a common parent pom. When repo
settings need to be changed, maven automatically gets the new parent pom as
needed. In the worst case situation, when the repo settings are so drastic that
maven can not automatically fetch the new parent pom, I can still tell users
to[ "get the latest" banked parent pom project and run mvn install]. Then they
are good to go again.
If I stored all repo settings in settings.xml, when repo settings need to be
changed, maven has no automatic way to update the settings.xml file (correct me
if I'm wrong on that). Furthermore, since settings.xml is commonly stored in
the user home dir, theres no way to tell users to ["get the latest" banked
parent pom project and run mvn install], since the get would not be into a
common dev tree, but would be in a different dir for each user (user home).
Please tell me I'm missing something, and there is any easy way to share and
update a common settings.xml file across the organization.
Thanks,
Dan
> improved control over the repositories in the POM
> -------------------------------------------------
>
> Key: MNG-2381
> URL: http://jira.codehaus.org/browse/MNG-2381
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories, Design, Patterns & Best
> Practices
> Reporter: Brett Porter
> Fix For: 2.1
>
>
> 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
