[maven-bug] Updated: (MAVEN-294) maven.username when set in root project.properties doesn't propagate to reactor-driven sub-projects

[bo...@werken.com]

The following issue has been updated:

    Updater: John Casey (mailto:jdcasey@commonjava.org)
       Date: Wed, 26 Feb 2003 2:00 AM
    Comment:
diff to existing touchstone test project to express maven.username problem.
    Changes:
[Attachment] [maven-username-touchstone.diff] was added

---------------------------------------------------------------------
For a full history of the issue, see:

  http://jira.werken.com/secure/ViewIssue.jspa?key=MAVEN-294&page=history

---------------------------------------------------------------------
View the issue:

  http://jira.werken.com/secure/ViewIssue.jspa?key=MAVEN-294


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: MAVEN-294
    Summary: maven.username when set in root project.properties doesn't propagate to reactor-driven sub-projects
       Type: Bug

     Status: Assigned
   Priority: Minor

 Time Spent: Unknown
   Estimate: 1 hour

    Project: maven
  Component: core
   Versions:
             1.0-beta-9

   Assignee: Jason van Zyl
   Reporter: John Casey

    Created: Wed, 26 Feb 2003 1:59 AM
    Updated: Wed, 26 Feb 2003 2:00 AM
Environment: RH linux 8, jdk1.4.1

Description:
when the maven.username is set in a project's project.properties file, and that project in turn invokes sub-project builds through the use of reactor, (or other means, I assume) the creation of the new Context for the sub-project overwrites the maven.username from the root project.  This is caused by the defaults in the driver.properties file, which are (a) loaded while the context isn't in inheritance mode, and (b) primarily used as markers to denote that the property hasn't been set (ironically).  I will include the touchstone diffs and the new touchstone test files for expressing this bug, along with an admittedly old patch which would probably address the problem.  My proposed solution is essentially to split out all so-called "marker" properties from the driver.properties file into a separate markers.properties file, and then to load that file AFTER inheritance mode is turned back on for the context.  This will ensure that any of these marker properties don't overwrite a value from the root context.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.werken.com/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira