Bug 134190

The malfunction of propagating options changes to dbxgui is because sometime pcs in DbxProfile is null, and the reason
for this could be the ConfigurationAuxObject in MakeConfiguration.clone(), the following codes in
MakeConfiguration.clone() will make DbxProfile's pcs as null, but I couldn't figure out why :

        ConfigurationAuxObject[] objects = getAuxObjects();
        List<ConfigurationAuxObject> clonedAuxObjects = new ArrayList<ConfigurationAuxObject>();
        for(int i = 0; i < objects.length; i++){
            clonedAuxObjects.add((ConfigurationAuxObject)objects[i].clone());
        }
        clone.setAuxObjects(clonedAuxObjects);
        return clone;

Here's why.
AuxObjects belong to a Configuration and share a pcs with them.
RunProfile has two constructors, a plain one and one with a PCS parameter.
The one with the PCS parameter is called from it's provider using the whole AuxObject provider 
infrastructure. This all happens correctly when you create a Configuration.
But RunProfile.clone() uses the simple constructor so the resulting clone which
is created by MakeConfiguration.clone ends up w/o a pcs.

In cnd.makeproject cloning has two uses.
One is to create a "working copy" to be passed to editors (configuration
edit dialog). These working copies don't rely that much on property notification because
they usually just assign themselves back to the original copy which fires property
changes galore.
Another use is when a configuration is duplicated from the configuration manager UI.
Not copying the pcs in this case causes the problems described in this IZ. 

Coupl of ways this could be fixed:
- Have clone go through the AuXObj factories/providers instead of instantiating using plain
  "new RunProfile()".
  In other words cloning and factories cannot simultaneously co-exists w/o subtle problems.

- MakeConfiguration.clone() creates a new Configuration (with a pcs _and_ with all it's
  AuxObjects created (with _their_ correct pcs's)). It then goes and replaces references to
  the AuxObjs (sending them to be GC'ed) with cloned copies.
  MakeConfiguration.clone() could instead use assign to xfer info from it's AuxObjs to 
  the clones AuxObjs.

It's important to note that it's always desirable for a propertied object to have a pcs.
What's definitely is _not_ desirable is copying a pcs's registered _listeners_! If you
do that then you'll have multiple entities signalling one observer. 
I suspect in the process of enforcing this latter desire the baby (an empty pcs)
was thrown out with the bathwater (the pcs's listeners).

Was this cloning and AuxObject mgmt inherited/copied from some other place?
If so than that other place and whoever copied form it also suffers these problems.

Fixed:

changeset 7d449df4aec0 in main
details: http://hg.netbeans.org/main?cmd=changeset;node=7d449df4aec0
description:
	134190 project properties modification does not propagate to  current debug session

Instead of replacing aux objects in the copy with copies of the original ones, the values of original ones are assigned back to the copy preserving the pcs 
which is correct in the copy.

I have tested the fix with SS IDE and it seems to fix the problems described here. The SS build can be found here:
/net/danmark/export/home/thp/ceres/opt

verified in build provided by Thomas on /net/danmark/export/home/thp/ceres/opt

I've transplanted the changeset http://hg.netbeans.org/main?cmd=changeset;node=7d449df4aec0 into release61_fixes
repository as http://hg.netbeans.org/release61_fixes/rev/cad04c239182

delivered to SS