Fixed. Remove the config.xml entry only if it is empty.
Fixed in rev 486815 in branches\1.1, branches\1.2, branches\2.0-M1 and trunk. --vamsi On 12/13/06, David Jencks <[EMAIL PROTECTED]> wrote:
On Dec 13, 2006, at 9:18 AM, Vamsavardhana Reddy wrote: Yes. It removes the config.xml entry unconditionally. Once the configuration is deleted is it necessary to retain the config.xml entry? Should we skip those entries that have gbean elements inside? Will these entries be useful (used automatically) at a later deployment of the same configuration? When I worked on it my idea was that if you went to the trouble of customizing a module in config.xml we shouldn't remove those customizations: if you didn't want them any more you could remove them by hand. I really think we need to support preserving customizations over redeploys. To me, the ideal situation would be: - if there are no customizations for a module, undeploying the module removes the config.xml entry - if there are customizations, undeploying the module sets load="false" for the entry - deploying something with moduleId already present in config.xml sets load="true" for that entry and uses the customizations. - we have functional tests to verify that all this actually works. thanks david jencks --vamsi On 12/13/06, David Jencks <[EMAIL PROTECTED]> wrote: > > Does this unconditionally remove the config.xml entry? The original > idea was to only remove the config.xml entry if it had no > customizations: if it has customizations we tried to leave it with > load="false" > > thanks > david jencks > > <snip>
