> public class AssertIConfiguration {
> static public void assertEquals(String message, IConfiguration expected,
> IConfiguration actual) {
> if (expected == actual) return;
>
> if (expected != null && actual != null) {
> AssertIBuildObject.assertEquals(message, expected, actual);
> AssertIBuildObjectPropertiesContainer.assertEquals(message, expected,
> actual);
> Assert.assertEquals(message, expected.getArtifactExtension(),
> actual.getArtifactExtension());
> Assert.assertEquals(message, expected.getArtifactName(),
> actual.getArtifactName());
> ....
> AssertIBuilder.assertEquals(message,
> expected.getBuilder(), actual.getBuilder());
> ...
> return;
> }
> junit.framework.Assert.failNotEquals(message, expected, actual);
> }
> }
>
> I think that kind of unit testing would be helpful to ensure that
> serialization is not being broken while being cleaning up.
> Andrew
> On Tue, Oct 21, 2008 at 8:27 AM, Schaefer, Doug
> <
Doug.Schaefer@xxxxxxxxxxxxx> wrote:
>>
>> Yes, there are many ways of doing trees in a property set. You could use
>> qualifiers or paths in keys as well.
>>
>> I guess my hope was that it would be good enough to get out of the
>> setting store business. The less time we spend on figuring out how to
>> store build settings, the more we can spend on cleaning up some of the
>> more serious issues we have, like redoing scanner discovery.
>>
>> Doug.
>>
>> > -----Original Message-----
>> > From:
cdt-dev-bounces@xxxxxxxxxxx
>> > [mailto:
cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
>> > Sent: Tuesday, October 21, 2008 4:17 AM
>> > To: CDT General developers list.
>> > Subject: Re: [cdt-dev] Project Preference Store
>> >
>> > > There are a couple of issues I can forsee with this:
>> > > - How do you handle ICSettingsStorage ICStoargeElement trees ?
>> > > Currently everything is stored in a tree. Key / Value preferences
>> > > aren't really a suitable replacement (and I think storing
>> > xml trees in
>> > > values will make version control even harder...)
>> >
>> > Taking a look at IEclipsePreferences more closely, they can
>> > represent a tree like store.. So that objection goes out the
>> > window :)...
>> >
>> > My aim with my current work is to allow any tree based
>> > storage to be used for persisting the model -- so something
>> > like this would plug-in nicely with (hopefully) little effort.
>> >
>> > James
>> > _______________________________________________
>> > cdt-dev mailing list
>> >
cdt-dev@xxxxxxxxxxx
>> >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >
>> _______________________________________________
>> cdt-dev mailing list
>>
cdt-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
>
cdt-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev