Bug 778370 (SOA-853)

Summary: reconfigure macro in schema/build.xml destroys original files
Product: [JBoss] JBoss Enterprise SOA Platform 4 Reporter: nwallace <nwallace>
Component: Build ProcessAssignee: Julian Coleman <jcoleman>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 4.2 CP01   
Target Milestone: ---   
Target Release: 4.2 CP03   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-853
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-23 10:25:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description nwallace 2008-09-25 19:28:59 UTC
Date of First Response: 2008-10-23 06:25:38
project_key: SOA

The reconfigure macro moves files to {file}.orig, and then moves them instead of copying them - which destroys the original file.      If the second move in the sequence were a copy instead of a move, it would be possible to rerun the schema script.    I think the intention was to preserve the original file - the subsequent copies don't overwrite the .orig files.   

      <macrodef name="reconfigure">
            <attribute name="file"/>
            <attribute name="old"/>
            <attribute name="new"/>
            <sequential>
                <move file="@{file}" tofile="@{file}.orig"/>
                <move file="@{file}.orig" tofile="@{file}">
                    <filterchain>
                        <replacestring from="@{old}" to="@{new}"/>
                    </filterchain>
                </move>
            </sequential>
        </macrodef>

Comment 1 nwallace 2008-09-25 19:28:59 UTC
Link: Added: This issue related SOA-695


Comment 2 nwallace 2008-09-25 19:29:33 UTC
Link: Added: This issue is duplicated by SOA-567


Comment 3 nwallace 2008-09-25 19:30:14 UTC
Can we have confirmation that fixes are in place for 4.2CP03.

Comment 4 Julian Coleman 2008-10-23 10:25:38 UTC
We will not fix this for 4.2CP03.