The following issue has been updated:
Updater: Brett Porter (mailto:[EMAIL PROTECTED])
Date: Mon, 8 Mar 2004 9:26 PM
Changes:
Version changed from 1.1
Fix Version changed to 1.1
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1191&page=history
---------------------------------------------------------------------
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
Fix Fors:
1.1
Assignee:
Reporter: John Casey
Created: Mon, 8 Mar 2004 12:03 PM
Updated: Mon, 8 Mar 2004 9:26 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]
