Message: A new issue has been created in JIRA.
--------------------------------------------------------------------- View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1191 Here is an overview of the issue: --------------------------------------------------------------------- Key: MAVEN-1191 Summary: ~/build.properties should define globals; project.properties should override Type: New Feature Status: Unassigned Priority: Major Original Estimate: 2 hours Time Spent: Unknown Remaining: 2 hours Project: maven Components: core Versions: 1.1 Assignee: Reporter: John Casey Created: Mon, 8 Mar 2004 12:03 PM Updated: Mon, 8 Mar 2004 12:03 PM Environment: all Description: Currently, maven loads the [global] ~/build.properties as an override for everything else in the system. This means that anything specified in the project.properties gets wiped out when build.properties is included. This is contrary to intuition and indeed to most software configuration methodologies out there today. In most cases, we expect locally-defined parameters to be special cases of the default value, and therefore override the global specification. The value of a dominant build.properties is questionable at best, especially given the requirement of [one project == one artifact] which requires many real-world applications to be split into multiple maven project definitions. When this scenario plays out, and a proprietary maven repository is used, one of two things must be done: (a) supply maven.repo.remote=xxx,yyy in build.properties (and break any non-proprietary, project-level specifications of this parameter), or (b) supply a project.properties _for_every_proprietary_project_ which can make project maintenance an absolute nightmare. I understand that maven-proxy is available to solve this and other problems, but this itself adds unnecessarily to the maintenance burden; one cannot simply use additive maven.repo.remote definitions any more...why is this additive behavior even present if it's not usable? I propose two solutions: 1. Change the import order of the .properties file, to put build.properties nearer the top of the list (and hence, the default, but not the dominant). This will break current use cases where global override of local projects is used. 2.Split the ~/build.properties into ~/build-defaults.properties and ~/build-override.properties (maybe the latter is aliased as build.properties for legacy support). Then, dominant global overrides are specified in the build-override.properties, and recessive default values are in build-defaults.properties...This will allow global parameter values which can be overriden by non-mainstream (i.e. non-proprietary) project definitions which supply their own parameter values. All in all, this is a relatively easy fix. It's quite a bit like the fix to split driver.properties into driver.properties and defaults.properties, which was done circa beta-9 I think. --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
