jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2 & 3
  • MNG-294

installation-wide configuration

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-alpha-3
  • Component/s: None
  • Labels:
    None

Description

similar (identical?) to settings.xml - we need something that can be added to a Maven installation.

Issue Links

relates to

New Feature - A new feature of the product, which has yet to be developed. MNG-3914 Add CLI option to control location of global settings from command line

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Brett Porter added a comment - 08/Jun/05 6:35 PM

... and include a sensible default, or all the settings commented out with notes.

Show
Brett Porter added a comment - 08/Jun/05 6:35 PM ... and include a sensible default, or all the settings commented out with notes.
Hide
Permalink
John Casey added a comment - 13/Jun/05 10:33 AM

for now, I'm working on the assumption that this is a file identical in capability to the ~/.m2/settings.xml file, but exists in ${maven.home}.

This should provide separation of truly global settings from user-specific settings, and local user settins will override. I'm planning on implementing a merge functionality similar to the project inheritance, except inside o.a.m.settings in the maven-core project...if this needs to be more generally available, I can move the MavenSettingsBuilder, etc. into the src/main/java of maven-settings. On second thought, I'll go ahead and do that last bit as well, since the ant tasks will probably want this...

Please correct here if my assumptions are wrong.

Show
John Casey added a comment - 13/Jun/05 10:33 AM for now, I'm working on the assumption that this is a file identical in capability to the ~/.m2/settings.xml file, but exists in ${maven.home}. This should provide separation of truly global settings from user-specific settings, and local user settins will override. I'm planning on implementing a merge functionality similar to the project inheritance, except inside o.a.m.settings in the maven-core project...if this needs to be more generally available, I can move the MavenSettingsBuilder, etc. into the src/main/java of maven-settings. On second thought, I'll go ahead and do that last bit as well, since the ant tasks will probably want this... Please correct here if my assumptions are wrong.
Hide
Permalink
John Casey added a comment - 13/Jun/05 4:57 PM

default location for global settings is ${maven.home}/settings.xml

Collisions on the id field of server, mirror, proxy, or profile will result in the user-specified entity completely suppressing the globally-defined one.

<activeProfiles/> are additive.

Show
John Casey added a comment - 13/Jun/05 4:57 PM default location for global settings is ${maven.home}/settings.xml Collisions on the id field of server, mirror, proxy, or profile will result in the user-specified entity completely suppressing the globally-defined one. <activeProfiles/> are additive.
Hide
Permalink
John Casey added a comment - 13/Jun/05 4:59 PM

need to include a default global settings.xml...NOTE: what is the goal of this?

Currently, if the settings.xml is missing from the global location, no merger takes place.

Show
John Casey added a comment - 13/Jun/05 4:59 PM need to include a default global settings.xml...NOTE: what is the goal of this? Currently, if the settings.xml is missing from the global location, no merger takes place.
Hide
Permalink
Brett Porter added a comment - 13/Jun/05 6:43 PM

the goal of the default settings.xml is to provide a template so someone can untar the install, go to conf/settings.xml and start setting up their proxy, etc. For the unix minded among us. There need not be any actual defaults in here that aren't commented out.

I think it makes sense that settings.xml is not merged if it doesn't exist (I have no idea what you meant by this statement

Show
Brett Porter added a comment - 13/Jun/05 6:43 PM the goal of the default settings.xml is to provide a template so someone can untar the install, go to conf/settings.xml and start setting up their proxy, etc. For the unix minded among us. There need not be any actual defaults in here that aren't commented out. I think it makes sense that settings.xml is not merged if it doesn't exist (I have no idea what you meant by this statement

People

  • Assignee:
    John Casey
    Reporter:
    Brett Porter
Vote (0)
Watch (0)

Dates

  • Created:
    11/Apr/05 8:43 PM
    Updated:
    15/Feb/09 8:28 AM
    Resolved:
    16/Jun/05 9:24 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.